吾知网

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 6190|回复: 0

用stage3d加速2d arpg游戏的性能测试和处理思路

[复制链接]
发表于 2016-8-15 13:57:17 | 显示全部楼层 |阅读模式
先给出我的机器配置,dual-core E6700    3.2GHZ,4G内存,显卡ATI Radeon 5450,应该算是普通配置

给出性能测试结果,可以看到左上角输出的数据,人物数500,贴图数451,每帧draw call次数1708,大概能达到57帧,cpu 37%。
500个人,基本都分四部分,头发,身体,武器,马匹,头发和马匹基本一样,身体的武器差别比较大。人物站立动作有多帧,一直在不断变化。








可能很多人觉得这个性能不行啊,远远不如starling,ND2d等框架的性能,starling有些测试,同屏能达到几千,甚至上万呢。
那还有啥可说的呢?
很多同学都知道,starling等的高性能,来自于批处理,将很多图片打包到同一张texture上,很多图同时一次绘制,减少绘制批次,从而得到了很高的性能。
而且很多stalring等引擎的测试,缺少一些实用性,很多测试,同屏人物,就几种图,完全可以做到一张贴图上,这样,就算有几千人,可能也只需要几次draw call。


但是在实际项目中,我们遇到的情况,将复杂得多,这种做法到拿到页游上,特别是arpg内的页游上,是否适用呢
首先,假设同屏200人,考虑极端情况,同屏的人物大多数人都是不一样的,并且一个人由很多部分组成,例如头,身体,武器,马匹,甚至现在流行的翅膀。
想要将这么多图打包到贴图上,是不可能的,并且由于人物都是随机的,我们不能预先将图打包到一起。
这样,想要批处理,就产生了两个思路:
        1,动态打包,根据人物当前的身体,武器,马匹等部分,动态地将每部分的bitmapdata拼接在一起,再生成texture,上传GPU。
                但是这样做,如果两个人,身体一样,武器不一样,身体就会被处理两次,大大浪费了可贵的显存,并且需要保存好多份额外生成的bitmapdata,又浪费了内存。
        2,将人物的每部分图一开始就打包到一起(texturepacker的做法),例如身体的行走,站立,攻击等打包在一起,武器的行走,站立,攻击打包在一起。寻求同样的,然后批次渲染。例如A和B的身体一样,就先同时渲染AB的身体,再渲染A的武器,最后是B的武器。
                这种方法,命中率很难保证,并且,cpu计算是宝贵的资源,这种处理可能会消耗很多计算,而且将贴图上传,也是一个耗时的操作,这种做法,会需要不停地拼接,上传,销毁,是一个几乎不可行的方案。
                并且存在渲染先后顺序的问题,也就是深度的问题,在此就不细说了。(有同学会说,深度可以用z缓冲来解决,同学可以试试再说)

不知道我描述清楚没有,总之,考虑到实际项目中可能遇到的各种问题,批处理是一个不太可能的方式。
同时,我也用starling,做了测试,同样是上面的需求,(500个人,基本都分四部分,头发,身体,武器,马匹),只有10帧左右。因为没有了批处理的威力。

所以,不得不换个思路。不做批处理,从其他方面来找性能。
原则就是,减少cpu计算,不优化draw call次数
思路大概有3方面:
1,贴图重用,这个是基本的,和我们重用bitmapdata一个概念,就不多说了。
2,顶点数据优化,stalring的做法是,将一个图的x,y,scale,rotation等等值,都存在vertexbuffer里面,这样,当图只要有一点变化,就需要重新upload数据,这是一个很大的消耗(试一下多张不同贴图图片静止和随机运动的效率就知道了)。
        所以,我将顶点数据只保存uv和宽高,x,y等值,交由常量着色器,最后由agal算出实际位置。这样,每张图片的vertexbuffer,只和图片的宽高有关(uv是通过宽高算出来的),即使图片移动,也不需要更新vertexbuffer了,设置常量着色器,很快。
        这大大解决了当移动的时候,大量重算重传vertexbuffer的问题。所以,人物移动和不移动,几乎没有渲染性能差别(差别在cpu处理移动逻辑的损耗上,无可避免)。并且,相同宽高的图,可以共享顶点数据。
3,资源回收,GPU的资源是十分有限的,必须回收。基本原理就是根据上次使用时间回收,每隔一段时间检测一次,长期没用就回收。回收时间应该是浮动的,如果资源快用完,就要减小回收时间间隔,如果资源还很多,就拉长时间间隔。
        这里最好是分开处理每个资源的回收,这样,资源的回收时间就是随机分布的,不会集中在某一帧统一回收,导致严重掉帧。

其中,最重要的思路转变是第二点,这样处理,大大减少了CPU的运算,即使draw call次数看起来很高,帧率依然保持不错。
后期如果加上更多的游戏逻辑等其他处理,肯定不能保证同屏这么多人,但是,我想,能做到200人PK60帧,已经非常满意了,也满足大多数页游arpg的需求了。
而如果固守strling的处理机制,在实际运用中,同屏人数就很难保证了。

当然,stalring有其很好的好处,友好熟悉的接口,很好的扩展,社区的支持,等等等等。
但是,它考虑了太多东西进去,很多是和我们实际项目需求无关,我们就应该学习其好的方面,然后根据自己的需求,做出自己的东西,争取自己的效率。(我做arpg的渲染,就不必考虑回合制的渲染做法,对吧)



另:贴图的大小也会影响性能,画一张大图,肯定比画一张小图慢。所以,当人物的朝向改变,例如向左,因为侧面图片大了(主要是马匹),所以性能会略下降,当500个人的朝向都是左,掉到40fps。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Archiver|吾知网 ( 粤ICP备13013563号-1 )

GMT+8, 2024-3-29 15:47 , Processed in 1.093750 second(s), 10 queries , Memcache On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表