我的脏矩形设计方案，探讨可行性。

微无渊

【简述】
窗口主表面以32×32的tile做划分，如800×600的窗口，划分为25列19行(18.75)
其中，每个tile有个BOOL标记，代表是否需要重绘


【具体】
1：执行BeginDraw()时，将所有tile设为“不需要重绘”状态
2：每绘制一个文本、图像时，记录该次绘制所占用的所有tile区域，然后将本次绘制任务压入链表
3：当执行EndDraw()时，从后往前依次计算各个绘制任务：
   ·检测该次绘制所在的所有tile状态，若存在需要重绘的，则将绘制对象本身设为重绘状态，然后继续计算下一个绘制任务，否则判断该次绘制是否有变化，若有变化，则将其所在的所有tile区域标记为重绘，并将绘制对象本身设为重绘状态。
4：将所有需要重绘的tile区域以指定背景色清空
5：从前往后依次执行每个绘制任务：
   ·检测该绘制对象是否为重绘状态，是则进行绘制
   ·将该绘制对象的重绘状态标记为FALSE


各位都是如何做的？交流一下。

funcman

想跟你说，市面上跑的很多2D游戏根本不用脏矩形

微无渊

funcman: Re:我的脏矩形设计方案，探讨可行性。

想跟你说，市面上跑的很多2D游戏根本不用脏矩形

恩，那请问我大体的设计思路没有问题吧？

sea_bug

可以的，不过好像2D游戏确实是不常用。

我以前做hoho引擎的时候，也支持脏矩形刷新，不过我分的块比你大一些，基本上800x600分4x3，在所有绘图操作时进行脏标记，最后在填充到显卡的阶段，来进行逻辑处理。

不过以现在的内存带宽和CPU速度，这点价值似乎没有很明显的作用。

微无渊

sea_bug: Re:我的脏矩形设计方案，探讨可行性。

可以的，不过好像2D游戏确实是不常用。

我以前做hoho引擎的时候，也支持脏矩形刷新，不过我分的块比你大...

谢谢大仙，明白了。

funcman

对于前后两帧，只要绘制的顺序和每步骤绘制的内容相同，那结果肯定是相同的。在绘制结果相同的情况下，顺序和内容可以不同。
脏矩形技术主要是按前面说的情况优化，后面的情况也可做优化，但一般没必要。
不采用脏矩形时，我们的绘制命令是立即执行的。采用脏矩形，我们需要从绘制命令流中提炼出那些是要绘制的。按tile划分的话，就是找到哪些tile在本帧绘制结束后，画面和前一帧不同。
并不是说只要绘制（发出渲染指令）就弄脏画面。我们关心的是结果的不同。不同则重新绘制（真正地去改变内存数据绘制）。
当然也有不提炼渲染指令流的算法，比如单独在画精灵时，把精灵的新位置做重绘，但这么做就失去了通用性。
发出渲染指令的模块不应该关心脏矩形是怎么运作的，不然模块间耦合太大。

所以不是每绘制一次就找对应位置的tile，而是每个tile都要记录本tile的渲染指令流，然后对前后帧指令流做对比，看看本tile是不是要重绘。对比指令流时，

此外要考虑滚屏。最好是tile根据场景划分而不是屏幕，tile对应场景，不显示的场景没tile，滚屏时要增删tile。这样做滚屏时，可以把前一帧的整个屏幕拷贝到新位置，删除一些tile，增加一些tile，再根据tile里的指令流提炼出哪些tile要重绘。

再就是UI什么的。UI都很大，又具备最后绘制的特性。UI的绘制可以不当作前面意义上的渲染指令。如果UI是不透明的，那么UI覆盖的tile可以不绘制了。但是现在的UI多是半透明的。

一旦画面中出现大的变化，比如全屏技能施放，脏矩形就没什么意义了。

微无渊

funcman: Re:我的脏矩形设计方案，探讨可行性。

对于前后两帧，只要绘制的顺序和每步骤绘制的内容相同，那结果肯定是相同的。在绘制结果相同的情况下，顺序...

恩，明白了。

paladin_t

做受限平台的话还是很有意义的，一些平台的填充率实在不怎么样；实现以下锻炼自己也不错。

tearshark

知道有个叫作云风的人吧?知道这人有套<风魂>的玩意儿吧?
找找代码,找不到的话找云风本人要吧.脏矩形已经被此人做到了极致了.

微无渊

tearshark: Re:我的脏矩形设计方案，探讨可行性。

知道有个叫作云风的人吧?知道这人有套<风魂>的玩意儿吧?
找找代码,找不到的话找云风本人要吧.脏矩形已经被此人做到了极致了.

恩，他的代码我经常查阅。代码优化高手啊！