对于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,使之成为一个由当前帧消息包数量决定的一个可变的值。当前帧消息包的数量超过一个值时,就将这个时间阈值加一,否则减一。这么做的效果就是,消息包来得越多,每帧用于处理消息的时间就越长,也就是说消息处理耗时的比重在逐渐上升。这样就能很大程度上降低消息数量超过上限的可能性。
最差的情况,如果这样做依然有周期性卡顿的话,这台机器真的就不适合运行这个游戏了,退一步讲,不作这个优化的话,这台机器玩这个游戏也依然会卡得要命。:)
当然,时间阈值的范围,和消息包的数量上限可以调整,以适合于不同的游戏。
分享到:
相关推荐
cocos2dx升级spine3.8。解决多个相同动画同时加载卡顿的问题,自测可用,200个相同动画瞬间加载完成,不卡帧
unity2018.1的官方html版文档,自己花了1天写了专门的lua文件进行清理了超20000个html文件中导致html卡顿的js代码
使用RunLoop优化tableView加载大量图片卡顿问题,可有效解决主线程阻塞问题
网络游戏-网络直播客户端中弹幕输入框卡顿处理方法及系统.zip
解决fragment卡顿问题,还是可以的。让解决fragment卡顿问题得到解决。
unity2019.1的官方html版文档,自己花了1天写了专门的lua文件进行清理了超20000个html文件中导致html卡顿的js代码
懒加载或者可以说是延迟加载,针对非首屏或者用户”看不到”的地方延迟加载,有利于页面首屏加载速度快、节约了流量,用户体验好 实现方式 传统H5的懒加载方式都是通过监听页面的scroll事件来实现的,结合viewport的...
操作系统参操作系统参数配置不当引起系统并发访问卡顿排查方法操作系统参数配置不当引起系统并发访问卡顿排查方法操作系统参数配置不当引起系统并发访问卡顿排查方法操作系统参数配置不当引起系统并发访问卡顿排查...
这个方法的确可以解决ios5.0、android4.0以后系统的滑动卡顿问题。 -webkit-overflow-scrolling: auto | touch; auto: 普通滚动,当手指从触摸屏上移开,滚动立即停止 touch:滚动回弹效果,当手指从触
listview加载图片 遇到的卡顿问题,用原始的方法加载图片,不是开源框架卡顿问题 ,希望可以帮到大家,摸索中前进。
unity2020.1的官方html版文档,自己花了1天写了专门的lua文件进行清理了超20000个html文件中导致html卡顿的js代码
主要介绍了vue-router懒加载速度缓慢问题及解决方法,非常不错,具有一定的参考借鉴价值,需要的朋友可以参考下
Altium Designer中PCB移动卡顿卡屏解决办法
微信小程序中使用video组件播放m3u8直播视频,在ios的真机预览里点击video中间的播放容易卡几十秒,此时什么都做不了,手机也非常非常卡。 我的解决办法是在视频video组件里加入custom-cache={{false}} autoplay=...
减小CAD文件大小,解决CAD文件无法打开、卡顿、闪退问题。使用方法:APPLOAD命令加载插件,加载成功后,选择占用空间最大的内容,输入其对应序号,回车即可。
亲测好用的百度地图海量marker性能优化,包括重写的百度方法以及个人心得
ScrollView解决列表卡顿.zip
NULL 博文链接:https://chenleijava.iteye.com/blog/1868330
多线程解决界面卡顿,支持大量数据的显示
android项目中经常会接触到加载网络图片的情况,这里向大家展示几种最为常见访问网络图片的几种方式.rar,太多无法一一验证是否可用,程序如果跑不起来需要自调,部分代码功能进行参考学习。