• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            清風竹林

            ぷ雪飄絳梅映殘紅
               ぷ花舞霜飛映蒼松
                 ----- Do more,suffer less

            轉載—網絡游戲程序中解決加載卡頓的有效方法

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

             

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

            初始時間 = GetTickCount();
            while( 消息隊列中還有消息 )
            {
               if( 消息隊列中的消息數量 > 300 )
               {
                  一次性處理所有的消息;
               }
               else
               {
                  從隊列中取出第一條消息;
                  處理這條消息;
                  當前時間 = GetTickCount();
                  經過時間 = 當前時間 - 初始時間;
                  if( 經過時間 > 20 )
                  {
                     break;
                  }
               }   
            }
                這樣就解決了消息越積攢越多的問題,當消息越攢越多時,會一次性處理所有的消息。但這樣也會帶來一個問題,那就是在幀率比較低的機器上,當需要處理的消息特別多時會出現周期性的卡頓。卡頓的原因就是那步一次性處理所有消息的操作。優化的目的就是要避免這樣的卡頓,而對于低端機器來說,這樣的優化不但沒有起到效果,反而加重了卡頓現象。為了彌補這個方法帶來的弊端,就要對那個經過時間20ms做點手腳:

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

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

            posted on 2009-12-30 14:00 李現民 閱讀(482) 評論(0)  編輯 收藏 引用 所屬分類: 絕對盜版

            无码国产69精品久久久久网站| 精品久久久久久无码人妻蜜桃| 国产69精品久久久久APP下载| 欧美日韩久久中文字幕| 综合久久国产九一剧情麻豆| 午夜天堂精品久久久久| 国产AV影片久久久久久| 亚洲va久久久噜噜噜久久| 久久久久国产视频电影| 看久久久久久a级毛片| 国产精品99久久久久久www| 777午夜精品久久av蜜臀 | 色狠狠久久AV五月综合| 久久九九有精品国产23百花影院| 久久影视国产亚洲| AV色综合久久天堂AV色综合在| 中文字幕无码久久人妻| 99久久国产综合精品成人影院| 熟妇人妻久久中文字幕| 亚洲国产成人精品91久久久 | 国产精品久久久久久久久鸭| 国产精品嫩草影院久久| 国产精品天天影视久久综合网| 久久久久久精品久久久久| 久久精品国产亚洲Aⅴ香蕉| 国内精品久久久久| 久久精品国产第一区二区三区| 久久天天躁狠狠躁夜夜avapp| 久久久久国产一区二区| 国产精品免费久久| 国产精品无码久久综合网| 色综合久久88色综合天天| 国产精品国色综合久久| 久久99精品久久久久久久不卡 | 精品久久久久久久久久中文字幕| 国产精品久久久久久久久免费| 久久精品天天中文字幕人妻 | 午夜不卡888久久| 国产高潮国产高潮久久久91| 99久久综合国产精品二区| 91精品观看91久久久久久|