-
技术选型
传统的Flash页游大多采用CPU渲染，也就是Bitmap + BitmapData 渲染方案。但是CPU渲染瓶颈比较低，只要角色数量稍微增加，FPS就会直线下降，开发者不得不采用屏蔽玩家的方式，来保障游戏的流畅性。Adobe Flash早在2011年便推出Stage3D API，使得Flash 开发者也可以直接操作显卡进行渲染。在绘图方面，显卡是专门针对并行计算优化的计算设备，与CPU的4核8核比起来，显卡的流处理单元数量往往成百上千个，其渲染性能根本不是在一个量级。
这里提供一个非常有趣视频链接，看看Nvidia的工程师如何演示CPU与GPU的绘图原理。
http://v.youku.com/v_show/id_XMTQ5MDM1MTQ4.html?from=s1.8-1-1.2&spm=a2h0k.8191407.0.0
既然决定要改用基于Stage3D的硬件加速方案，那么我们继续看下，当前采用Stage3D渲染2D游戏的方案有哪些可供选择？
-
Starling框架（代表作：《天书世界》）
Starling是荷兰制作《愤怒的小鸟》那家公司开源的一个很方便使用的Flash GPU渲染解决方案。也是Adobe官方推荐一款跨平台（移动端+PC端）的游戏开发框架。具有成熟的开发者社群，大量免费的第三方扩展可以拿来便用。它的强大之处是在于批量渲染对象。但它的弱点是批量渲染需要将对象的纹理都打包在同一张纹理上，而且X、Y坐标不能发生改变，一旦发生改变，就需要重新计算顶点，然后重新上传顶点到GPU中。对于ARPG游戏的特性而言，顶点的计算和上传的消耗变得相当高。
所以，如果不对Starling做针对性的优化，那么GPU在ARPG游戏渲染加速中的作用将十分有限。
-
FrameBone框架（代表作：《风云无双》、《九天星辰诀》、《霸王大陆》）
是一款非开源的渲染框架，相对比较封闭。据说一开始起源于第七大道。《风云无双》中期的时候，是一个来自七道的兄弟给把底层渲染从CPU切换到GPU，就是采用的这套方案。据说性能表现要比Starling的好不少。那个时候，我对GPU渲染的认识还不是很多，很多概念比较模糊。虽然有frameBone的源码和配套工具，但是阅读起来很是费劲。所以当我准备着手研究Stage3D的GPU渲染的时候，FrameBone并未纳入我计划之内，因为缺少文档，代码不易理解，对于一个新手而言，上手难度确实有点太高了。后来有幸认识了FrameBone的原创作者，得知，FrameBone除了渲染效率不错之外，还有强大的动画编辑器。通过这套动画编辑器，可以使用非常少量的图片素材，通过各种旋转变换和缓动，就可以实现相对复杂的特效。这对Flash进行显卡渲染有个非常重要的帮助就是大大减少资源内存的消耗。对于大型ARPG游戏来说，这块的开销，的确是个瓶颈。后面，我会介绍下，我们的节省内存的解决方法。
-
Dze框架（代表作：《盛世三国2》）
dze这个名字，其实是我取的。因为我也不知道这个框架叫什么名字。我只是在《盛世三国2》的破解代码里，看到这个包名称，于是暂且把这套渲染思路命名为dze。Dze具体有什么特别之处呢？Dze除了是心动网络自主研发的渲染框架，它的独特之处在于，直接放弃了Starling的批量渲染的方案，在顶点上传这块做出了优化，更加适合ARPG游戏场景。顶点数据优化，stalring的做法是，将一个图的x，y，scale，rotation等等值，都存在vertexbuffer里面，这样，当图只要有一点变化，就需要重新upload数据，这是一个很大的消耗。所以，作者将顶点数据只保存uv和宽高，而x、y等值，交由常量着色器，最后由agal算出实际位置。这样，每张图片的vertexbuffer，只和图片的宽高有关（uv是通过宽高算出来的），即使图片移动，也不需要更新vertexbuffer了，设置常量着色器，很快的。作者技术探讨帖子地址如下，想了解详情的请戳这里。 http://bbs.9ria.com/thread-206282-1-1.html
-
其他ND2D/Genome2D
资料较少，所以暂未考虑
-
最终渲染方案：
以Starling框架作为母体，吸取后面两种解决方案的优点，但是又保留Starling自身的批量处理的优势。经过countless of hours的不懈努力和优化，我们的这个渲染引擎具备了一下优点：
- 保留Starling 友好的DisplayList接口
- 保留Starling保留Starling批量渲染的威力（主要用于渲染脚底特效和头部的血条已经怪物名字）。这里需要用到一种特殊的分层渲染机制。
- 角色、部件、坐骑、法宝、技能特效，采用改良的渲染算法，省去顶点的频繁上传，可大幅提升性能。原理与《盛世三国2》dze框架的优化思路差不多。
- 开拓性的采用自主研发的纹理分割重组打包算法，大幅节省内存开销。传统的资源打包，空白率非常高，而我们把纹理切碎，然后以更加紧凑的方式排列，可大幅压缩纹理内存。根据统计，纹理内存节省率为30-50%。基本上解决了纹理内存不足这个瓶颈性的问题。
-
最后补充：
经过实测，在本人一台非常普通的办公电脑上（连独立显卡都没有），300人同屏PK，包括各种技能特效、各种角色部件，在内存上没有太大压力，在性能上也是杠杠的。稍微好点机子上可以跑到400多人，60fps 。但是前端模拟实测，终究只是模拟实测，游戏具体运行效果，除了渲染这个块之外，消耗性能的地方还有很多。比如当游戏研发走到中期，随着功能系统模块不断添加进行来，游戏也会变得越来越卡顿。具体问题具体分析，这个时候，就需要花时间放在业务代码质量的控制之上。底层引擎代码+业务层逻辑代码就好比一个木桶。这个木桶能装多少水，取决于短板。
如何优化业务层代码，我前面的有好几篇博文是探讨这块的。这次算是把比较核心的底层设计拿出来和大家探讨，也希望能帮助到更多的页游开发团队。也希望让更多的人知道，Flash的性能是有瓶颈，但是其瓶颈也没有很多人想象的那么低。最后把咱们游戏地址放出来，欢迎拍砖！