#瞎子#

對(duì)于3d視頻游戲來(lái)說(shuō)，游戲引擎的性能是至關(guān)重要的。玩家在體驗(yàn)一款游戲時(shí)，游戲的流暢度是最基本的要求。與單機(jī)游戲不同，網(wǎng)絡(luò)游戲更需要考慮性能問(wèn)題，因?yàn)闊o(wú)法像單機(jī)游戲那樣，控制游戲元素的復(fù)雜度來(lái)達(dá)到效率的要求。大量玩家涌入同一片區(qū)域，同屏出現(xiàn)大量的游戲角色是無(wú)法避免的，因此游戲幀率的大幅下降，系統(tǒng)資源的大量消耗也很難避免，這是網(wǎng)絡(luò)游戲引擎最難處理的問(wèn)題之一。     這里要講一下游戲幀率的控制，通常玩家在玩游戲抱怨游戲客戶端卡有兩個(gè)意思，一是游戲平均幀率很低，二是游戲的幀率非常不穩(wěn)，導(dǎo)致了卡頓。實(shí)際上游戲平均幀率低，對(duì)玩家心情的影響遠(yuǎn)不及卡頓造成的影響。平均10幀的游戲，雖然已經(jīng)很糟糕了，但是依然能玩，但是頻繁的卡頓給人的感覺(jué)就糟糕透了，平時(shí)40幀左右的游戲忽然因?yàn)榧虞d個(gè)什么東西卡了一下，幀率掉到了零點(diǎn)幾，然后又恢復(fù)到40幀，這種卡頓給人的感覺(jué)就是煩透了。     游戲引擎首要解決的性能問(wèn)題就是卡頓的問(wèn)題。要解決卡頓的話需要做到以下兩點(diǎn)：     第一，不要在主線程去加載資源，最忌諱的操作就是打開文件，這個(gè)操作會(huì)掛起當(dāng)前線程，也就是說(shuō)會(huì)讓渲染線程停頓。把所有的資源加載操作全放在加載線程去做，畢竟加載線程隨便停頓也沒(méi)什么關(guān)系，對(duì)主線程的渲染沒(méi)影響，主線程只需要每幀判斷資源是否已經(jīng)加載上來(lái)就可以了。一但發(fā)現(xiàn)已經(jīng)加載上來(lái)了，就可以用這個(gè)數(shù)據(jù)去渲染了。     第二，也是最重要的一點(diǎn)，把加載的操作攤到多幀去做。通常角色走進(jìn)人堆里以后，或者在戰(zhàn)場(chǎng)上魔法漫天飛的時(shí)候，服務(wù)器會(huì)傳來(lái)大量消息需要處理，最典型的就是創(chuàng)建消息，無(wú)論是創(chuàng)建角色還創(chuàng)建特效，就算是采用多線程加載的方式，在一幀內(nèi)創(chuàng)建對(duì)象，通知線程加載底層資源，那么多消息的處理依然會(huì)不可避免地造成卡頓。這里有一個(gè)非常好的解決辦法，就是這些處理消息的操作不要一幀內(nèi)做完，而是分?jǐn)偟蕉鄮瓿伞?    一般說(shuō)來(lái)，處理網(wǎng)絡(luò)消息的過(guò)程是這樣一個(gè)循環(huán)： while( 消息隊(duì)列中還有消息 ) {    從隊(duì)列中取出第一條消息;    處理這條消息;    將這個(gè)消息從隊(duì)列中刪除; }     在一幀當(dāng)中，循環(huán)遍歷整個(gè)消息隊(duì)列，將這一幀收到的消息一個(gè)一個(gè)處理一遍。     這樣做忽略了最重要的效率問(wèn)題，當(dāng)你因?yàn)橛螒蚩D在焦頭爛額地優(yōu)化資源加載時(shí)，不放考慮修改一下消息隊(duì)列的處理。     在這里，我可以加入計(jì)時(shí)：GetTickCount()

初始時(shí)間 = GetTickCount(); while( 消息隊(duì)列中還有消息 ) {    從隊(duì)列中取出第一條消息；    處理這條消息；    當(dāng)前時(shí)間 = GetTickCount();    經(jīng)過(guò)時(shí)間 = 當(dāng)前時(shí)間 - 初始時(shí)間;    if( 經(jīng)過(guò)時(shí)間 > 20 )    {       break;    } }     如果這一幀的處理時(shí)間超過(guò)了20ms，則把剩下的消息放到下一幀處理。通過(guò)這種計(jì)時(shí)的方式，你會(huì)發(fā)現(xiàn)游戲的流暢度簡(jiǎn)直有了天翻地覆的變化！在優(yōu)化之前，有個(gè)幾個(gè)人在用群攻魔法攻擊大量的怪物，這些家伙忽然涌入到視野中，幀率便一下掉到了零點(diǎn)幾，游戲出現(xiàn)了非常嚴(yán)重的卡頓，這種狀態(tài)持續(xù)了很短一段時(shí)間，幀率又迅速回升上去。而現(xiàn)在，經(jīng)過(guò)修改以后，你會(huì)發(fā)現(xiàn)那些家伙很平滑地出現(xiàn)在視野中，沒(méi)有一絲的卡頓。如此效果簡(jiǎn)直是奇跡一般，而這一切僅僅是修改了幾行代碼而已。     現(xiàn)在考慮這么做所帶來(lái)的問(wèn)題。如果消息量非常大，而機(jī)器又慢，平均幀率又很低的話，那麻煩可就大了：每幀處理的消息量還沒(méi)有收到的消息量大。這可是個(gè)很嚴(yán)重的問(wèn)題，這會(huì)讓客戶端的表現(xiàn)與實(shí)際情況嚴(yán)重脫節(jié)。在這里，就需要有一個(gè)機(jī)制，保證消息在積攢超過(guò)一定數(shù)量時(shí)，能得到及時(shí)的處理：

初始時(shí)間 = GetTickCount(); while( 消息隊(duì)列中還有消息 ) {    if( 消息隊(duì)列中的消息數(shù)量 > 300 )    {       一次性處理所有的消息;    }    else    {       從隊(duì)列中取出第一條消息；       處理這條消息；       當(dāng)前時(shí)間 = GetTickCount();       經(jīng)過(guò)時(shí)間 = 當(dāng)前時(shí)間 - 初始時(shí)間;       if( 經(jīng)過(guò)時(shí)間 > 20 )       {          break;       }    }   }     這樣就解決了消息越積攢越多的問(wèn)題，當(dāng)消息越攢越多時(shí)，會(huì)一次性處理所有的消息。但這樣也會(huì)帶來(lái)一個(gè)問(wèn)題，那就是在幀率比較低的機(jī)器上，當(dāng)需要處理的消息特別多時(shí)會(huì)出現(xiàn)周期性的卡頓。卡頓的原因就是那步一次性處理所有消息的操作。優(yōu)化的目的就是要避免這樣的卡頓，而對(duì)于低端機(jī)器來(lái)說(shuō)，這樣的優(yōu)化不但沒(méi)有起到效果，反而加重了卡頓現(xiàn)象。為了彌補(bǔ)這個(gè)方法帶來(lái)的弊端，就要對(duì)那個(gè)經(jīng)過(guò)時(shí)間20ms做點(diǎn)手腳：

static 時(shí)間閾值 = 20;     //注意時(shí)間閾值是static的 if( 消息隊(duì)列中的消息數(shù)量 > 100 ) {    ++時(shí)間閾值; } else {    --時(shí)間閾值; } if( 時(shí)間閾值 < 20 )    時(shí)間閾值 = 20; if( 時(shí)間閾值 > 40 )    時(shí)間閾值 = 40;

初始時(shí)間 = GetTickCount(); while( 消息隊(duì)列中還有消息 ) {    if( 消息隊(duì)列中的消息數(shù)量 > 300 )    {       一次性處理所有的消息;    }    else    {       從隊(duì)列中取出第一條消息；       處理這條消息；       當(dāng)前時(shí)間 = GetTickCount();       經(jīng)過(guò)時(shí)間 = 當(dāng)前時(shí)間 - 初始時(shí)間;       if( 經(jīng)過(guò)時(shí)間 > 時(shí)間閾值 )       {          break;       }    }   }     這里增加了時(shí)間閾值這個(gè)靜態(tài)變量，替代了之前代碼中的20，使之成為一個(gè)由當(dāng)前幀消息包數(shù)量決定的一個(gè)可變的值。當(dāng)前幀消息包的數(shù)量超過(guò)一個(gè)值時(shí)，就將這個(gè)時(shí)間閾值加一，否則減一。這么做的效果就是，消息包來(lái)得越多，每幀用于處理消息的時(shí)間就越長(zhǎng)，也就是說(shuō)消息處理耗時(shí)的比重在逐漸上升。這樣就能很大程度上降低消息數(shù)量超過(guò)上限的可能性。 最差的情況，如果這樣做依然有周期性卡頓的話，這臺(tái)機(jī)器真的就不適合運(yùn)行這個(gè)游戲了，退一步講，不作這個(gè)優(yōu)化的話，這臺(tái)機(jī)器玩這個(gè)游戲也依然會(huì)卡得要命。：）    當(dāng)然，時(shí)間閾值的范圍，和消息包的數(shù)量上限可以調(diào)整，以適合于不同的游戲。