M8SDK教程-游戏开发心得（三）:DDraw进阶教程-贴图,Alpha和Sprite动画,RPG游戏雏形

M8SDK教程-游戏开发心得（三）:DDraw进阶教程-贴图,Alpha和Sprite动画,RPG游戏雏形

引用:
M8SDK教程-游戏开发心得（一）: 游戏程序框架
http://bbs.meizu.com/thread-957024-1-4.html
2009-05-18
WM_ACTIVATE已处理,感谢linuxlt的提醒.

M8SDK教程-游戏开发心得（二）: DirectDraw基础
http://bbs.meizu.com/thread-968949-1-1.html
2009-05-25

M8SDK教程-游戏开发心得（三）: DDraw进阶教程-简单贴图,Alpha半透明效果和Sprite动画
http://bbs.meizu.com/thread-981601-1-1.html

2009-12-04 屏幕闪的问题,请看80楼
题外话:
前面2章的教程受到了很多朋友的欢迎,对于自己写的东西能帮助到很多朋友我感到很欣慰.
这里非常抱歉这次教程迟了一些出来.因为这次要写更多的代码,本人水平有限,且遇到了一些比较郁闷的技术问题(稍后会讲到),实在解决不了也只好仓促发布了.
闲话少叙,本次是游戏开发心得系列教材的重头戏了这次我们将会讨论到游戏场景的编程设计,贴图,alpha半透明效果,Sprite动画.这些都是真功夫哦,呵呵.
在前面2章讲的理论性的东西比较多,有些朋友看着不是很有趣,所以这一次我写了很多代码,重点进行代码实现的讲解.为了演示Sprite我还大概做了一个RPG游戏人物的行走效果,呵呵,算是RPG游戏的一点点技术原型.

下面我们正式开始,由浅入深的来看这几个例子:

游戏场景
从前面2章的例子我们可以看到我们的游戏窗口只有一个,但是我们需要在这个窗口里实现多个场景.何为场景呢?在开发者的眼中,游戏的进入菜单,游戏loading画面,RPG的人物行走,战斗,状态等等都是独立的场景.为了便于开发,我们需要将它们从逻辑上分开.因为这次我要演示好几个独立的效果,所以我也实现了一个山寨版的"场景"的架构,供大家参考.
我定义的场景类名为CMyScene,类定义如下:






1.png (18.53 KB)

2009-6-2 22:25

我们来看代码,当主窗口创建时,我们调用了CreateScenes用于创建场景.






2.png (16.61 KB)

2009-6-2 22:25

上面的代码中,我们创建了4个场景,同时将第一个菜单场景设为当前场景. 在主窗口的RenderFrame函数和各个处理常用消息的函数中,我们都直接调用了默认场景的对应函数,这样就把绘图和消息的控制权直接转移到了场景内部,我们可以直接在各个场景内写我们的逻辑,实现代码的清晰分离.
我们看看场景内的代码






3.png (34.56 KB)

2009-6-2 22:25

以CMenuScene(主菜单场景)为例,可以看到,在初始化时,我们顺序创建了几个button(我自己实现的,感兴趣的请看源代码),并分别赋予了CommandID,用于按钮点击产生的事件处理.这些事件可用于场景切换和其他的特殊处理(按钮点击等的处理写在基类里了,这里就不具体说了,感兴趣的朋友可以看看).

简单贴图:
我们之前的例子都只是使用了GDI函数输出文字,非常土鳖,现在我们终于可以开始贴图了!
我记得在Win32编程的时候,载入位图一般都用LoadImage这个API,这个函数只能载入BMP,其他格式只能用第三方类库或者自己写,在绘图的时候还要用DC做好几次转换,非常麻烦.在M8里,你仍然可以使用LoadImage,但是我们已经有了更好的选择: ImageHelper. ImageHelper是基于WinCE Imaging COM接口的封装,可以支持多种图像格式.同时支持带Alpha通道的PNG图像,功能很强大.
贴图的例子写在CBlitScene场景中,我们来看初始化代码:






4.png (30.88 KB)

2009-6-2 22:25

创建了2个按钮之后,我们使用ImageHelper的LoadImageFromRes方法从资源中直接加载PNG图像,下面是我们已经熟悉的创建缓存Surface的步骤,最后,我们从ImageHelper直接绘图到缓存Surface中.在这里我们为什么要使用一个缓存Surface呢?为什么不使用ImageHelper直接绘图到BackBuffer呢?这是因为DDraw对Surface之间的Blt是硬件加速的,但是如果我们直接从ImageHelper绘图到BackBuffer是没有硬件加速的,如果每次都这样绘图,会牺牲我们的绘图性能.所以尽可能的使用Surface来缓存位图数据是必要的选择,当然Surface容量是有限的,在复杂的游戏中,我们不可能每次在游戏开始的时候就把所有素材都加载到Surface中,但是我们可以按场景等单位加载位图,尽可能的进行优化.大家见过大部分RPG在场景切换都是要Loading的吧,呵呵,它们很可能就是在加载图像到Surface中哦.
下面来看CBlitScene的RenderFrame方法:






5.png (18.26 KB)

2009-6-2 22:25

我在这里做的工作比较简单,计算源矩形和目标矩形,然后将位图从缓存Surface拷贝到BackBuffer Surface.这样我们就实现了每次RenderFrame都显示同一个位图.
简单贴图效果如下:






6.png (53.21 KB)

2009-6-2 22:25

Alpha半透明
Alpha半透明是一种非常重要的效果,有了它可以做出很多绚丽的游戏画面.但是这个例子我遇到了一些难以解决的问题.其实我已经不想把这个例子加上来的,因为功能远未达到我要求的效果,不过觉得把问题拿出来大家讨论也许更好吧.我们先来看代码,然后我来说局限性.
这个例子使用CAlphaScene场景,首先来看初始化的代码:






7.png (28.65 KB)

2009-6-2 22:25

在创建完该场景的按钮之后,我们仍然使用ImageHelper来载入位图,不同的是,最后一个参数我们改为true,用于正式支持Alpha通道.之后将图像加载到surface中.






8.png (15.88 KB)

2009-6-2 22:25

在绘图函数这种,比较重要的是我们使用了AlphaBlt方法,这是DDraw中支持硬件加速的半透明实现方法.该方法需要传入一个DDALPHABLTFX结构体,用于填充Alpha数据.在这个范例中我们仅仅改变Alpha值来实现半透明的效果.
该范例运行效果如下:






9.png (12.51 KB)

2009-6-2 22:25

这个范例其实存在巨大的问题:
1. 有时候效率很低下,在范例中最快的时候6ms,慢的时候100多ms,你在看代码的时候会发现绘图前先GetDC,随便绘了点文字(空的都行),这是因为我发现通过这样做,速度就会正常,否则AlphaBlt就很慢.这是什么怪原因?是否因为我没有指定该Surface在内存中呢?
2. 这个函数的最大缺陷就是不支持关键色,何为关键色?就是绘图时,你希望被抠掉的背景色.在Blt函数中关键色可以通过设置参数很好的支持,但是AlphaBlt这个函数竟然不支持设置关键色,而奇怪的是,在CE5.0的这个函数是有关键色这个参数的,竟然在CE6被取消了?(微软的人脑子也进水了?)我曾经尝试使用Alpha通道来解决,但是由于DDraw没有提供对PNG的原生支持,仅仅通过bitblt方式无法将关键色拷贝到Surface当中去.所以,我觉得不能去掉绘图时的背景色极大的限制了该函数的应用.我今后会有时间再研究下看看能否解决这个问题.

Sprite动画
Sprite动画的原理其实和动画片差不多.看我们这个范例的素材(天之痕中的陈靖仇,呵呵,别告诉我你没玩过天之痕):






sprite_2.png (81.98 KB)

2009-6-2 22:26

这些是阿仇各个方向的行走图,通过把每个方向上的图在很短的时间内连续显示,在我们看来就基本形成动画效果了,Sprite动画可是2D游戏,尤其是RPG游戏的实现基础,应用还是很广泛的.通过这范例,我演示了Sprite动画,而且还是实现了人物在地图中的行走(当然,这里没有地图了,所以用了一个重复背景来替代).

这个范例放在CSpriteScene场景中,下面我们来看代码:






11.png (30.21 KB)

2009-6-2 22:25

初始化代码和上面的大同小异,但是有些不同的是,在绘Sprite的时候我们必须要擦掉Sprite的背景了,这时候要用到我们刚才提到的关键色了,通过DDSetColorKey这个函数(从微软DDraw的范例代码里copy出来的),我们设置了Surface的关键色,一会在绘图的时候会用到.

下面我们来看看"阿仇快跑"的实现逻辑.
我们可以设想一下,RPG游戏人物的移动一般都是人物在屏幕中间摆出移动的动作,但是人物并不做实际的移动,反而是游戏背景进行滚动,这样你会发现,游戏主角始终在屏幕中间,但是看起来人物也移动了.
所以按照此原理我们只需要在每次屏幕点击时,计算点击坐标和屏幕中心坐标的偏差,就可以确定移动方位了.在不断播放Sprite动画的同时,将背景一点一点沿人物移动的反方向移动就可以实现我们需要的效果了.
来看代码:






12.png (3.49 KB)

2009-6-2 22:25

首先用一个enumn来定义了行走方向,这个定义和素材图的方向顺序保持一致,一会贴图的时候便于我们的计算.

然后我们看看屏幕点击事件的处理:






13.png (33.08 KB)

2009-6-2 22:25






14.png (12.52 KB)

2009-6-2 22:25

在这里,我们通过计算x和y左边的偏差来判断阿仇移动的方向,我们设计了8个方向: 上下左右,左上,坐下,右上,右下,通过计算可以比较容易的计算方向,并且记录阿仇需要移动的x,y轴步长.设置m_bStartMove为true作为阿仇开始跑步的状态,最后把这一次的步长记录下来备用.

我们来看我们每次的绘图函数都做了什么:






15.png (27.01 KB)

2009-6-2 22:25






16.png (11.01 KB)

2009-6-2 22:25

首先根据我们移动的步长绘背景(为了偷懒,背景采用的是无缝连接的循环绘图方法,这里不是重点,大家自己看看代码好了). 之后,我们修正绘图帧数,开始画Sprite(一会分析具体代码),之后的代码判断跑步是否结束,如果结束则将帧数恢复到0(站立状态),如果屏幕依然处于依然被按下状态,则说明阿仇需要持续不断的跑,我们取出刚才记录的步长,继续进行跑步动作.如果跑步没有结束,则需要对路径方向做修正,这是为什么呢?这是因为我们只设计了8个移动方向,但是真实的移动方向则可能是任意度,所以我们需要随时判断是否x,y轴一个方向已经和终点一致,如果是则需要改变移动的方向.下面的代码就是进行每一次的移动了,同时,我们在一定间隔更行一个frame来绘图,这样阿仇的步伐看上去就比较舒服,不快也不慢.

来看看我们Sprite绘图的核心:






17.png (23.56 KB)

2009-6-2 22:25

这里的代码其实很简单,我们通过移动方向就确定了画sprite的哪一行,通过刚才函数的计算,就确定了画哪一帧,由此我们直接计算出相应的Sprite位置,把这个矩形区域拷贝到BackBuffer上.注意这里启用源图关键色的方法,设置DDBLT_KEYSRC.

下面来看看我们处理移动步长的代码:






18.png (33.24 KB)

2009-6-2 22:25

可以看到,在这个函数.每进行一次绘图,我们就把记录的x,y轴移动步长规律递减.同时背景坐标进行反方向的加减.

大概的逻辑就是这样了,是不是还忘记了处理什么事件呢?对了,是移动事件,在屏幕上按下之后并且移动后我们是需要更改阿仇跑步的方向的:

很简单,再重新调用一下StartMove即可.






19.png (8.77 KB)

2009-6-2 22:25

好了,大概流程就是这样,也不知道讲清楚了没有.好在有源代码,大家没懂的可以具体看看代码.这个例子的具体效果如下,看上去是不是有点意思了:






20.png (68.06 KB)

2009-6-2 22:25

通过这一章的教程,我已经基本上把我目前所知道的DDraw知识都讲完了.前面有朋友提到过图像旋转的问题,经过我的研究,DDraw不支持硬件加速的图像旋转,所以这方面只能自己写算法实现了.
本人的DDraw功力尚浅,所以能讲的大概也就这些了.由于时间很仓促,代码里难免有考虑步骤的地方或者性能问题以及Bug,所以权当参考.

最后奉上本章源代码:


GameSample1_step3.rar (271.97 KB)


GameSample1_step3.rar (271.97 KB)
下载次数: 2443

2009-6-2 22:31