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

jekeyhui99

先给出我的机器配置，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。