对DUILIB重构的一些看法

来源:对DUILIB重构的一些看法

经过一段时间的思考和对游戏引擎HGE和OGRE的学习,我觉得duilib要参照游戏开发的方法来做些重构:在功能层次划分上大体可分为主框架、窗口管理器、事件管理器、渲染处理、逻辑处理、资源管理、时间系统、脚本、GUI,以下是具体内容
1、主框架:负责创建唯一的物理窗口、处理系统消息处理生成输入事件,同时它也是一个主循环应该具有起停功能
2、窗口管理器:所有的窗口都是virtual的,涉及到窗口间的切换以及通信的时候能够很方便的进行管理,同样定义窗口切换的动画时也是很好扩展的
3、事件管理器:对输入事件、逻辑事件进行统一管理。输入事件一般就是由系统消息转换而成的,而逻辑事件一般是逻辑处理产生的。事件通知机制采用类似C#的托管机制,由事件管理器分发到注册的监听者(窗口和控件)
4、渲染处理
(1)做成一种帧回调的方式,这样能够根据实际情况调整刷新的频率。
(2)帧可以拆分成逻辑处理帧和界面渲染帧在不同线程中处理实现完全分离,逻辑帧是对数据及渲染对象状态改变等进行处理,而渲染帧是进行实际的渲染,在处理完一帧结束的时候同步一下。
(3)简单数据的处理可借鉴MFC的DDX机制。比如音量调节,在逻辑处理修改音量这个数据后会触发视图的刷新。
5、逻辑处理:处理数据和事件状态切换、通知渲染处理
(1)简单的逻辑处理直接在事件处理函数中完成
(2)复杂的逻辑处理考虑用有限状态机的方式
(3)逻辑处理和渲染处理是需要有一个同步机制的
6、资源管理器:对图片、文字、声音进行统一管理
(1)在PopCap_Framework这个小游戏开发框架中有一个ResourceGen工具,可以生成资源配置文件包含的只是ID及路径,这样有一个好处就是可以动态的改变图片及文字
(2)资源预读线程。这在资源够多主框架刚起来时对效率的提升还是有帮助的。
(3)高速缓存:防止过多的资源占用大量的内存
7、脚本:如果界面和逻辑分离得比较彻底,那么逻辑处理用脚本来做应该是比较容易了。
8、GUI:duilib现有的控件容器部分其实只是GUI,已经做得比较完善了。不同的是由渲染线程来处理这些图形单元,如果能进一步抽象到点、线、面就更好了。
9、渲染器:这一部分最好抽象出来,一个好处就是具体的渲染模块如GDI、GDI+、D3D、OPENGL可以用插件的方式注册。
10、时间系统:这部分到底需不需要还没想明白。
11、日志记录
12、调试:比如说内存泄漏监控、回收、异常处理机制等等
以上这些纯粹是个人的一些想法,因为游戏不管是逻辑处理还是渲染处理都是要比普通的程序要更复杂的,这些想法实际开发中是否有效还是个未知数。另外强力推荐一本游戏开发的书籍:

<Game Coding Complete 3rd Edition>,建议直接看英文版,我是受益良多吧。