对于通用场景来说我以前介绍的区间扫描线Z缓冲器算法可以剔除大部分的不可见物
体，但是在基于heightmap的大规模地形场景下会发现作用不是太大，区间扫描线Z
缓冲器算法需要在场景中手工指定occluder，occluder必须为规则物体，而在地形
场景中这种occluder非常少，也就是场景中的建筑物之类的物体。实际上地形场景
中最适合作为occluder的是连绵起伏的丘陵、山脉，它遮挡住了场景中的大部分物
体，但是区间扫描线Z缓冲器算法对这种情况下的OC就无能为力了，需要使用其它算
法进行OC计算，现在网上完全公开的适用于地形场景的OC技术主要有以下几种：
Voxel column culling、Hierarchical visibility、incremental horizon。这些
算法都需要进行一些预处理，其中最流行是incremental horizon（增量地平线）技
术，这种技术要求在渲染前对每一个地形块计算一个潜在轮廓线，在渲染时将这些
潜在轮廓线合并为地平线进行OC处理。由于这种算法需要进行预处理因此也不太适
用游戏开发，此后我自己又开发了一个realtime计算的incremental horizon算法，
但是发现开销太大，根本无法用于realtime rendering（和Pascal Junod在论文
《Implementation of a O(na(n)log(n)) Point
Visibility Algorithm on Digital Terrain Models》中使用的算法相同，这篇论
文我也是后来才发现的，有兴趣的可以翻看一下我以前在gameres发表的文章）。
下面列出的是网上相关的论文，有兴趣可以自己看一下。
Lloyd B, Egbert P. Horizon occlusion culling for real-time rendering of
hierarchical terrains. In: Gross M, Joy KI, Moorhead RJ, eds. Proc. of
the IEEE Visualization. Boston: IEEE Computer Society Press, 2002. 403-
410.
Stewart J. Hierarchical visibility in terrains. In: Dorsey J, Slusallek
P, eds. Eurographics Workshop on Rendering. Vienna: Springer-Verlag,
1997. 217-228.
Zaugg B, Egbert P. Voxel column culling: Occlusion culling for large
terrain models. In: Ebert D, Favre JM, Peikert R, eds. Proc. of the Joint
Eurographics-IEEE TCVG Symp. on Visualization. Vienna: Springer-Verlag,
2001. 85-93.
Stewart J. Fast horizon computation at all points of a terrain with
visibility and shading application. IEEE Trans. on Visualization and
Computer Graphics, 1998,4(1):82-93.
Daniel Archambault. All the Distant Horizon Edges of a Terrain. B.Sc.
(Hons.) in Computing Science, Queen’s University (Kingston), 2001
Pascal Junod. Implementation of a O(na(n)log(n)) Point
Visibility Algorithm on Digital Terrain Models. October 1999
后来我仔细观察farcry的editor sandbox，经过差不多两个多月的试验终于开发出
一个可以realtime运行的用于地形环境的OC算法，这个算法的开销非常小，经过我
在OGRE平台上的试验，此算法可以做到非常精确的剔除，FPS提升明显。由于这个算
法的核心是线段求交，因此我暂时称其为线段求交OC算法。
在介绍这个算法前先明确一下坐标系，一张heightmap的行为X，列为Y，高度方向为
Z。
先考虑单点OC的情况，如下图所示：
P
|
|C
A-------------------B
|
|
O
假设plane AB为一个occluder，O为camera位置，如果要判断点P是否被AB遮挡，只
需要简单的判断线段OP是否和occluder AB相交即可，如果存在相交点C则点P即被遮
挡，问题被简化为线段和平面的求交。下面继续考虑在地形环境下如何简化这个问
题，在地形环境下heightmap的每一行和列都可以看作一个occluder，这里假设AB为
行或列相临两个顶点组成的线段，如果要判断点P是否被AB遮挡，可以通过比较交点
C在线段OP和线段AB上的z值来确定：
Zc_op > Zc_ab 点P没有被线段AB遮挡
Zc_op <= Zc_ab 点P被线段AB遮挡
现在检查点P是否被遮挡在地形环境下简化为一个简单的2D线段求交问题，这也是本
算法之所以高效的原因。
下面继续来看一下如何将算法由一个点推广到整个地形。在基于heightmap的地形系
统中通常将地形分成一块块小的tile，根据LOD算法的不同tile大小可以为17*17或
者33*33不等，这里假设使用17*17的tile。
首先来看如何剔除场景中被遮挡的tile。对于tile来说如果所有的顶点都位于其前
方行和列的下方，那么它一定被遮挡。换句更精确的定义，对于tile的每一个顶点
，如果与camera所在位置所形成的线段，全部与位于tile和camera之间的行或列中
任意一条线段相交，那么可以确认tile被完全遮挡。
按照上面的定义，一个tile如果被检查到完全遮挡需要检查17*17=289次，虽然2D线
段求交运算开销非常小，但是一个tile就需要进行289次运算仍然是不可接受的，需
要更简化的算法。考虑一下区间扫描线Z缓冲器算法，occludee使用都是物体的AABB
，是否可以使用tile的AABB进行运算呢？由于地形环境的性质可以不用考虑AABB最
下面的四个顶点，但是直接使用AABB最上面的四个顶点进行运算绝对不行，如图所
示：
四个顶点虽然被完全遮挡，但是occludee并没有被完全遮挡，如果解决这个问题需
要将AABB的up表面分割成16*16的格子，这样的话运算次数并没有发生变化。
这里可以使用一个取巧的方法，如下图所示：
将AABB投影到camera空间，直接获得线段AB，将AB线段16等分，获得17个新的顶点
，注意这些顶点z值全部相等，现在ocludee是否可见只需要检查17次就可以了。
下面看一下算法复杂度，对于一个完全遮挡的tile只需要进行17个顶点的计算，完全未遮挡的tile只需要计算一个顶点，部分遮挡的tile大约是2-16个顶点左右，由于tile在进行OC运算之前首先要做frustum culling，剔除被frustum culling的tile，然后剔除那些没有被遮挡的tile，实际上的运算量非常少。
注意这里的每个顶点的计算不是指简单的17次线段求教运算,根据tile距离camera位置的远近每一个顶点求交的数量是不一样的,例如下图所示:
图中线段OA需要检查三条行和列,一共是六个交点,需要进行六次线段求交运算.
对于场景中的模型进行OC运算时，也需要按照上面的方法将模型的AABB变换到camera空间，获取一条occludee线段，然后根据地形相临顶点之间的距离确定顶点数。
使用这个算法和区间扫描线Z缓冲器算法相配合可以获得在室外场景中最大限度的剔除被遮挡物体，先用线段相交OC算法剔除被地表遮挡的tile和模型，然后用区间扫描线Z缓冲器算法剔除被建筑物遮挡的tile和模型，完美的室外场景OC解决方案，very nice！！！！
原创文章,转载请注明出处!!!!!!!
线段相交OC算法演示程序下载（使用OGRE平台，运行前先看readme文件）:
/Files/dreams/ogrenew.part01.rar
/Files/dreams/ogrenew.part02.rar
/Files/dreams/ogrenew.part03.rar
/Files/dreams/ogrenew.part04.rar
/Files/dreams/ogrenew.part05.rar
/Files/dreams/ogrenew.part06.rar
由于cnblog上传文件大小限制,因此文件被分割成1M大小上传,抱歉!!!!
HL2的地形系统是一个另类的地形系统，它没有使用当前流行的heightmap技术，而是完全使用displacement map技术来进行处理，使用displacement map技术的初衷是为了在框架中和BSP技术保持一致，这是因为在BSP中最小的渲染图元是surface，surface的限制是所有的顶点必须位于同一个平面上，实际上从理论上来说在HL2这样的引擎中也可以使用heightmap来构造地形，那就是将heightmap数据也分块保存，但是当前流行的地形技术使用的都是一个整张heightmap，而且大量的LOD算法都是基于这个基础上的。使用displacement map的另外一个好处是可以构造更加复杂的地形，这是因为它存在法线的缘故。同时使用displacement map还有一个好处是在将来，因为当前MS已经对displacement map技术进行了支持，现在的问题是GPU在硬件上还不支持，如果一旦硬件支持的话，就有可能将整个地形由GPU来处理，那么对地形渲染的速度和精度会有非常大的提高。
1、what’s Displacement Map
displacemtn map技术是最近几年才出现的一个技术，它出现的初衷是为了解决内存和GPU之间的带宽问题，它开始主要用于高poly角色模型的渲染，由于模型的高数据量会使内存和GPU之间的传输成为瓶颈，因此将其转换为低poly模型和一张displacement传送到GPU中，在GPU中转换为高poly模型进行渲染，可以大大减轻传送的数据量。
但是当前这项技术已经获得非常大的发展，它使用的范围非常大，从室外地形、水面、海洋到室内场景的渲染，它为提高场景的真实度提供了一个有力的工具。一个displacement map通常包含两部分：一张normal map用来保存法线，另一张height map用来保存顶点的偏移。当需要从低poly模型转换为高poly模型时很简单，首先从模型的一个face上获得一个插值点P1，然后从displacement map中获得相应位置的normal和distance，那么新的顶点P2为：
P2 = P1 + normal*distance
关于displacement map的参考文章请看shaderX2中的Displacement Mapping。
2、HL2 Displacement Map Rule
在HL2中displacement map信息被保存在BSP文件中，它有以下几个数据块：
LUMP_DISP_VERTS 保存displacement真实顶点信息
LUMP_DISP_TRIS 保存displacement三角形标识符信息（walkable or buildable）
LUMP_DISPINF 保存displacement 的连接信息
它们保持的信息结构如下：
LUMP_DISP_VERTS：
class CDispVert
{
public:
Vector m_vVector;// Vector field defining displacement volume.
float m_flDist; // Displacement distances.
float m_flAlpha;// "per vertex" alpha values.
};
LUMP_DISP_TRIS：
class CDispTri
{
public:
unsigned short m_uiTags; // Displacement triangle tags.
};
LUMP_DISPINF：
class ddispinfo_t
{
public:
int NumVerts() const{ return NUM_DISP_POWER_VERTS(power); }
intNumTris() const{ return NUM_DISP_POWER_TRIS(power); }
public:
Vector startPosition;// start position used for //orientation -- (added BSPVERSION 6)
int m_iDispVertStart;// Index into LUMP_DISP_VERTS.
int m_iDispTriStart;// Index into LUMP_DISP_TRIS.
int power; // power - indicates size of map //(2^power + 1)
int minTess; // minimum tesselation allowed
float smoothingAngle; // lighting smoothing angle
int contents; // surface contents
unsigned short m_iMapFace; // Which map face this
//displacement comes from.
int m_iLightmapAlphaStart;// Index into ddisplightmapalpha.
int m_iLightmapSamplePositionStart;// Index into.
// LUMP_DISP_LIGHTMAP_SAMPLE_POSITIONS
CDispNeighbor m_EdgeNeighbors[4];// Indexed by NEIGHBOREDGE_ defines.
CDispCornerNeighbors m_CornerNeighbors[4]; // Indexed by CORNER_ defines.
enum { ALLOWEDVERTS_SIZE = PAD_NUMBER( MAX_DISPVERTS, 32 ) / 32 };
unsigned long m_AllowedVerts[ALLOWEDVERTS_SIZE]; //
// This is built based on the layout and
//sizes of our neighbors
// and tells us which
//vertices are allowed to be active.
};
在HL2中规定一个displacement最大由17*17个顶点组成，每一个displacement都将左下角看作是自身坐标系的原点，并按照顺时针方向进行记数。如下：
在ddispinfo_t类中我们可以看到为了记录displacement的邻接关系，它使用了两个数组，m_EdgeNeighbors记录四条边的邻接关系，而m_CornerNeighbors记录了四个角的邻接关系。必须注意的是在HL2中邻接的displacement并不一定都是一样大的，也就是说邻接的displacement不一定是一个，也可以是两个，如果邻接的为两个的话那么邻接的displacement的大小必须小一倍。如下：
在displacement和surface中都有一个变量来指定它们相互之间的对应关系，你可以这样认为，如果一个surface是一个displacement surface的话，那么在surface所保存的顶点信息就是displacement所在的基准面信息，实际上就是记录基准面的四角坐标，当产生实际顶点时过程如下：通过这四角的坐标和displacement的power信息可以插值获得每一个真实顶点的基准点坐标，然后通过CdispVert所保存的信息获得真实的顶点坐标。
3、如何处理地形系统
在HL2中为了高效的渲染地形定义了大量的类，其中最重要的为CdispInfo，它几乎包含了地形的大部分处理，还有一个类CpowerInfo，这是一个予计算的模版类，它预先计算了每一种大小displacement的信息，这样做是为了加速地形的渲染，而类CcoreDispInfo只用来载入数据时使用，它的功能就是将BSP文件中的信息转换为程序可以处理数据。其实在HL2中比较难懂的是它的LOD算法，下面是它具体的算法：
首先是它的更新策略，在正常情况下（LOD的控制台变量为默认值）对displacement的更新有两种情况，它规定了一个更新半径（由控制台变量r_DispFullRadius指定）凡是位于此半径内的displacement的LOD等级都为最大。另外在每次更新时每一个displacement内部都记录了更新时camera的位置，如果当前camera的位置减去上一次更新时camera位置的大小大于一个规定值（由控制台变量r_DispRadius指定），对其进行更新，必须注意的是此时更新的是位于更新半径外的displacement。
下面是它的LOD算法，还是要提醒此时是对更新半径外的displacement进行处理。通常现在LOD算法都是基于距离进行计算的，但是HL2中没有采用这种方法，而是使用一种称为屏幕误差的方法进行。具体方法如下：
首先假设将要更新的displacement位于屏幕的中心，然后求出此时的camera变换矩阵，遍历displacement中的所有顶点（不包含当前displacement的中心点和四个角上的点），对于每一个顶点，用它的坐标和它所在error edge的算术中点坐标相减，然后用这个值和当前displacement的AABB中心点相加，结果通过camera矩阵进行变换然后将X，Y部分分别除以Z值得到的就是这个顶点在屏幕上的视觉误差了。这是一个非常不容易理解的部分，尤其是除以Z值的部分，其实这样做是为了将其投影到Z为1.0的平面上，省略了进行投影变换的过程，提高了效率。当这个误差大于预定义值就将这个顶点渲染出来。
通过上面的介绍可以看出在HL2中并没有象其它LOD算法一样对每一个displacement硬性的规定一个LOD级别，而是通过每一个顶点的屏幕误差来确定它是否可以被渲染，这样做在渲染非常大的地形时效率不会太好，但是在处理HL2这样的小场景时效率确实非常不错。同时也要注意这种地形方法的优点，它非常适合处理落差非常大的室外场景，如地牢围攻这样比较夸张的地形，不过此时就需要对它的LOD算法进行一下改进，另外在HL2中地形一般都比较小，如果地图设计良好的话基本上很少会渲染hidden surface，因此上不需要做地形tile的HSR，而将这种地形系统扩展到无限地形系统时，必然需要使用一定OC算法来做HSR的工作，这可能是将其扩展到无限地形系统的一个非常具有挑战性的工作了。
你是否正在考虑构建一个游戏引擎呢？你对如何构建一个游戏引擎是否已经有了一个明确的
计划呢？你是否已经对如何组织游戏引擎各个模块之间的关系有了一个通盘的考虑？如果没有，
那么本文将对你建立一个良好的游戏架构提出一些有益的方案，如果你已经对上面的问题有了一
个明确的答案，那么本文不是你需要阅读的内容。本文的目的是给那些没有任何建立完整游戏引
擎经验的人提供一些入门性的知识，使他们初步了解一下如何来构建一个游戏引擎，构建游戏引
擎应该注意哪些方面的问题，并提供了一些成熟的设计模版并指出这些设计模版使用的范围，我
希望这些内容对那些中级编程人员也有一个良好的参考作用。本文的内容来源于一些流行的编程
书籍，具体书目请见本文最后的部分，由于本文是介绍性质的文章，因此如果你对哪方面的内容
非常感兴趣请参考相应的书籍，本文或许有很多错误的地方，如果你有什么看法的话可以通
过Email和我进行讨论，我的地址为dreams_wu@sina.com。
这里必须再次提醒你，本文介绍的是一些通用的游戏编程技巧，虽然是通用但是可能并不是
非常全面，可能存在这样或那样的缺陷，因此如果你希望它发挥最大的效用必须恰当的使用它，
而不是不分场合的滥用。切记切记，一个初学者最容易犯的错误就是任意使用一些设计模版而不
顾它的使用范围。
在开始构建一个游戏引擎时你需要先考虑哪些方面的问题呢？这是你必须认真考虑的问题，
我的答案是首先必须考虑代码的可读性，尤其是在多人进行开发时更必须高度重视，如果你写的
代码其他人需要花费非常大的精力进行阅读，那么根本谈不上提高工作效率，下面是提高代码可
读性的一些良好建议：
1、建立一份简单明了的命名规则。一份良好的命名规则可以大幅提高代码的可读性，规则必须
简单明了，通常只需要两三分钟的阅读应该可以让其他人掌握，例如在代码中直接使用匈牙利
命名法这种大家熟知的规则，使用字母I作为接口类的首字母，使用C开头作为实现类的首字母，
使用g_开头的变量名作为全局变量，s_开头作为静态变量名，m_开头作为内部变量名，使用_开
头作为类内部使用的函数名等等，通过名字就可以使你大概了解对象的使用范围和基本功能。
2、不要讨厌写注释。一个编程者易犯的错误就是不写注释，认为它会增加自己的工作量，但是
他没有考虑到相应的工作量已经转移到代码阅读者的身上，可能看代码的人会花费比写注释时间
两倍或者三倍的时间来阅读代码，这是一种非常不负责任的行为，通过一段简短的注释可以使阅
读者迅速的了解代码的功能，从而把时间更多的用到功能的扩展上。下面是一些良好的建议：尽
量对每一个变量标明它的功能。对每一个函数声明的地方标明它的功能，对于复杂的函数还应当
写清参数和返回值的作用，注意是在声明函数的头文件中。在关键的代码处写清它的作用，尤其
是在进行复杂的运算时更应如此。在每一个类声明的地方简要的介绍它的功能。
3、减少类的继承层次。通常对于游戏编程来说每一个类的继承层次最好不要超过4层，因为过多
的继承不仅会减少代码的可读性，同时使类表指针变长，代码体积增大，减低类的执行效率。还
要注意要减少多重继承，因为不小心它会形成编程者非常讨厌的“钻石”形状。同时还要注意如
果能使用类的组合的话那么就尽量减少使用类的继承，当然这是设计技巧的问题。
4、减少每行代码的长度。尽量不要在一行代码中完成一个复杂的运算，这样做会增加阅读难度，
同时不符合现代CPU的执行，由于CPU现在都使用了超长流水线的设计，它非常适合执行那些每行
代码非常短而行数非常多的代码，例如对一个复杂的数学运算，写成一行不如每一步骤写一行。
以上建议是我的一些粗略看法，如果你还有什么好的看法可以给我指出来，同时上面的建议
并不是绝对的，例如类的继承并不是绝对不能超过4层，如果你需要的话可以使用更多的继承，前
提是这样带来的好处大于代码执行效率的损失。
接着看看要考虑什么，在Game Programming Gems3的《一个基于对象组合的游戏架构》一文
指出了几个值得考虑的问题，首先是平台相关性与独立性和游戏相关性与独立性的问题，也就是
说应当作到引擎的架构与平台和游戏都无关。为什么要做到与平台无关性呢？这是因为你必须在
开始架构引擎考虑它的可移植性，如果在开始你没有注意到这个问题，那么一旦在游戏完成后需
要移植到其他的游戏平台上，你会发现麻烦大了，你需要修改的地方实在是太多了，所有与平台
相关的API调用都需要修改，所有使用了平台特定功能的模块也需要修改，这是一个非常耗费精力
的事情，可能需要花费和开发一个游戏一样的时间，而如果你在开始的时候就考虑到这个问题，
那么非常简单，只需要写一个相应平台的模块替换掉原来的模块即可，这样精力就可以放在如何
充分的利用特定平台的能力来提高游戏的表现力上，而不是代码修改上。下面简单的谈一下如何
使引擎作到与平台无关。
1、注意操作系统的差异。现在主流的操作系统主要是Windows和Linux两种，当然还有Unix和Mac
，在编程时你必须注意这一点，当你需要包含Windows的头文件时，你必须将它包含在宏_WIN32
中，下面是一个简单的例子：
#ifdef _WIN32
#include "windows.h"
#endif
而你使用Windows平台特定的API时也应当如此，这样在其他平台上编译时可以保证Windows平台
相应的代码不会被编译进去。对于其他平台也应当如此。
2、注意编译器的差异。现在通用的编译器主要有VC，BC和gcc几种，在进行Windows平台编程时，
你通常会使用VC或BC，而对Linux平台编程时通常使用gcc，使用VC编译器你不可能编译出用于Linux
平台的代码，因此在编程时也需要注意，你可以使用上面的方法通过特定的宏来将不同的编译器
分离开。举一个简单的例子：
#ifdef _WIN32
#ifdef _MSC_VER
typedef signed __int64 int64;
#endif
#elif defined _LINUX
typedef long long int64;
#endif
在不同的编译器中对64位变量的命名是不同的，因为它并不是C++标准的一部分，而是编译器的扩
展部分。另外一个例子是编译器使用的内联汇编代码，在VC中你可以使用_asm来指明，而对于
Linux平台的编译器你需要使用它的专用关键字了。
3、注意CPU的差异。对于不同平台来说它通常会使用不同的CPU，不过幸好Windows和Linux都支持
X86的CPU，这也是PC游戏的主流CPU平台，而XBOX使用的也是X86的CPU，除非你需要移植到PS2平台
，否则这将大大减轻你的编程负担，在X86平台上提供了一个cpuid的指令可以非常方便的检查CPU
的特性，如是否支持MMX，SSE，SSE2，3DNow!技术等，通过它你可以使用特定的CPU特性来加速你
的代码执行速度。
4、注意图形API的差异。现在图形API主要存在两种主流的平台DirectX和OpenGL，DirectX只能用于
Windows平台，而OpenGL几乎被所有的平台所支持。因此你需要为不同的图形API进行封装，将它做
成不同的模块，在需要的时候进行切换。完成这个工作最好的方法是使用后面介绍的类厂模式。
5、注意显卡的差异。现在显卡有两大主流ATI和NV，虽然显卡可以被主流的操作系统所支持，但是
必须注意在不同的游戏平台上还是使用不同的GPU，而在GPU之间也相应有自己的功能扩展，因此在
使用特定的扩展功能时必须检查一下是否被显卡所支持。
6、注意shader语言的差异。可编程图形语言的出现是最重要的一项发明，现在几乎每一个游戏都
在使用这项技术，而正由于它的重要性现在出现了多个标准，HLSL只能用于DX中，而OpenGL由于
标准的开放性更加混乱，每一个显卡厂商都根据自己的产品推出相应的扩展指令来实现shader，
而NV更推出了GC可以同时适用于DirectX和OpenGL，这是一个非常好的想法，不过由于这不是一个
开放的标准因此没有得到其他厂商的支持，在ATI显卡上运行GC代码你会发现比在NV显卡慢了几个
数量级，由于上面的情况你需要根据不同的平台相应进行封装，方法和第4条一样。下面的建议值得
你去考虑，当你使用DirectX平台时应当使用HLSL，而对于OpenGL可以封装为两个模块，根据显卡
的不同进行切换，也可以使用GC特别为NV的显卡封装一个模块来对它进行优化。
这里需要补充一点，如果可以的话尽量和OGRE一样为不同的操作系统进行封装，这样方便在
不同的系统之间进行切换。
接着看看如何实现游戏无关性，通常游戏引擎如果要实现游戏的无关性是非常困难的，这也就
是说要求你的引擎适合所有的游戏类型，这太难了，考虑一下一个RPG游戏引擎如果用来做一个RTS
游戏那简直是不可能，类似的你不可能拿Q3引擎来做RTS游戏，但是如果引擎设计的非常良好的话
还是可以实现部分的游戏无关性。也就是说你可以将引擎的一部分模块设计成通用的模块，这样在
开发其他类型的游戏时可以重用这部分的代码，这部分代码包括底层显示，声音，网络，输入等
部分，在设计它们时你必须保证它们具有良好的通用性。
在这些问题之后你应当考虑程序的国际化问题。这也是非常重要的方面，因为你的游戏可能在
其它国家发行，这主要是注意语言方面的问题，尤其是字符串的处理，在C++的标准库中提供了一个
String容器，它提供了对国际化的良好支持，因此在引擎中你需要从头到尾的使用它。
接下来我们看看本文最重要的内容，如何组织一个引擎的架构。这是引擎最重要的部分，为什么
重要呢？如果我们把引擎看作一间房子的话，那么架构可以看作是房子的框架，当你完成这个框架
后就可以向框架内添砖加瓦盖房子了。下面让我们来看看如何构建这个框架，通常一个大型的软件
工程是按照模块化的方式来构建的，编程之前要进行必要的需求分析，将软件工程根据不同的功能
划分为几个较大的功能模块，对比较复杂的模块你可能还需要将它分为几个子模块，并需要给出各
个模块之间的逻辑关系。当你编写一个引擎时也需要进行相应的功能分析，让我们看看如何来划分
引擎的功能模块，如果按照上面的游戏无关性和相关性进行分析的话我们可以发现它可以分为游戏
相关层和无关层两层，游戏相关层由于包含了游戏的逻辑性代码也被称为逻辑层。逻辑层应该位于
引擎的最顶层，如果你在开发一个局域网或在线游戏的话，按照网络程序的C/S开发模式，这一层
应该分为两个模块，服务器和客户端模块,它包含了和特定游戏相关的所有功能，如AI，游戏角色，
游戏事件管理，网络管理等等。在它下面就是游戏无关层了，包括了引擎核心模块，GUI模块，文件
系统管理模块等等，其中引擎的核心模块是最重要的部分，逻辑层主要通过它来和底层的模块打交
道，它应该包含场景管理，特效管理，控制台管理，图形处理等等内容。在向下就是一些底层模块
了，如图形渲染模块，输入设备模块，声音模块，网络模块，物理模块，角色模型模块等等，所有
的这些底层模块必须通过核心模块来和逻辑层进行交互，因此核心模块是整个引擎的枢纽，所有的
模块都通过它来进行交互。
下面看看应该如何来进行模块的设计，这里有一些通用的规则是你应当遵守的：
1、减少模块之间的关系复杂度。我们知道通常每一个模块内部都存在大量的对象需要在各个模块
之间进行相互的调用，如果我们假设每一个模块内部对象的数量为N的话，那么每两个模块之间的
关系复杂度为N*N，这样的复杂度是不可接受的，为什么呢？首先是它非常不利于管理，由于各个
模块都存在大量的全局对象，并存在相互依存的关系，并且各自建立的时间各不相同，这就存在
初始化顺序的矛盾，考虑这种情况，一个模块中存在一个对象需要另外一个模块中的对象才能进行
初始化，当这个对象进行初始化时而另外的对象在之前并没有初始化就会引发程序的崩溃。其次，
不利于多人进行同时的开发，由于各个模块存在相互依存的关系，当复杂度非常高时就会出现模块
与模块的高度依存，也就是说一个模块没有完成下一个模块就无法完成，因此就需要一个模块一个
模块按照它的依存关系进行编程，而无法同步进行。因此在设计模块时的第一件事情
是减少模块之间的复杂度，为此你在设计模块时必须为模块设计一个交互接口，并约定所有模块之
间的交互必须通过这个接口来进行，这样模块之间的关系复杂度就降低为1*1了，非常方便管理，同
时这非常利于多人之间进行开发，假如每个人负责一个模块的开发的话，那么你只需要先完成这个
接口类，其他人就可以利用这个接口进行其他模块的开发，而不必等到你完成所有的类再进行，这
样所有的模块都是同步进行，可以节省大量宝贵的开发时间。
2、对类的抽象接口而不是类的实现编程。这是《Design Patten》一书作者对所有软件编程者的建议
，它也对游戏编程有很大的指导意义。对模块中所有被其它模块使用的类都要建立一个抽象接口，
其它模块要使用这个抽象接口进行编程，这样其它模块就可以在不需要知道类是如何实现的情况下
进行编程。这样做的好处是在接口不改变的情况下任意对类的实现进行改变而不必通知其它人，这
对多人开发非常有用。
3、根据调用对象的不同对类进行分层。实际上本条还是对第2条的补充，分层还是为了更好隐藏底
层的实现。通常一个类不仅被其它模块使用还要被自身模块所调用，而且它们需要的功能也不同，
因此我们可以让一个类对外部显现一个接口而对内部也显现一个接口，这样做的好处和上面一样，
因为一个复杂的模块也是多人在进行编程的。
4、通过让一个类对外显现多个接口来减少类的数量。减少关系复杂度的一个方法是减少类的数量，
因此我们可以把完成不同功能的类合并成一个类，并让它对外表现为多个接口，也就是一个类的
实现可以继承多个接口。
上面的建议只是起到参考作用，具体实现时你应该根据情况灵活使用，而不是任意乱用。
下面的内容涉及到具体的编程技巧，
对于引擎中的全局对象你可以使用Singleton，如果你不了解它是什么可以阅读《Design Patten
》，里面有对它的详细介绍，具体的使用可以通过OGRE引擎获得。
调用模块内的对象可以通过类厂来实现。COM可以看作是一种典型的类厂，DX就是使用它来进行
设计的，而著名的开源引擎Crystle Space也是通过建立一个类似的COM物体来实现的，但是我并不
对它很认可，首先构建一个类似COM的类厂非常复杂，开销有点大，其次COM的一个优点是可以对程
序实现向下兼容，这也是DX使用它的重要原因，而一个游戏引擎并不需要。OGRE中也实现了一个类厂
结构，这是一个比较通用的类厂，但是使用起来还是需要写一段代码。我比较欣赏VALVE的做法，它
通过使用一个宏就解决了这个问题，非常高效，使用起来也非常方便。这个做法很简单，它把每个
模块中需要对外暴露的接口都连接到一个内部维护的链表上，每一个接口都和一个接口名相连，这
样外部模块可以通过传入一个接口名给CreateInterface函数就可以获得这个接口的指针了，非常简
单。下面看看它的具体实现。它内部保存的链表结构如下：
class InterfaceReg
{
public:
InterfaceReg( InstantiateInterfaceFn fn , const char *pName );
public:
InstantiateInterfaceFn m_CreateFn;
const char *m_pName;
InterfaceReg *m_pNext;
static InterfaceReg *s_pInterfaceRegs;
};
并定义了两个函数指针和一个函数
#define CREATEINTERFACE_PROCNAME "CreateInterface"
typedef void *(CreateInterfaceFn)( const char *pName , int *pReturnCode );
typedef void *(InstantiateInterfaceFn)( void );
DLL_EXPORT void *CreateInterface( const char *pName , int *pReturnCode );
下面看看它如何通过宏来建立链表
#define EXPOSE_INTERFACE( className , interfaceName , versionName ) \
static void *__Create##className##_Interface() { return (interfaceName*) new className; } \
static InterfaceReg __g_Create##interfaceName##_Reg( __Create_##className##_Interface , versionName );
如果你有一个类CPlayer它想对外暴露接口IPlayer，那么很简单，可以这么做
#define PLAYER_VERSION_NAME "IPlayer001"
EXPOSE_INTERFACE( CPlayer , IPlayer , PALYER_VERSION_NAME );
如果在其他模块内你需要获得这个接口，可以这么做
CreateInterfaceFn factory = reinterpret_cast<CreateInterfaceFn> (GetProcAddress( hDLL , CREATEINTERFACE_PROCNAME ));
IPlayer player = factory( PLAYER_VERSION_NAME , 0 );
其中hDLL为模块的句柄。这里函数指针factory实际指向模块内部的CreateInterface函数，这个
函数通过比较传入的接口名从链表找到指定类指针。
解决了类厂问题，下面让我们看看如何建立模块对外的接口，在Game Programming Gems3的
《一个基于对象组合的游戏架构》一文提出了一种架构，Half Life2引擎中对这种架构进行了有效
的扩展，你可以让所有的对外暴露的接口都使用这个架构，前提是模块只有一个接口对外暴露。
class IAppSystem
{
public:
// Here's where the app systems get to learn about each other
virtual bool Connect( CreateInterfaceFn factory ) = 0;
virtual void Disconnect() = 0;
// Here's where systems can access other interfaces implemented by this object
// Returns NULL if it doesn't implement the requested interface
virtual void *QueryInterface( const char *pInterfaceName ) = 0;
// Init, shutdown
virtual InitReturnVal_t Init() = 0;
virtual void Shutdown() = 0;
};
通过Connect方法你可以将两个模块建立一个连接关系，通过QueryInterface方法你可以检索到其他
需要暴露接口，这种方法很好的为所有的模块建立一个标准的对外接口，极大的减轻了编程的复杂
性，遗憾的是在HL2引擎中只有部分模块使用了这个方法，可能是这个接口引入时间太晚的缘故。
（待续）