什麼是降幀&為什麼降幀
一般情況下我們為了提高整個遊戲的體驗，所以我們一般會將遊戲的幀數（每秒鐘重新整理多少次）設定的比較高。一般情況下，我們的遊戲所有的**都是一幀執行一次。為了讓每一幀都變成真的關鍵資料幀。不過，部分手機能效能可能跟不上，或者計算量太大的情況下，手機的運算速度不能夠支援的情況，過高的效能消耗就會拖慢運算的速度，讓一秒內沒有辦法打到滿幀。所以就會覺得遊戲變得卡頓。
其實一部分邏輯並沒有必要每一幀都去執行，可以將他們隔幾幀執行一次也不是不可以。比如說傷害值的運算，傷害應該與遊戲運營的幀數無關，比如每0.1秒執行一次傷害**，那麼在滿幀60幀的情況下，其實每6幀執行一次就ok。
或許你會問，如果我們的程式最少的邏輯間隔時間是0.1的話。所有的遊戲邏輯都是間隔0.1判定一次不就好了？這不是很簡單的事情？但實際上事情並沒有那麼簡單。一般情況下我們人眼的錄入認為是16幀每秒。那麼理論上滿足16幀的遊戲，我們就應該覺得很流暢了。但是你我都知道，16幀的遊戲，並不能讓人覺得非常流暢。為什麼？原因也非常簡單。人看到的東西會有預判，你看到這個怪物在水平移動，如果遊戲表現出來的效果與你的預判是保持一致的，那麼你就會覺得這是非常流暢的，但是如果怪物的移動跟你的預判不一致，那麼你就會覺得這個遊戲並不流暢。回答一下剛才自己提問的問題。為什麼不可以，因為你把業務堆積到某一幀裡邊去了。所以這一幀裡邊的運算量跟你沒有降幀之前的運算量是一致的，相對於沒有運算的幀來說，你是卡頓的。這個時候。一會卡頓一會流暢。或許你列印出來的每秒的幀數是夠60的。但是你表現出來的效果並不流暢。
我們之所以希望能提高幀數，是為了製造流暢的感覺。但是降幀則會違反這種感覺。所以遊戲的幀數不能降低，或者在準確一點來說，遊戲的view的幀數不應該降低，減低的應該是邏輯幀數。
請原諒我取了乙個比較迷惑的題目。其實這樣的原因，是希望你能夠讀下去。而不是看一眼題目就自以為知道具體是怎麼處理了。
怎麼降幀
從上文中，我已經提到了。我希望將遊戲的幀數分為兩種，一種邏輯幀，一種view幀。view幀是滿幀在跑的。邏輯幀則是間隔執行的。也沒錯。上文中已經提到了，簡單的區分這兩種更新的實際也並不合適。因為依然會卡頓。那怎麼才會不卡呢。將資料量分攤到各個幀裡邊。
怪物會有兩種跟新模式
1、view更新：用來更新他的位置，動畫一類
2、用來更新行為：攻擊、打出傷害等等
主迴圈會有多個物件列表比如說6個
主迴圈會將每一次的update標上記號。呼叫所有的物件的view更新方法和與標記相對應的物件列表的邏輯更新。
這樣就將所有的邏輯分攤到了各個幀數裡邊。讓各個幀數更平均一些。達到流暢的目的
遊戲效能 掉幀，記憶體過高 問題
前兩個星期懇求乙個顯示器，好緩解我的眼睛疲勞問題。今天居然直接給我配了個蘋果一體機。因為沒有多餘的顯示器 該mac無人使用 近期由於新遊剛上線，暴露出來的問題不少，上頭在寫新需求的同時給我分配了幾個效能優化的工作，具體就是爭取降低記憶體占用以及避免掉幀。網上結合書本研究了下cocos的大致渲染流程和...
高效能遊戲伺服器架構 快取清理策略
雖然使用快取思想似乎是乙個很簡單的事情，但是快取機制卻有乙個核心的難點，就是 快取清理。我們所說的快取，都是儲存一些資料，但是這些資料往往是會變化的，我們要針對這些變化，清理掉儲存的 髒 資料，卻可能不是那麼容易。第一種是使用控制命令。簡單來說，就是在伺服器程序上，開通乙個實時的命令埠，我們可以通過...
一種高效能網路遊戲伺服器架構設計
圖2的流程說明了，在選角色過程中，客戶端會把攜帶遊戲賬號和sessionkey的選角色協議發給gg，gg做一些簡單處理之後 給dbserver，dbserver要驗證sessionkey的合法性，驗證通過之後，dbserver會從角色資訊緩衝區裡取出該賬戶的所有角色資訊發給客戶端。這個過程在客戶端的...