篇文章节选
贴上来请各位指教
目前
限制2D游戏速度瓶颈主要是大量在内存/显存中传输图像数据所造成帧800*600*16bit图像数据量差不多有1M要不断在内存/显存间传输秒钟要处理数据量是相当大般我们为了使游戏更加丰富多彩总希望游戏有更高分辨率、颜色数以及更多卷轴、精灵等等这些无不是以增大图像数据传输量为代价单纯靠提高位图传输速度来解决显然不是办法
传输速度是由硬件传输带宽决定无论你如何优化都不会有很大提高另外尽管显存的间传输带宽非常大但是对于软件Software渲染引擎来说又用不上也是行不通看来我们只有从算法和总体设计上另想办法 从2D游戏画面产生
特点我们可以看出无论什么2D游戏相邻两帧画面总有定连续性换句话说相邻两帧画面改变量并会很多因此在生成每帧游戏图像时候我们没有必要重画全部画面而只需要重画那些改变部分就可以了这样子就可以节省下大量数据传输带宽了另外对于有多层画面地方下面被遮挡部分画面完全没有必要绘制我们也可以在这个方面想办法优化 对于前者
优化我们可以采用脏矩形(dirty rect)算法即对每处画面将有改变(例如个精灵需要重绘)地方定义个脏矩形每次绘制时候只对脏矩形内画面进行绘制那么对于有地图卷轴情况又该如何处理呢？这个时候我们需要定义个比屏幕更大帧缓冲区只要改变帧缓冲和屏幕对应关系就可以实现地图卷轴这样就不需要在每次地图卷动时候重绘整个地图了 对于后者
优化则并不容易在3D中我们可以使用Z-Buffer避免重绘那些被遮挡像素点在2D使用Z-Buffer则显然得不偿失我们还是回到使用矩形裁减思路方法对于般对话框这类正规矩形界面元素直接定义裁减矩形就可以了但问题是般精灵都不会是矩形该如何解决这个问题呢？ 我们可以使用
在精灵内部计算生成出系列裁减矩形列表这些裁减矩形将把前面绘制被遮挡部分裁减掉使其不被绘制但是要注意如果裁减矩形太小花在裁减上时间就可能超过绘制时间那就得不偿失了因此我们还应该规定个裁减矩形最小面积小于这个面积矩形将不被添加到列表中当然如果觉得生成列表太麻烦也可以只保留最大那个裁减矩形另外对于半透明图面则不能生成裁减矩形 好了
说了那么多现在让我们来整理下这个算法具体过程 第
步:生成所有图面裁减矩形列表这步是预计算 第 2步:在每帧游戏渲染
过程中记录下所有游戏渲染图面以及脏矩形在更新屏幕时次性渲染到帧缓冲并输出到屏幕这就是异步渲染机制 第 3步:对每个脏矩形进行渲染
第 4步:每个脏矩形
渲染过程为:每个要渲染图面将按画家算法从前到后渲染将每个图面裁减矩形列表也按这个绘制顺序排列生成个总裁减矩形列表将裁减矩形列表作用于每个要渲染图面上将被遮挡部分裁减掉每渲染完个图面就将这个图面裁减矩形在列表中删除并进行下个图面渲染工作直到完成渲染 使用这个算法还要注意矩形间
合并另外还要针对游戏具体情况来做权衡不然很有可能会得不偿失
最新评论