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直接算在内了。
基本的模块就是这样了,唉,开始努力……