WM_PAINT 消息
在之前的代码中,我们对于WM_PAINT
消息的处理方式如下:
1 | PAINTSTRUCT ps; |
如下图所示,当一个窗口被移动、改变大小或被其他窗口遮盖时,WN_PAINT
消息便被发送了:
在之前的代码中,我们对于WM_PAINT
消息的处理方式如下:
1 | PAINTSTRUCT ps; |
如下图所示,当一个窗口被移动、改变大小或被其他窗口遮盖时,WN_PAINT
消息便被发送了:
菜单的配置与前述各类资源一样,编写在.RC
资源脚本中,同时,和字符串资源相似,菜单各项的标识符也必须是整数ID,而不能是名称字符串;
一个简单的菜单配置如下:
1 | // 在头文件 RESOURCES.H 中 |
1 | // 在资源脚本 xxx.RC 中 |
上述代码可以生成如下图所示的菜单栏:
作者在书中写道“关键字DISCARDABLE是过时了但还是必须的”,但是实测在VisualStudio2019环境下此声明是不需要的;
与其他资源的定义相同,花括号可以被替换为BEGIN...END
对;
如果需要设置热键或配合Alt触发的快捷键,只需要在POPUP菜单或MENUITEM字符串中将&
放到想要标识的快捷键字符前面,如下:
1 | // 使 x 成为热键 |
Windows程序支持将资源数据编译到.EXE
文件中,优势如下:
支持编译到程序中的资源类型有:图标,光标,字符串,声音,位图,对话框,图元文件;
我们只需要创建扩展名为.RC
的文本文件,资源编译器会自动根据所配置的资源脚本装载所需的资源,并编译到以.RES
为扩展名的文件中,后续与.LIB
和.OBJ
文件编译为一个完整的应用程序文件;
不久之前做了一个直播间弹幕互动小游戏的开发框架,不过一直没有把相关的内容记录下来,也没有使用这个框架完成一部完整的、具有游戏性的小游戏,所以正好忙里偷闲整理一篇博文,顺带做一款大地图的多人扫雷。
本篇主要对框架的技术设计进行阐述,游戏逻辑等日后有机会再另其一篇文章进行介绍;
使用 Python 实现类似 Protocol Buffers 的通信协议解析及序列化和反序列化等功能
Windows程序的关键是打开窗口,并对窗口进行文本、图像的显示工作,以及对来自窗口的交互消息做出响应,步骤如下:
每一个应用程序至少需要创建一个Windows类,用于描述窗口信息;
描述Windows类信息的数据结构有两个,WNDCLASS
和WNDCLASSEX
,最好选用较新的扩展版本WNDCLASSEX
;
在Unicode环境下,WNDCLASSEXW
被定义成了WNDCLASSEX
,相关定义如下:
1 | typedef struct tagWNDCLASSEXW { |
Windows允许不同的应用程序以轮询的方式“同时”执行,每一个应用程序都占用一段很短的时间片来运行,而后轮到下一个应用程序运行,如下图所示,CPU由几个不同的应用程序以循环的方式共享,而负责判断出下一个运行的程序、给每个程序分配运行时间的是调度程序的工作:
在大部分情况下,我们是不需要对Windows调度程序过度关注。
深入接触Windows,会发现其不仅是多任务的,还是多线程的,程序可以有许多较为简单的执行线程构成;这些线程被视为具有较重的权值的进程,从而如程序一样被调度;程序可以有一个主线程和几个工作线程构成,如下图:
一个视频游戏基本上是一个连续的循环,它完成逻辑动作并以每秒30帧或更高的刷新率在屏幕上绘制图像,与动画和电影的放映原理相似,简化的游戏循环结构如下图所示:
对上图每一部分流程进行说明:
在大多数情况下,游戏循环是一个含有大量状态的FSM(Finite State Machine,有限状态自动机),如下图所示:
《Game Programming Patterns》学习笔记 - 观察者模式
观察者模式可能是应用最为广泛的设计模式了,Java 将它放到了自己的核心库 java.util.Observer
中,C# 更是将其通过 event
关键字把它嵌入到了自己的语法中
一种常见的定义可以把它描述为:
一个目标物件管理所有相依于它的观察者物件,并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实现事件处理系统
在游戏中最常见的用途便是 “成就系统”
《Game Programming Patterns》学习笔记 - 享元模式
简而言之,享元模式就是将对象的数据分为两部分,其中一部分没有特定指明是哪个对象的实例,因此可以在它们间共享,GoF 称这部分为 “固有状态”,一个很常见的例子便是开放世界中的树林的渲染和瓦片地图的数据存储方式
享元模式是对内存和开发者友好的,它可以通过减少重复部分数据避免内存冗余,并且通过合并类来减轻程序员的管理负担