游戏编程学习笔记(3)

到目前为止,我的2D引擎的渲染器,对象管理器,资源管理器已经基本完成,绘制1000个100*200的精灵(并且使用alpha融合)时速度也完全够用了(60fps),事实上渲染速度是和精灵大小也有很大关系的,在实际游戏中精灵的大小一般都不会有100*200这么大.于是video部分基本上符合了我的要求.接下来的一段时间会将这部分代码再调试一段时间,观察是否还有未发现的bug等.

 

目前的渲染部分工作于3个不同的线程,主线程是用于进行渲染的主循环所在的线程,删除线程是为了提高渲染速度而做的一个优化,在场景树中被删除的子树首先都回先被放如删除buffer,然后由定时线程去清除他.最后就是游戏逻辑线程,这个线程和渲染最大的关系就是游戏资源的加载,对象向场景树中的添加都发生于这个线程.这个线程和主线程的同步也就需要格外的注意.

 

事实上渲染引擎只是游戏引擎众多部分中的一部分,而且是比较底层的一部分.

 

当完全完成了渲染引擎之后,下一个开始实现的是输入引擎.

目前只是属于设想阶段,但是对下面几个问题进行着考虑:

 

首先就是对事件源的选择,目前有两个选择,一个是winproc,一个是directinput各自有各自的好处,不过对这个的设计我还没有想好,因为我比较理想的状态是,把input专门独立出来一个动态库,然后向外界提供统一的接口,然后可以用有相同接口的dll所替换,但是问题是目前窗口是整个封装在目前的引擎里的.势必会导致这两个模块比较高的偶合.应该可以有方法去解决这个问题的.具体写的时候再去看吧.

 

其次是事件和对象的交互.我有想过几种方案,一种是在引擎的底层做一个消息队列,从消息源接收到的消息经过某种过滤先放入消息队列,然后在队列的上面做一个消息分发机器人(这需要一个单独的线程),这个线程在消息队列空的时候应该是挂起的,在有消息在队列里的时候,应该被及时的唤醒.消息分发机器人需要根据消息的类型和参数顺利的找到消息的接收对象,消息的接收对象应该可以独立于绘制对象.然后回调消息接受对象中的各种函数.

 

另外一种想法是, 所有的绘制对象都拥有自己的事件线程,当然事件线程也应该是经常会挂起的,然后由事件对象自己去处理各种事件,这个想法有点像windows的工作过程.

 

最后比较复杂的一点是,如何去判断鼠标选取事件和精灵对象的作用.与精灵对象进行作用时要通过相素进行判断,但是这样会不会慢,还有就是事件对象如果要根据相素进行判断,在取相素时肯定会阻塞绘制线程,这样对绘制效率的影响会不会太大.这非常重要. 也许在建立某个对象的事件响应对象时就应该去先拷贝一个副本,或者用一个黑白位图去表示区域问题.至少这样不会阻塞绘制线程,而且也不用考虑那么多的同步问题.但缺点就是会耗费很多的内存资源.

 

还是和绘制部分一样先写着吧.写着写着就可以发现问题了.到时候也许思路回更成熟一些