我所遭遇过的游戏中间件--FlashOcx

      使用Flash做游戏界面的另一种方式是通过Abode提供flash.ocx处理Flash界面.将Flash图像通过GDI绘制出来后，再将图像数据拷贝到一个D3D的纹理结构中，最后由引擎的D3D接口进行渲染。用它来做游戏UI界面的好处就是方便,快捷.做出来的Flash在Abode的播放器中什么样,那么在游戏客户端中的就是什么样.不用担心什么显示不一致,脚本不支持之类的问题.另一方面,FlashOcx对AS脚本的处理效率比Scaleform强得多.但最大的问题就是渲染效率,毕竟需要做大量的像素拷贝工作,这很耗时.

      在项目中,一开始使用FlashOcx做UI界面,后来买了Scaleform,就成了两种并存的情况.再后来的两年半时间里,有若干次的想把所有FlashOcx的界面翻成Scaleform的.这个翻界面的工作不是我做,本来我认为不是什么难事,毕竟二者的资源都是Flash的SWF文件.但翻改起来,工作量比想像中的大得多.

      FlashOcx这个模块起初不是我写的,后来它的原作者走了,而正巧我在搞Scaleform,好歹与Flash有关联,于是这个模块的维护工作就落在我头上.整个集成代码可读性不强,完全是调用其接口,这一块没什么好说的,无非是依照着Demo,比着葫芦画瓢.好吧,我承认这一块我也不太熟悉.

      我对该模块做的最大的工作是实现了一套脏矩形合并算法.FlashOcx之所以卡,是因为像素拷贝耗时大.优化的办法自然而然就是降低其像素拷贝量.之前的矩形合并策略是简单的矩形合并方式，取更新矩形的作左上点和最右下点形成新的矩形.这种策略会导致这样的问题，如果左上角有一块小矩形更新，右下角有一块小矩形更新，合并的矩形就会相当大，从而重复绘制很多很多东西，导致效率低下。我写了一个脏矩形管理对象:

 1 class DirtyRects
 2 {
 3 public:
 4     LONG    left;
 5     LONG    top;
 6     LONG    right;
 7     LONG    bottom;
 8     std::vector<RECT> m_vecRect;
 9 
10 public:
11     DirtyRects();
12     void    Clear();
13     void    AddRect(const RECT& updateRect);
14 };

     外部只需调用若干次AddRect(updateRect),内部会自动对矩形进行分裂与合并.当矩形过于碎小时,会自动对其做合并处理.记得写这算法碰到的最多问题是该刷新的地方没有刷新,造成界面的残影.