M8SDK教程-游戏开发心得（一）:游戏程序框架(05-18更新)
引用:
M8 SDK教程- 游戏开发心得（一）: 游戏程序框架
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
很高兴看到M8下的 原创应用开发逐渐丰富起来了.本人有幸也发布了自己的游戏:《K3.原子球》,虽然该游戏目前还未完善,不过作为M8sdn的 论坛管理员,为配合我们的开发宗旨,我非常高兴将我的代码进行开源,并且给大家 分享我在开发中的心得.
游戏开发是一个复杂的过程,它牵扯到程序框架,逻辑设计,绘图,素材美工等多个流程,但是游戏编程也是有趣的,它更是对一个非游戏开发人员的挑战. 我们会在这个教程系列中将我们近期通过在M8上做一些简单游戏所获得的心得和重要的技术介绍给大家.
我所写的教程中大部分都应该在K3.原子球的代码中得以体现,如果想更清楚的了解一个完整的游戏流程,欢迎参考我的代码,不过原子球是我写的第一个游戏,所以有很多很多地方写的不太好,仍需完善.如果各位 高手认为我的程序有什么 问题,欢迎拍砖.
K3.原子球的完整代码已经在M8sdn开发社区开放,欢迎大家参考.
正式开始:
大多数熟悉Windows编程的 朋友可能都已经习惯了一个套路: 处理控件的各种消息事件,然后在这些事件的处理函数里写我们的程序逻辑.我们在使用M8 SDK开发一般 软件时仍然可以使用这一模式,那是因为SDK已经将Windows程序的最基础部分都做好了.
但是游戏程序有其特殊性,我们需要做到实时处理程序逻辑,并对 屏幕进行实时的刷新,并且在用户没有进行操作的时候也一样要做到,所以我们已经不能依赖Windows消息来达到这些目的,我们必须回到底层,去做一些SDK已经为我们做好了的事情.
(我在这里不介绍Windows程序的基本结构和消息循环的相关知识,如果大家对此不熟悉,请大家去 下载一本叫做Programming Windows(Windows程序设计)的 电子书,看完前几章你就会了解)
这些我们必须做的事情就是自己实现程序的消息循环,目前大部分流行的写法是这样:
复制内容到剪贴板
这段代码的逻辑是用 PeekMessage(这个函数与GetMessage有区别哦,请查MSDN) 来处理Windows 消息,一旦消息队列为空,就转去跑一帧游戏逻辑,这帧逻辑完成后游戏屏幕也被刷新了一帧.通过这样,我们就可以做到有消息的时候,优先处理Windows消息,没有消息的时候,就不断处理游戏逻辑并刷新屏幕.
代码:
for(;;)
{
MSG msg;
// 取一个消息
while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
// 如果是Quit消息,则退出
if (msg.message == WM_QUIT)
{
goto _quit;
}
// 转换键盘消息
TranslateMessage(&msg);
// 分发消息
DispatchMessage(&msg);
}
// 进行一帧渲染
render_frame();
}
_quit:
看完上面的代码,我们可能存在以下的问题:
1. 我们为什么要自己写消息循环?为什么不能用WM_TIMER做个定时器来处理(如果大家不了解WM_TIMER请 查询MSDN)
1. 这段代码其实是一个死循环,我们不能判断它会造成每秒钟刷新屏幕多少次,对于M8来说,刷新屏幕次数太多不但没有必要而且可能也更费电吧.
2. 这段代码如果在一个从main函数写起的程序应该是有意义的,可是在M8中有个CMzApp类,消息循环已经被封装好了,我们是根本看不到的,我们必须想办法处理.
第一个问题: 不使用WM_TIMER 的一个原因是精度不够。WM_TIMER的精度如果我没有记错的话大概也就几十毫秒,不过这个帧数在 手机上貌似也差不多足够,但是另外一个原因则是因为它并不能完全准确的表示时刻。WM_TIMER和 WM_PAINT 一样，属于比较特别的消息：优先级低，在消息队列中同时只存在一份（即多个同样的消息可能被合并）,所以,在游戏中完全依赖WM_TIMER是不保险的.
第二个问题其实比较好处理,我从Gledplay的源代码中抄来了一个FPS类,专门用来处理此问题,可以把帧数进行精确限定.
对于第三个问题,大家是否注意到CMzApp类中有个run函数,我们只需要继承并重写这个函数,把我们写的消息循环写在这个函数里,这样问题也可以 解决了.
好的,下面我们可以开始写一个简单的游戏程序的基本框架了:
来看一下我们的项目 文件,很简单,CMainApp.h 和CMainApp.cpp是我们的App类, CMainWnd.h和CMainWnd.cpp是我们的主窗口类,Fps.h和Fps.cpp是我们引入的帧数控制类.
来看一下具体的代码:
1. App类的Init函数:
这段代码创建了我们的主窗口,同时做了一些重要的辅助性工作.SetDVS这个函数是从论坛著名的OpenGl ES的演示代码中来的,目的是为了让CPU全速运行(至于怎么实现的,我也没看懂...). HideMzTopBar()这个函数也很重要,目的是为了隐藏M8的顶部工具栏以使我们可以创建一个全屏的窗口,之后我们使用GetSystemMetrics获得屏幕的大小,然后根据这个大小创建主窗口,我们这里不写成固定值是为了以后的扩展性(说不定以后M9,M10,M11的分辨率就更高了)
2. 主窗口初始化
这段代码没什么特殊的,重要的一句就是使用了SetScreenAlwaysOn来使屏幕一直打开同时防止自动锁屏(你不希望在游戏进行中屏幕黑掉吧)
3. App类Run函数
这里就是我们的消息循环了.可以看到,这里跟我们一开始提供的那段代码差不多比较特殊的地方就在于我们使用帧数控制器控制了现实帧数.同时,在执行一次游戏逻辑后,我们sleep了一下,适当释放资源给其他的线程.由于我们还没有讲到其他的内容,所以游戏的实际逻辑RenderFrame我们只是简单的使用GDI绘了一行文字,同时我们也把绘图帧数绘在了屏幕左上角,便于观察游戏执行效率.
2009-05-18更新
这里增加了当前我们的游戏窗口是否激活的判断,因为如果 电话呼入我们的游戏窗口就会失去焦点,这时应该停止绘图并让出CPU资源,这里非常感谢 linuxlt的提醒.
这个active变量是怎么产生的呢,请看主窗口的处理函数如下:
注意,在游戏窗口重新获得焦点的时候我们需要再次隐藏顶部
4.App类Done函数
这个函数会在程序退出时调用,所以我们在这里做退出程序时该做的事情: 恢复CPU节能状态,解除屏幕高亮以及重新显示顶部工具栏,SetScreenAutoOff函数你可能发现了,有拼写错误,看着有点别扭,所以我们这里用一个宏改过来.
好了,代码分析完成,我们来看看通过本次学习我们了解到了什么?
1. 游戏程序的基本执行流程和消息循环
2. 精确限定游戏帧数的方法
3. 在M8上创建全屏游戏窗口的方法
4. 在游戏运行时保持屏幕开启的方法
5. 在游戏运行时维持CPU全速的方法
6. 在游戏窗口失去焦点时需要停止绘图并让出cpu资源
这个范例的实际运行效果如下:
呵呵,只有一行字,很土鳖,而且你会发现,我们明明限定了帧数是40帧的,为什么执行结果反而还没有到40帧呢?这说明我们的绘图性能方面有问题.解决绘图性能是游戏的一个大问题.那么我们该如何解决这个问题呢?
785
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
