GamerClass：10月16日：设计

GamerClass从根本上说应该是准备贴近于DDraw接口的，一是因为DDraw已经几乎成为了2D的标准，虽然目前正承受着3DSprite的冲击，并且本身已经没有了多少发展空间，但是，DDraw还是很适合用来做一个2D引擎的。一句话：简单就是最大的哲学。

图形引擎的图形方面肯定是重中之重，作为基本的功能，字体、图元、图像位块传送，都是必须要实现的东西，然后就是Alpha混合，2D图形学的一些算法，这就牵扯到了一个构架的问题。

引擎的首要目标是针对开发者，而不是游戏。因为玩家不会使用引擎，玩家使用的是游戏。引擎是开发者使用的，首先，难道一个引擎的开发者本人不是一个游戏的开发者吗？在中国，很多游戏的引擎和开发者是共通的，游戏就意味着引擎，引擎就意味着游戏，我也一样，只不过更蠢一点罢了。

尽管JAVA针对手机游戏的2D工具库可以作为借鉴，但是我还是决定自己来思考，GamerClass只是一个实践，不是一个解决方案，也不是一个答案，所以，自己思考，然后在借鉴别人的东西，似乎是一条更好的学习思路。

在图形上面，资源系统是肯定必要的，尽管Demo未必会出现显存不足等等BT情况，但是这不是我们将这个问题排除在外的理由。资源系统的主题就是对图形显示相关的资源：包括Surface和字体进行管理。Surface管理对于DDraw时代最烦心的问题：应用程序焦点问题是一个很好的帮助。而资源系统的设计有两个基本的方案，一个是COM方案，一个是HANDLE方案。COM就是大家都会的ADDREF和RELEASE，而HANDLE则更进一层，使用HANDLE来避免开发者“无意中忘却ADDREF”。更进一步的，Gem4有写，我想那个是很经典的。

资源系统的类，可能会有下面的：

Resource和ResourceManager，提供Handle管理等基本的逻辑和内容

Image和ImageManager，提供图片Surface的管理。

Font和FontManager，封装Font。

这里是准备把Surface分成两个部分，一个是来自于文件的ImageSurface，受制于资源系统。另一个是属于可进行渲染的RenderSurface，不受制于资源系统。

那么下面就是画布这一块儿，DDraw可直接获取BackBuffer，所以这算一个画布应该没有问题。其他的，大部分情况下我们还会创建一些离屏缓冲，就算是RenderSurface，专门进行管理。这些离屏缓冲采取什么样的索引方式还是一个头疼的问题，文件ImageSurface可以通过文件名索引，这些在游戏运行中被动态生成的，用来做些奇怪作用，比如画上两根线什么的，怎么索引呢？汗一个。再考虑。

画布的其他组件可能包括一个Camera，这个是跟D3D学的，至于Viewport……就免了吧。Camera也不用变大小了，只能与屏幕等大。Camera在引擎层提供，通过Camera直接在引擎层进行可见筛选等内容，

最后是渲染物的部分，图元，这应该是必须提供的了，2D除了位块传送就是图元，但这不是主要的内容，主要的就是对位块传送的封装，这中间当然应当把Alpha直接算在内了。

基本的模块就是这样了，唉，开始努力……