• <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>

            3d Game Walkman

            3d圖形渲染,網絡引擎 — tonykee's Blog
            隨筆 - 45, 文章 - 0, 評論 - 309, 引用 - 0
            數據加載中……

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

            對于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-02-28 13:47 李侃 閱讀(1450) 評論(2)  編輯 收藏 引用 所屬分類: 前臺客戶端

            評論

            # re: 轉載—網絡游戲程序中解決加載卡頓的有效方法  回復  更多評論   

            對于分攤到多幀的方案,確實身有體會,記得以前做過一個游戲模板數據查詢的工具,是用MFC做的,由于一次性查找到的數據過多,一下子加載到列表控件中會引起很嚴重的停頓,于是我便學游戲的樣子將其放到多個幀中處理,程序仍然是單線程,但立馬流暢了很多。
            2009-08-10 22:01 | 李現民

            # re: 轉載—網絡游戲程序中解決加載卡頓的有效方法  回復  更多評論   

            嗯,不錯,學習了。
            2010-03-10 09:55 | 月隱
            91精品无码久久久久久五月天| 亚洲国产香蕉人人爽成AV片久久| 无码国内精品久久人妻蜜桃 | 久久93精品国产91久久综合| 久久福利片| 久久天天躁夜夜躁狠狠躁2022| 亚洲欧美日韩中文久久| 热99re久久国超精品首页| 久久国产美女免费观看精品| 伊人热热久久原色播放www| AV无码久久久久不卡网站下载| 国产精品九九久久免费视频| 国内精品九九久久精品| 99精品久久久久久久婷婷| 亚洲香蕉网久久综合影视| 久久综合九色综合久99| 中文字幕日本人妻久久久免费| 久久免费高清视频| 无码AV中文字幕久久专区| 久久精品一区二区三区中文字幕| 无码AV中文字幕久久专区| 亚洲伊人久久综合中文成人网| 天天久久狠狠色综合| 久久久无码精品亚洲日韩蜜臀浪潮| 久久久久亚洲爆乳少妇无| 精品午夜久久福利大片| 色偷偷偷久久伊人大杳蕉| 波多野结衣久久一区二区| 狠狠色综合网站久久久久久久| 青青青伊人色综合久久| 国产91色综合久久免费分享| 久久WWW免费人成一看片| 久久亚洲熟女cc98cm| 精品久久久久成人码免费动漫| 久久人人爽人爽人人爽av| 国内精品久久久久久麻豆| 亚洲嫩草影院久久精品| 伊人久久免费视频| 激情五月综合综合久久69| 狠狠久久综合| 欧美一级久久久久久久大|