在游戏中使用“CEGUI”

文/唐亮

CEGUI是非常常用的GUI设计工具，本期我们为你详解。

-----------------------------------------------------
老大的笔名吗?


有个问题要请教马肝兄!
猫狗占140M以上的内存,觉得很不应该,我想你也一定做过测试,能说一下瓶颈
在什么地方吗?

另外猫狗中使用open source的东西太多了,我觉得并是件好事,你怎么认为?

网络确实是softstar的弱项,看了lsocket.dll ,objnet.dll的导出函数,功能是如此的简单!

7月的可刊发了？上面有靓照么？

o>_<o
千里马肝才是偶的ID

来真的了，不过我倒真比较喜欢回答这样的问题:)
你说的猫狗应该是指的猫狗坦克，这140M，大概主要是花在：
1. 文件打包
文件在被读取的时候，会解压到一个FileMapping中，这样的话，一个scene.pkg就会很大了，这也是因为猫狗坦克里的场景“不是很大”，所以打在一个包里，如果像是猫狗2，就会分场景打包了。而且，游戏不止是scene，还有music.pkg、sound.pkg等，这样就大了。
2. CEGUI
因为界面使用CEGUI实现，而记得光一个CEGUI::Window就有十几K（具体数字忘了）的样子，你想界面上那么多控件，都是从Window派生，再加上自身的member，就吃内存吃得很历害了。其实主要坏事是坏在CEGUI::Properties上面，为了序列化，实在是花了太多的空间。记得有次小叶子测试某个“比较”复杂的界面，光它一个就吃掉了约一百M的内存，后来因为很多control不需要scrollbar，就去掉了，发现就省了几十M，当然，编译成Release版就好很多了，执行效率会“大大”改善，这是CEGUI的一个特点：Debug版超吃内存超慢，Release会好不少。

A. OpenSource
我是个喜欢OpenSource的人，所以会比较偏向于一些如Boost、OpenAL、Stlport、Python之类的东西，一方面是避免重复造轮子，另一方面是即使重造也没有这些轮子好用和稳定，站在巨人的肩膀上肯定是好的，至少在使用的过程中会学到不少架构上的知识或奇技淫巧。我认为唯一需要注意的就是license，GPL这样的就纯粹研究好了，LGPL是首选。

B. net和socket
这一块是偶的弱项，俺觉得光C++和Graphics就够洒家烦心的了，吾实在没有时间去操心这些了。而且，猫狗坦克的网络是由台湾总公司独立负责开发，插不上手。

想要俺的照片
先发尔的照片给偶瞅瞅:)
再决定之

.....
游戏创造我只缺了一期而已.
不过关于技术的讨论实在太少了.....

谢谢马肝兄的回复！
猫狗指的是"阿猫阿狗大作战Online".
1.也就是程序Load的时候，就把所有资源放到内存中，怪不得Load过程这么慢。为什么没有尝试在房间开始游戏时才Load呢？
2.cegui我也下过，尝试了它的摆放工具，最后觉得实在不舒服（可能习惯vs的摆放工具了），还有它依赖于orge,所以放弃了！既然它这么耗内存，为什么不考虑放弃它！
3.偶也是一个开源狂热份子。但是我不会轻易在商业项目中使用开源的东西，必须经过再三思量后才用之。在vs6那个年代Stlport确实是个很好的东西，很多windows下的库都依赖于它，但是有了vs7.1后，很多人都不在用stlport了.
作为一个专业的游戏公司竟然把libsql.dll，d3dx9_27.dll以及一些pdb文件打包到安装报，实在很不应该。
4.那就无话可说了。这是觉得可惜啊！

哈哈

1. 倒也不是一开始就都Load进来了，还是读哪个场景载哪个，可能是我没说清楚，应该不像你想象中那么夸张
2. cegui可以自行配置的，修修改改，还是很好用的，而且并不依赖于ogre，对于cegui而言，ogre只是个renderer而已，另外相比自行实现的UI，cegui有很大的优势，这也是为什么会选择使用它的原因
3. 开源并不代表着低人一等，也不意味着商业软件就不能使用它。实际情况恰恰相反，很多开源的东西要比同等商业软件要来得好，这当然是见仁见智。没看见最近爆出一些商业软件中使用了GPL软件而导致的官司吗？这就是开源软件实力的象征。只要是符合协议的行为，都是可以大大节省人力的。另外，stlport优秀是在于它的效率、hash系列以及优秀的memory pool（这个可以去看候捷老师的《池内春秋》和《STL源码剖析》），另外他的代码可读性也是最强的，相比VC使用的PJ这一版，因为PJ使用了代码混淆器，其代码可以说是乱78糟，不过从vs2003起，PJ的STL在效率上已经有很大的改善，所以大家就慢慢接受了。也可能是因为stlport配置麻烦的原故（这也是opensource的特点，属于unix风格，很多东西都是“面向程序员”的）。至于你提到的包里的一些dll，像是libsql.dll，这应该是使用到mysql的原因；d3dx9_27.dll是因为dx9.0c每隔2个月就有新版本，而猫狗坦克是基于_27这版制作的，自然要带上方可运行，也省得玩家机器上不同dx9版本为了这一个文件去重装dx9 runtime；最后回答你的pdb，这个我猜想是可能为了收集crash时的dump数据的原故。（我们的程序可以在自带pdb的情况下，当crash时可以dump出堆栈一类的调试信息）
4. 谁都不是神，大宇也是:)，只是围城外的人被她外表的耀眼的光环闪花了眼睛一厢情愿而已

说明一下，猫狗2是我从头到尾带的，而坦克我主要是程序指导和图形渲染的技术支持，可能我走后这段时间，上软又做了些改动也不得而知。

另外，我个人认为，商业项目的要求是能在保证稳定和质量的情况下，在最快的时间内实现出来，作为程序员，不应该为了炫耀自己的个人技术，大量重复造轮子，最后往往导致车子造不出来还花大量时间修轮子。

今天早上再看了一遍你的问题
发现你被主观意识所主导了
忍不住再说两句：

1. 这是个设计的问题，倒底是游戏一开始就全Load进去，以后切换场景和界面就会很快，用空间换速度；还是到哪Load哪，这样会有大量磁盘操作，用速度换空间，见仁见智

2. 基于mmo或是casual这些game有大量的复杂ui，通常的ui库是无法满足需要的。而cegui有许多的优点，多到足以可以弥补它的缺点，单是一个LayoutEditor就可以说明一切了。放弃cegui？难道自己开发就肯定会好过它吗？如果你有从头设计一个ui库的经验，我想就不会这样认为了

3. stlport不像第2条，它是有PJ这样的替代品，而且vs2003/2005的PJ版STL已经非常优秀，所以这是道选择题，而且不瞒你说我也从2005起就没再用stlport了。不过主要原因却是，stlport搞了自己的memory pool，而游戏通常需要自行实现，这样就冲突了，在这种情况下，PJ版的只是一句::operator new的alloc实现反而有了优势

4. 这个麻，不一定复杂就好，够用就行，简单也是一种美，keep it simple and stupid~

马肝兄会错我的意啦!
说实话,我看过的代码并不比你少:),
1.从linux kernel,httpd,到ace,stdc++,glibc,boost,loki,lua等等,
我也不同意重复造轮子,但是有一点需要明白的,如果你用过ace.当你程序发现bug的时候,在那个时候你就会陷入代码的海洋,你并不知道是库的问题,还是你代码的问题,还是你代码和库代码的兼容问题.

2.可能我们的背景不一样,我很多时候在linux下开发,我有stdc++就够了,并不需要stlport.很多时候我们在进行oo设计的时候知道低耦合高内聚原则,但是我们使用库的时候呢,是否也要遵守这个原则呢.你写了个库依赖于boost,那么意味着用你库的人也必须要依赖于boost.假设你走后,公司没有这方面的人呢,如何维护?这些问题我们都需要考虑的.

3.我初看到client打包了libsql.dll,我还以为使用了embeded mysql server,因为之前也看到很多client用sqllite作为client的数据库,但是用mysql确实太大材小用了.后来把libsql.dll改名后发现并不依赖(下次把我系统里的libsql.dll也改了看看到底有没有依赖).把d3dx9_27.dll放到程序目录下,难道不怕dll hell吗?

4.我做的项目也用pdb作crash dump,但是只在debug版本中这么用,在release版本中不会这么用,也重来没见过有人用pdb,因为pdb中放了很多的符号信息,你可以通过他很容易捕捉crash的详细信息,我也可以获取这些信息啊.建议马肝兄看看Matt Pietrek大师的文章.

5.我从来没有把大宇看作神,他只是个拿着'仙剑'沾沾自喜的家伙!

6."商业项目的要求是能在保证稳定和质量的情况下",你那样'泛滥'的用开源能保证稳定吗?能让程序很好的维护吗?毕竟维护的时间要多余开发的时间.

马肝兄,我还是蛮佩服的!呵呵
tnnd不知不觉写了这么多东西,自己的blog都好久没更新,真有些不务正业!

3.至于memory pool,可以说是程序员工具箱中必被的东东.为什么不把他从stlport中剥离出来呢!另外halflife2 leak source ,Torque Game Engine
中都有这些东东,codeproject.com上也有不错的!

4.简单到幼稚!
lsocket.dll已经被我hack掉了,从暴露出的接口,我对他的效率表示很有怀疑.抽时间写个测试,用数据来验证我的怀疑!

尝试地学习了3D一段时间后,发现还是网络更适合我.那里有我的天空.

呵呵，说真的，蛮高兴能有这样的讨论，谢谢~

我想问题应该就像你所说的：正因为我们的背景不一样，所以谁也无法说服谁
其实我是个追求完美的人，但是就像ace的问题一样，每个项目都有着这样那样的原因，开发者不得不放弃一些东西，又有哪家公司有暴雪那样的魄力呢
不过也正因为如此，大家能从各自不同的角度去看一个问题，缺陷也就是在这样的讨论下浮现的

的确，cegui花了我不少时间，通过阅读这条小河的代码，我会这样去推举它也正是因为我很清楚它的实现确实有可取之处，而且它还在不断完善之中
对于stlport和boost这些stable很久的东西，我还真的从来没有去怀疑过，可能我过于迷信权威，当bug出现，我更多得是去从自己身上去找

ace我只是看过些文章介绍，给我映象中用一句话可以描述：它是个超强的网络库，但是因为历史原因（c++、c++ compiler、向下兼容），使用了一些比较丑陋的方法去实现一些设计，导致代码可读性很差，听说ice要好一些

你应该发现了，我使用的大多是像TinyXML这样的轻量级OpenSource库，从功能还是代码量上，都是无法与Ace相比的，其目的也是便于学习、使用和维护。也就像是Devil和FreeImage，对于我而言，大多数情况下我只是要一个Loader，除非我要做图像处理，实在是不需要像FreeImage这么复杂的功能

猫狗坦克中的数据库和网络，我还真的不了解他们现在是在怎么处理
pdb的问题，呵呵，天晓得他们为什么要把这个也丢出来
另外，网络这边，我对台湾那边的那位老兄的能力也是非常佩服的，他在网络这一块已经有15年的经验了，但对具体实现技术这边我没有发言权>_<

其实，我们在把技术和项目管理维护混为一谈
使用到boost这样的前沿库，的确上软现在无人对它有什么太深的了解
这确实会有你所说的维护上的问题，但是也不能因噎废食
我想这是个人的问题，技术的发展不会因为个人的停止不前而滞留。其他过多的东西我想没必要去要求程序们全部都了解，但是像boost这样的准标准库还是应该去学习的，只要不是去了解底层实现，光使用的话还是很简单的

对于脱离sgi的stl中的memory pool，当我发现pool冲突的问题时，我何尝没想去做你所说的事情，可惜当我面对如此一望无垠的汪洋大海时，我流泪了~

呵呵，又说了一堆
我发现我们其实蛮互补的，非常希望以后能多与你交流，从中我也学到不少的东西
其实大家都有同感，会的东西越多，就越发现自己的渺小
就我而言，C++就花了我不少的时间，还有一堆书要去啃，转战图形学，更是一种剧痛，咬着牙挺过来，却发现数学没学好，再看看这个学学那个，最终的答案是这辈子就只搞搞C++，图形学两手抓，其他的东西，去死吧，真没那个命了

最后有句话和你分享：滚石不落苔，转行不聚财

人与人之间，没有谁对谁错，只有谈得来谈不来~

设计就是一个选择的过程!
我喜欢把设计的过程比作做菜,甜的咸的,味重味轻.这其中并没有谁对谁错,谁好谁坏!

[[
使用了一些比较丑陋的方法去实现一些设计，导致代码可读性很差.
]]
我不晓得说这句话的人是针对哪个版本.对于最近的基本版本,我认为可读性很好,但是因为其中用了很多dp,所以在掌握这些dp前阅读,是会有点吃力的!

我的msn是ro4tub_at_hotmail.com
有空可以再讨论下啊!呵呵

打完收功~