Home » 未分类 » 基于GPU硬件加速2D网页游戏渲染的实践经验总结

基于GPU硬件加速2D网页游戏渲染的实践经验总结

  • 技术选型

    传统的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的性能是有瓶颈,但是其瓶颈也没有很多人想象的那么低。最后把咱们游戏地址放出来,欢迎拍砖!

http://xygl.52xiyou.com

    分享到: