游戏UI2

这篇写下对游戏UI消息系统的理解和看法。主要参考有TEGA,NEBULA3,Irrlicht,CEGUI,scaleform, wxwidget.我发现我对什么东西的理解总会一波三折的。。。正题。。。笔记如下...

一般讲的UI消息系统一般会包括输入事件的处理，输入消息的派发，窗口消息的派发，逻辑消息的派发，他们在UI系统中都占有自己独立的位置，在我想明白这点之后，各种的UI消息处理方式可以说一目了然，只要抓住这几点就知道他的消息系统如何设计，效率大体如何了。UI的消息路由很多讲MFC的书上讲过，但是现在偶觉得并不到位。我自己理了一下，大概是个这样的过程。

首先是一个硬件输入消息的处理，比较有代表行的应该是CEGUI和NEBULA3，CEGUI在每收到一个消息后，立即回调处理，nebula3则是在每一帧开始时处理，其实是没什么区别的，但是一般就这两种方式，没啥区别。经过这一步，讲系统的输入事件转换成了我们UI的输入事件。

接着进行UI输入事件消息的派发，这块的处理所有的UI系统都是一样的，唯一一点区别就在于参数。不同的参数，基本就可以代表它正题的消息如何处理，很好玩。举例来说，CEGUI的参数是一个EventArgs，说明他已经将这次派发与后面的同等看待了，Window类调用了fireEvent，很清晰，很统一，但是会不会浪费了？后面再说。NEBULA3的消息方式。。。恩，必须说是我的最爱，比较纠结的是他打住在这一步了。。。很悲剧。。。后面两部留了个接口，setEventhandler，自己玩。。。nebula3的方式是参数就是个Point，char，uint8，非常简洁，而处理函数的任务也很明确，我知道自己在干什么，并且只能干什么，CEGUI在这点上就纠结了。Irrlicht的比较暴力，但是很简单，也很巧妙，他的消息处理方式跟DXTU异曲同工，只不过能干更多的事了，代表性就在于他对Event的封装，源代码说明一切问题。第二步输入消息的派发完成了，就到第三不了，如何处理这些输入消息，CEGUI的方式，一切一切都是一样的，一切一切都是fire~~~nebula3交给继承的子类重写函数，如果需要产生消息，泽putevent到uimanager里。到这里，有参考性的我想就省scaleform和cegui了，scaleform基于as3，所以只可YY...CEGUI也没什么好说的了，因为封装都是统一的，不停的fire，fire，fire，恩。。。时间长了会走火的，我这么觉得。

再往后，第三部，窗口消息的，窗口消息是我想出来的概念，可能并不独立，但是所有的UI里都会有他的影子，比如irrlicht里的GUIEvent，mfc，wx，cegui子类定义的比如Window_Resize啊，Window_Move啊，他们是没办法独立存在的，而一定是由输入消息处理之后逻辑上产生的。但是又仅仅控制窗口的属性，不需要扩展。除非有新的控件。最后一类，逻辑事件，这个最有代表性的我想要数DXUT，我定义个CUSTOM_EVENT，addbutton（CUSTOM_EVENT），button的本身逻辑保证鼠标被按下时系统产生了这个事件。差不多就这样了。我肯定没讲清楚，不过我自己能看懂就行。

再下一步，事件如何处理。

这个要看你做到多复杂了，我估计能复杂的极限也就是cegui和qt了，不过cegui有它的理由，消息处理很统一，而且方便脚本调用。但是我觉得，游戏的UI就是为了追求速度而生的。简单清晰才是王道。随意最后一步，只有一个点成员函数delegate,参考实现很多，但是不是boost和stl functon，可以参考nebula3 Util::Delegate,Hikari::Impl::Delegate,当然CEGUI的也可以，就是他的名字起的太纠结，竟然叫信号槽。。。没细看之前我一度以为这就是QT的信号槽。。。

UI的消息我觉得基本上就这些了。后面不得不说说CEGUI的瓶颈。

首先，cegui的消息派发使用std::map，并且使用String做key，当然string是有fastlesscompare的，我觉得这么搞，如果没有封装的那么统一，还是可以接受的，但是悲剧在于，连窗口内部调用函数都有可能去靠fireevent，event海量的增加，string越发的悲剧。。。我还是觉得，简简单单，int做key，用sortedarray二分查找，用户的逻辑事件，在通过代理派发，这样清晰，简洁，高效。这些只是我暂时的理解，大家觉得不对的请说说，我最怕误人子弟，当然我坚信没几个人能坚持看到这里的，我的语文太差了，而且是意识流。

ps：smoke的代码风格好清新。。。看的心情愉悦