回到主题，记录一下镜面反射矩阵的推导。

在用Irrlicht和RTT做镜面效果的时候，用到了反射矩阵。 就是需要把摄相机镜像，渲染一个RT，贴到镜面模型上。这个其实还纠结了许久，因为之前做水面渲染的时候，水面是平的，很好计算摄相机在水面以下的位置。 但是换成镜面，就不一样了，因为镜面可能是任意面。 于是就需要一个通用的反射矩阵。

反射矩阵的计算是基于平面的，因为，任何反射，都需要一个反射面。

所以，我们先给出平面表示 Plane(nx,ny,nz,d); 其中(nx,ny,nz)已经单位化。

然后，我们假设空间中有任意一点P(x,y,z,1)

设这个点P以Plane为反射面的镜像点为P1(x1,y1,z1,w)。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

根据定理，我们知道， 若两个点以某一点为镜像，则两个点的坐标之和除以2，就刚好是中点。

这个理论我们用到这里的话， 那这个中点就刚好是平面上的一个点。 平面上的这个点就是 P(x,y,z,1) - (nx,ny,nz,0)*D .  其中D就是点P到平面的距离

而D=Plane dot P = (x*nx+y*ny+z*nz+d);

由上面的描述，我们马上想到，那么要求点P1的话，就是这样 

(P+P1)/2 = P(x,y,z,1) - (nx,ny,nz,0)*D

=> P1 = P(x,y,z,1) - 2(nx,ny,nz,0)*D

=>P1 = P(x,y,z,1) - 2(nx,ny,nz,0)*(x*nx+y*ny+z*nz+d)

换成矩阵形式则为

                            ｜1-2*nx*nx   -2*nx*ny         -2*nx*nz         0  |

                             | -2*ny*nx     1 - 2*ny*ny     -2*ny*nz         0  |

P1 = {x,y,z,1}   x   | -2*nz*nx     -2*nz*ny         1-2*nz*nz        0  |

                             | -2*d*nx      -2*d*ny           -2*d*nz           1  |

大功告成

btw:这是行主矩阵表示法

目前在正研发中的项目 《帝国来了》

http://v.ku6.com/show/1zMrlsOx0nwpQw3JMoNAjw...html

继爹妈总动员之后的第二个产品 《大话修仙》 （天地劫WEB)

http://xx.sjgame.cn/

处女作 《爹妈总动员》 哎，第一次，给了它。

http://www.87kd.com/game/dmzdy/

公司让我们学习实战经验，临时参与了两个月的《五虎上将》

http://whsj.sjgame.cn/

第一个FALSH技术DEMO KINGDOM RUSH

http://www.cppblog.com/Leaf/archive/2013/02/22/198012.html

HALO 3D引擎DEMO演示

http://www.cppblog.com/Leaf/archive/2013/02/22/198011.html

2部的《天地劫》

http://tdj.sjgame.cn/main.html

在游戏开发的道路上，我想我依然会继续努力、奋斗。 生生不息，不离不弃。。。。

最近在用irrlicht做一个3D试衣间的小项目，为了给项目增添点花样，于是想实现一面镜子。

我记得D3D龙书上有一个使用模板缓冲区实现的例子。网上也有OPENGL实现的例子。 但这一次，我想用irrlicht的RTT实现一面镜子效果。

其实原理和水面反射原理是一样的， 只是没有加扰动而已

第一步：渲染反射贴图

反射贴图的渲染，其实就是将摄相机通过镜面镜像即可，irrlicht中我找了半天，没有发现镜像矩阵的算法，倒是在网上搜到了一个。 很是不错。

同时，也翻阅了一下先前公司引擎项目的代码，发现其实就是那个公式。 有兴趣的朋友可以参看这里

http://www.cnblogs.com/glshader/archive/2010/11/02/1866971.html

通过这个镜面反射矩阵，我们可以将摄相机镜像， 相当于是从镜子里向外看，渲染出一个世界。 在渲染的时候，要记得设置裁剪面。 在我的测试中我没有设置。

第二步：重新渲染世界

重新渲染世界的时候，镜子需要一个特殊的纹理来进行反射贴图。（镜像摄相机空间的投影纹理映射）。 这个贴图方式，就是指忽略镜子的纹理坐标，而通过

镜像摄相机来计算出投影坐标，然后贴在镜子上。在我的测试中，是用SHADER来实现的。 为镜子做了一个特殊的纹理。

下面，我贴一下SHADER，很简单，如果实在不清楚的，可以参考一些投影纹理相关的资料。

顶点着色器代码 HLSL

float4x4    WorldViewProj;
float4x4    MirrorWorldViewProj;
struct VS_OUTPUT
{
    float4 position    :POSITION;

    float3 uv: TEXCOORD0;
};

struct VS_INPUT
{
    float4 position        : POSITION;
    float4 color        : COLOR0;
    float2 texCoord0    : TEXCOORD0;
};

VS_OUTPUT main(VS_INPUT input)
{
    VS_OUTPUT output;
    float4 pos = mul(input.position, WorldViewProj);
    output.position = pos;

    //计算反射纹理的坐标

    pos = mul(input.position,MirrorWorldViewProj);
    output.uv.x = 0.5 * (pos.w + pos.x);
    output.uv.y = 0.5 * (pos.w - pos.y);
    output.uv.z = pos.w;
    return output;
}

像素着色器代码 HLSL

sampler2D colorMap;
struct PS_OUTPUT
{
    float4 color : COLOR0;  
};

struct PS_INPUT
{
    float4 position    : POSITION;
    float3 uv: TEXCOORD0;
};
PS_OUTPUT main( PS_INPUT input )
{
    PS_OUTPUT output;
    float2 uv = saturate(input.uv.xy / input.uv.z);
    output.color = tex2D(colorMap,uv);
    return output;
}

RTT相关的操作，irrlicht的RenderToTexture已经很明白了，再此不在敷述。

上图，收工

本来说是做镜子效果的，结果手工计算的镜面反射矩阵应用在irrlicht相机上的时候，始终无法出现效果，只能去网上搜索

在irrlicht official wiki上发现了这个扩展的WaterNode，下载下来，改了点BUG，整合进了Terrain Demo里， 就是上图的效果。

在我的机器上,HLSL版本是没有问题的，GL版本貌似RTT有点问题。

点击此处下载源代码

http://supertuxkart.sourceforge.net/

由于墙的原因，需要各位搭梯子。

上周末，在弄换装的时候，发现irrlicht引擎本身是不支持硬件蒙皮的，多少令人有些失望。 心里就一直寻思着怎么扩展一下，将它弄出来。

值得说明的是STK对irrlicht引擎的用法是很简单的，基本上可以说是裸用，并未在irrlicht接口上做修改。 而是对外进行了一些必要的扩展。

当然，STK也对外开放了一个irrlicht.dll，说是修改了其中的BUG。 但直接使用irrlicht是可以的。

废话不多说，来说说如何不修改irrlicht一行代码，通过外部扩展来实现硬件骨骼动画吧

首先，能够使我们不修改irrlicht代码的原因，是因为ISkinnedMesh提供了一个setHardwareSkinning接口，默认为false.

虽然这个接口的说明是"(This feature is not implemented in irrlicht yet)”，但并不代表，设置与不设置无差别。

查看代码可以发现，当你设置了这个为true以后，irrlicht就完全不管你的动画了。 意思就是，要是你非要让我干我不干不了的事，那就只有您另请高明了。

irrlicht连CPU计算都不会参与。 这正好让我们有机可乘，完全用GPU接管。

而要让一个顶点参与骨骼计算，那骨骼索引则是少不了的。所以，我们需要想办法让顶点数据能够将骨骼索引代入SHADER中。

在STK中用了一种巧妙的方法， 就是使用了顶点的颜色数据， 虽然这样一来，顶点颜色就用不了了。 但在模型渲染时，顶点颜色很少被使用到的。 也就是说，顶点颜色在STK的动画模型中，被用作了骨骼索引。

初始化骨骼索引的方法很简单，用下面的代码遍历即可。

设：我们有一个骨骼动画模型是 ISkinnedMesh* pSkinnedMesh = …

那么：初始化代码如下

for(u32 i = 0;i < pSkinnedMesh ->getMeshBuffers().size();++i)
{
    for(u32 g = 0;g < pSkinnedMesh ->getMeshBuffers()[i]->getVertexCount();++g)
    {
        pSkinnedMesh ->getMeshBuffers()[i]->getVertex(g)->Color = video::SColor(0,0,0,0);
    }
}

//初始化完毕以后，就是需要真正的索引赋值了，通过以下代码可以完成

const core::array<scene::ISkinnedMesh::SJoint*>& joints = pSkinnedMesh ->getAllJoints();
for(u32 i = 0;i < joints.size();++i)
{
    const core::array<scene::ISkinnedMesh::SWeight>&    weights = joints[i]->Weights;
    for(u32 j = 0;j < weights.size();++j)
    {
        int buffId = weights[j].buffer_id;

        int vertexId = pSkinedMesh->getAllJoints()[i]->Weights[j].vertex_id;
        video::SColor* vColor = &pSkinedMesh->getMeshBuffers()[buffId]->getVertex(vertexId)->Color;

        if(vColor->getRed() == 0)
            vColor->setRed(i + 1);
        else if(vColor->getGreen() == 0)
            vColor->setGreen(i + 1);
        else if(vColor->getBlue() == 0)
            vColor->setBlue(i + 1);
        else if(vColor->getAlpha() == 0)
            vColor->setAlpha(i + 1);
    }
}

//经过以上两个步骤，顶点数据改造完成。 值得注意的是， 在这里， 索引 0 是被认为是无效的

然后，我们来创建一个SHADER作为渲染。

假设 我们将这个pSkinnedMesh绑定了到了一个IAnimatedSceneNode* node 上。

那，我们为这个结点创建一个材质 在创建材质前，我们需要准备一个SHADER回调。 SHADER回调就像下面一样就可以了。

class HWSkinCallBack:public video::IShaderConstantSetCallBack
{
    scene::IAnimatedMeshSceneNode* m_pNode;
public:
    HWSkinCallBack(scene::IAnimatedMeshSceneNode* node):m_pNode(node)
    {

    }
    virtual void OnSetConstants(video::IMaterialRendererServices* services,
        s32 userData)
    {
        scene::ISkinnedMesh* mesh = (scene::ISkinnedMesh*)m_pNode->getMesh();
        f32 joints_data[55 * 16];
        int copyIncrement = 0;

        const core::array<scene::ISkinnedMesh::SJoint*> joints = mesh->getAllJoints();
        for(u32 i = 0;i < joints.size();++i)
        {
            core::matrix4 joint_vertex_pull(core::matrix4::EM4CONST_NOTHING);
            joint_vertex_pull.setbyproduct(joints[i]->GlobalAnimatedMatrix, joints[i]->GlobalInversedMatrix);

            f32* pointer = joints_data + copyIncrement;
            for(int i = 0;i < 16;++i)
                *pointer++ = joint_vertex_pull[i];

            copyIncrement += 16;
        }

        services->setVertexShaderConstant("JointTransform", joints_data, mesh->getAllJoints().size() * 16);
    }
};

好了，现在我们来创建一个材质

s32 hwskm = gpu->addHighLevelShaderMaterialFromFiles(
        "../../skinning.vert","main",video::EVST_VS_2_0,
        "","main",video::EPST_PS_2_0,&hwc,video::EMT_SOLID);

//用新创建出来的材质赋值给这个结点

node->setMaterialType((video::E_MATERIAL_TYPE)hwskm );

//到此，设置完毕。

//最后，就是skinning.vert本身的内容了。 贴出来即可，没有太多技巧，就是一个普通的蒙皮。

// skinning.vert

#define MAX_JOINT_NUM 36
#define MAX_LIGHT_NUM 8

uniform mat4 JointTransform[MAX_JOINT_NUM];

void main()
{
    int index;
    vec4 ecPos;
    vec3 normal;
    vec3 light_dir;
    float n_dot_l;
    float dist;

    mat4 ModelTransform = gl_ModelViewProjectionMatrix;
    index = int(gl_Color.r * 255.99);
    mat4 vertTran = JointTransform[index - 1];
    index = int(gl_Color.g * 255.99);
    if(index > 0)
        vertTran += JointTransform[index - 1];

    index = int(gl_Color.b * 255.99);
    if(index > 0)
        vertTran += JointTransform[index - 1];
    index = int(gl_Color.a * 255.99);
    if(index > 0)
        vertTran += JointTransform[index - 1];
    ecPos = gl_ModelViewMatrix * vertTran * gl_Vertex;
    normal = normalize(gl_NormalMatrix * mat3(vertTran) * gl_Normal);
    gl_FrontColor = vec4(0,0,0,0);
    for(int i = 0;i < MAX_LIGHT_NUM;i++)
    {
        light_dir = vec3(gl_LightSource[i].position-ecPos);
        n_dot_l = max(dot(normal, normalize(light_dir)), 0.0);
        dist = length(light_dir);
        n_dot_l *= 1.0 / (gl_LightSource[0].constantAttenuation + gl_LightSource[0].linearAttenuation * dist);
        gl_FrontColor += gl_LightSource[i].diffuse * n_dot_l;
    }
    gl_FrontColor = clamp(gl_FrontColor,0.3,1.0);

    ModelTransform *= vertTran;
    gl_Position = ModelTransform * gl_Vertex;
    gl_TexCoord[0] = gl_MultiTexCoord0;
    gl_TexCoord[1] = gl_MultiTexCoord1;
    /*
    // Reflections.
    vec3 r = reflect( ecPos.xyz , normal );
    float m = 2.0 * sqrt( r.x*r.x + r.y*r.y + (r.z+1.0)*(r.z+1.0) );
    gl_TexCoord[1].s = r.x/m + 0.5;
    gl_TexCoord[1].t = r.y/m + 0.5;
    */
}

//注：这是GLSL 2.0， 在用IRR做测试的时候，要选GL驱动方式。

还是上个图吧，不上图感觉没有真像。 虽然图看不出来什么动作

为了说明它真的在动，不得不上第二张。

在此，十分感谢Super Tux Kart. 提供了一个学习和扩展irrlicht的榜样.

那就从今天这个用irrlicht做天龙八部的模型换装说起吧。

也不知道是为什么，最近又捣鼓起了OGRE和irrlicht. 并且，总想用irrlicht实现一些OGRE中的东西。

当然，这不是商业项目，也没有商业目的，纯属蛋疼而已。

一切行动的由来，都来自于vczh那天晚上的举动。

记得有一天晚上在群里聊天，大伙就称赞各位菊苣是多么的厉害。

最后vc发了一个自己的桌面截图说：让你们看看菊苣是如何练成的（这不是原话，和话的字眼有出入，在此不想负任何责任，如果真有想看的，去翻群的聊天记录）

那天晚上，我想了很久。想想自己自从转做页游以后，是如何虚渡光阴的。

终于忍不住了，翻开了自己的移动硬盘，看看自己曾经做过的小东西。90%是建好工程就没理了。

这才明白，我花在思考上的时间远远大于了行动。 于是，我决定改变自己，找回那个真的我。

3D游戏是我的真爱， 真爱到就算画面差一点，只要是3D，我也会很喜欢。

于是，我觉得自己还是应该接着先前的路走下去。 什么服务器，什么 AS3. 都是浮云， 不喜欢就是不喜欢。

私下又开始研究irrlicht了。

猛地一发现，自己是多么的搞笑， 从09年到11年，一直在做引擎开发， 也翻过irrlicht和ogre无数遍。 却从来就没有写完过一个完整的DEMO。

连功能测试用例都没有写过。突然觉得之前的一些设计似乎有些脱离了实际。没有真正使用过，又怎知如何是好，如何是坏呢？

这一次是真的玩irrlicht了， 中间也纠结过是不是OGRE更适合。 但在目前这个时间有限的空间下，我更愿意玩irrlicht.小巧，轻便。 当然，意味着更多东西要自己实现。 不过对于一个代码控来说，也反而更自得其乐。 正好可以在短路的时候，去参考一下其它引擎，用来扩充irrlicht.

我要做的不是把irrlicht整得牛B，而是想自己弄弄，加上移动平台的崛起，我觉得irrlicht更加适合吧。 据说gameloft也有使用（仅是据说）。

可能很多兄弟会说我这讲的东西，其实就是一坨屎了。 不过，我觉得再坏的评论，也表示一种关注。 批评好过于无视啊~~~~

----------------------------------------------------------下面说说我遇上的纠结------------------------------------------------

纠结1:换装需要场景节点配合

  在irrlicht中，并没有提供普通引擎中的submesh或者bodypart这种东西，用于直接支持换装。 在irrlicht中，如果想要换装，最直接的方法就是依赖于场景结点

比如,在我的示例中，可以更换头发，帽子，衣服，护腕，靴子，面容。 那就需要7个场景节点，1个作为根节点，用于控制整个角色的世界坐标，平移，缩放，旋转等属性。另外6个场景节点则分别绑有各个部件的模型

贴一下我的角色类的代码，行数不多

class CCharactor
{
    IrrlichtDevice* m_pDevice;
    IAnimatedMeshSceneNode* m_pBodyParts[eCBPT_Num];
    ISceneNode* m_pRoot;
public:
    CCharactor(IrrlichtDevice* pDevice)
        :m_pDevice(pDevice)
    {
        memset(m_pBodyParts,0,sizeof(m_pBodyParts));
        m_pRoot = pDevice->getSceneManager()->addEmptySceneNode(NULL,12345);
    }
    void changeBodyPart(ECharactorBodyPartType ePartType,stringw& meshPath,stringw& metrialPath)
    {
        ISceneManager* smgr = m_pDevice->getSceneManager();

        IAnimatedMeshSceneNode* pBpNode = m_pBodyParts[ePartType];
        IAnimatedMesh* pMesh = smgr->getMesh(meshPath.c_str());
        if(pMesh==NULL)
            return;

        if(pBpNode==NULL)
        {
            pBpNode = smgr->addAnimatedMeshSceneNode(pMesh,m_pRoot);
            m_pBodyParts[ePartType] = pBpNode;
        }
        else
        {
            pBpNode->setMesh(pMesh);
        }
        ITexture* pTexture = m_pDevice->getVideoDriver()->getTexture(metrialPath.c_str());
        if(pTexture)
            pBpNode->setMaterialTexture(0,pTexture);
    }
};

//然后，我用了一个结构体来构建部件信息

struct SBodyPartInfo
{
    stringw Desc;
    ECharactorBodyPartType Type;
    stringw MeshPath;
    stringw MeterialPath;
};

纠结2：共享骨骼

首先，irrlicht 1.8中对OGRE模型的格式支持在代码中，最高只看到了1.40版本的解析，更高的就会被无视。 天龙八部的模型有几个是1.30的，而用于换装和主角的，都是1.40的。 可能是解析不全的原因，导致1.40的骨骼动画无法正常播放。 这个问题整了几个小时，没有解决，明天继续

其次，多个模型共享骨骼只能通过场景节点的useAnimationFrom来完成，并且传入的是一个Mesh参数。这点让人蛋疼， 天龙八部的角色动作是分开了的，不同的攻击动作是一个skeleton文件。 想要实现共享，有点麻烦。

纠结3：模型文件格式

irrlicht不像OGRE那样有一个强大且成熟的模型文件格式,虽然提供了.irr格式，但仅是用于irrEdit的场景信息输出。先看一张图

这张图是irrlicht samples中的MeshViewer的提示框内容。 上面列出了可以支持的模型文件类型。 大家可以看看，又有多少模型格式是可以直接拿来放到项目上用的呢？ mdl和ms3d可以考虑，dae的话，我在开源游戏0 A.D. 中见到使用过。 其它的话，就完全不熟悉了。 OGRE的 .mesh支持也不完全。 难道真要自己整一个。

我能想到的，就是选一个插件完整和模型和动画格式都比较好的作为与美术工具交互的格式。 自己再写一个工具，转换成自己的格式。

纠结4：硬件蒙皮

我以为像NIKO那样的技术狂，怎么会放掉这一个特性。 很高兴地在场景节点上发现了硬件蒙皮的函数接口。但一看注释，把我咽着了。

//! (This feature is not implemented in irrlicht yet)
virtual bool setHardwareSkinning(bool on);

其它地方，还没有去整，就先不发表言论了。 继续着这个很傻B,很天真的捣鼓之路。

上个图，纪念一下我的irrlicht产物。

布衣

换了身盔甲

换了帽子和靴子

PS:头发没有纹理，所以是白的。

用NVPerfHUD挂程序需要被挂的程序自身支持，但是网上有一个老兄写的一个NVPerfHUD Any程序可以帮你完成这个功能。对大多数D9的都有效。除非本身做了破解。

给大家这个链接，自己去解决个人问题。

http://www.thecodeway.com/blog/?p=433

完美时空的引擎很不错，依然坚挺地用着D8。其实挺想挂来看看的，可惜市面上主流的工具都不支持D8，只有D9以及以后的版本。

WOW在CTM的版本中升级了它的渲染引擎，光从水面和火焰就看得出来。　但WOW一向是以负载和流畅度为主，并且WOW本身卖的不是画面。所以若不能帮助提升游戏性的渲染损耗基本上被无视了。　其实吧，个人觉得，做游戏无非就三种了。　一种是追求画面，这一点棒子很有心得。二是追求可玩性，这一点我想WOW应该遥遥领先了吧。　另外一种追求就显得很单纯了－－－钱。　这一点国内许多游戏做得很好，在此就不列名字了，因为比较多。

由于上星期在公司测试新写好的材质和资源管理时，发现ALPHA测试的草丛效果很不理想，于是将草的ALPHA混合开启了，一时间，感觉世界被颠倒了。因为草是按簇画的，排序也只能是按簇排序，当开启了ALPHA混合后，草丛与草丛之间没有太多问题，只是草丛本身出现了像素渲染错误。　不管是Z写和Z测试如何选择开启和关闭。都会有问题。

突然发现草这个东西很特别。

草丛的建模和GPU GEMS 1上的建模方式一样，　三个矩形交叉的方式。

１、它需要用ALPHA混合来实现效果

用ALPHA混合的效果是很不错的。因为可以使边缘柔和。毕竟ALPHA测试会因为图片ALPHA值采样引起的误差导致严重的钜齿。其次就是对美术要求太高了，需要严格控制ALPHA与非ALPHA交界处。

２、但它的行为属性却是一个非透明物体。　

这是因为它必须有深度关系，必需写Z。　因为只有写了Z，才能够正确地与特效等透明物混合，并且也只有写了Z，同一草中的多个面片才能够正常混合。

在忽略其它情况下，我试过了Z测试和Z写的四种组合，也未能达到草丛本身和单棵草都同时达到正确的效果。

还是多看看别人怎么做的吧，所以上来就比较关心WOW的植被渲染了。　当看到下面这样的纹理的时候，我笑了。没想到BLZ的美术资源节约到了这样的程度，真是细致入微啊（这不是拍马屁，试问有多少美术资源是这样做的）。　可以看出，若不采用这样的半张，而用整张，那么就是128X128的大小。

左边为原图，右边为ALPHA通道查看图

而对于树的渲染，则很普通了。设置好纹理，设置好数据和渲染状态，提交绘制即可。

为了看到ALPHA混合的效果，我强忍着把WOW在我7300的显卡上开完了效果。以为会咋的，结果啥也没发生。

WOW的植被的确没有用到ALPHA混合。我失望了。

可能许多人觉得，把多张纹理整合在一张上更好吧。　当然了，这是自然的。　下面就是WOW中经常一起出现的植被的纹理打包图。

大家可以看到，右边的图并没有被裁剪，其原因不言而谕（因为想以非对称营造感觉，并且小件物体纹理本身比较小。）。

发现这草用的是两片，并且大小还不一样。　不知是否真的有此必要。

我最后要说明的是，这文章就算完了。没有结论，也没有感言。因为那样太俗套！

美工把物体贴图和物体颜色，高光等统称为材质。D3D和OPENGL这样的图形接口则把物体表面贴图单独叫做纹理，而把漫反射，高光等叫做材质。

而在游戏引擎或图形引擎中提到的材质，则与此不同。 引擎中提到的材质不仅上面的的内容。 引擎中所谓的材质，是指物体在渲染时一系列的状态控制。 如，ALPHA混合开关以及ALPHA混合因子、纹理过虑方式，纹理通道状态、纹理矩阵、裁剪模式等，在D3D中，就是SetRenderState,SetTextureStageState,SetSamplerStateState等所控制的。在OPENGL中，则大多数由glEnable所控制。

我们所提到的材质系统，则是以此为基础展开的。 上面提到的这些因子，组成了我们的材质。 也是我们在渲染一个物体的时候，提交到设备的状态控制值。 一个物体的一次渲染，我们称作一个PASS。于是我们顺其自然地将这个渲染时的材质控制的最小单位命名为Pass,则：

struct TextureState

{

    void* Texture;

    int ColorOp;

    int ColorAgr1;

    int ColorAgr2;

    int AlphaOp;

    int AlphaAgr1;

    int AlphaAgr2;

.....//更多内容

};

class CPass

{

   CColor mAmbient;

   CColor mDiffuse;

   ....更多内容

    bool mAlphaEnable;

    int mScrBlend;

    int mDstBlend;

    int mCullMode;

   TextureState[4] mTextureStates;

  ...更多内容

};

当我们渲染一个物体的时候，只需要将这个类里面的状态应用到设备，即可完成对物体的绘制。

材质系统的基本内容就是这些，这也是最容易做到的事情。

但是，我们都知道，像D3D或OPENGL这样的图形接口每设置一次GPU状态的时候，都会有一定的开销（通过查看相关文档可以看到某些函数的具体开销值）。而为了保证我们的渲染流畅，我们不得不减少这样的开销。

很自然地，我们会想到，尽量减少切换。而如何减少切换呢。我们可以记录下自己的硬件状态，在设置下一个的时候，先判断当前硬件状态是否相同，如果相同。则不用再设置。 虽然某些图形接口在其层底做了类似的功能。但我们外部判断一下，也未尝不可。从D3D上来讲，外部判断比让其内部判断效率更佳。需要注意的是，由于我们在自己的程序里做了相同判断。因此，当有另一个程序也修改设备状态的时候，就会产生意想不到的效果。所以，我们应该适当的查询一下设备状态，并更新自己的状态记录表。至于这个查询间隔，就要根据自己的实际情况来测试了。

通过记录状态的方法来提升的效率是很不明显的，因此，我们需要对材质进行排序，至于怎么排序，这算法上的问题，在此先不作过多解释。 总之，我们将相似的材质排在一起。由于材质很相似，绘完一个再绘下一个的时候，减少了切换，从而大大提升了效率。

既然已经是涉及到设备了，我们总得考虑一下设备问题。 如果设备不支持我们当前给定的材质状态，怎么办？ 返回FALSE不渲染。还是让程序DOWN掉？  对于一些重要的性能，设备不支持让程序DOWN掉是最好的做法，但是，对于像纹理混合通道不足的情况，让其DOWN掉就显得划不来了。毕竟我们设计的游戏程序是想让更多的玩家能玩不是？ 这样就会涉及到PASS的拆分问题。

对于PASS的拆分，OGRE已经做得很好了。根据用户的设备性能，如果不满足，就一直拆分，拆到用户满足为止，最后让一个物体渲染多次，来实现多个纹理通道混合的效果。 而多PASS则是在渲染的时候不得不考虑的地方，毕竟有些物殊效果非得用多PASS不可。

对于多PASS的设计，我们可以参考OGRE的材质方法或是D3DX的效果框架。我们把完成一个最终效果的方案称作一个渲染技术 Technique ，一个技术可由多个Pass来完成。

class Technique

{

...更多内容

 vector<CPass*> mPasses;

};

这样就满足了我们的需求。  对于同一种效果，我们可以提供多种Technique供程序选择。 而这个选择的条件则可以是根据硬件性能，或是玩家手动选择的配置来实现。

最后结构如下：

class CMaterial

{

public:

...更多内容

vector<CTechnique*> mRenderTechs

};

乱七八糟地说了一通，希望没晕死人！！！

在我们的游戏开发中，通常会遇到两个模块之间的通信。 回调估计是最常用的方式了。 回调的设计思想很简单，就是两个对象相互注册，然后在需要的时候调用对方的函数。

如下：

class B; class A { public: void RegisterCallback(B* pB) { m_pB = pB; } void ActiveA() { m_pB->DoB(); } void DoA(){} protected: B* m_pB; }; class B { public: void RegisterCallback(A* pA) { m_pA = pA; } void ActiveB() { m_pA->DoA(); } void DoB(){} protected: A* m_pA; }; B b; A a; b.RegisterCallback(&a); a.RegisterCallback(&b); a.ActiveA(); b.ActiveB();

这样，当A执行自己的某些动作的时候，就调用B的函数，这样B就会进行自己的更新或是一些处理。

但是，由于两个对象的直接回调，导致了许多不方便之处。特别是当A和B的功能需要扩展的时候。例如：现在A在执行过程中，需要调用B中其它的功能函数。这时候就不得不修改A和B的接口。然后大家都重新编译，连接，执行。

于是，我们就会想会不会有一种更好的方法来解决这一问题。 大家可以想想，WINDOWS中的通信机制：通过解析消息类型来进行处理。是的，消息回调的好处就是方便扩展。 当然我们这里要讲的不是像WINDOWS中那样的消息通信机制，对于我们来说，那种做法过繁琐。

假设现在是想让A通知B一些事情。那么，我们可以把B的void DoB();函数作一点点修改：

void DoB(int MsgID) { switch(MsgID) { case 0: //做相应的事情 break; case 1: //做相应的事情 break; case 2: //做相应的事情 break default: break; } }

同理，当B要通知A的时候，也这样做就行了。

但是，这样也很麻烦，关键在于，如果现在写类A的人并不知道类B的人会怎么写，或者说，类B不知道什么时候要写。另外，如果我们强制类B要实现这样的接口，会有点不现实。

此时，我们决定使用一个中间对象来连接他们。

class ICallback { public: virtual void Do(int MsgID) = 0; };

这就是我们传说中的监听器了。 在OGRE或是一些广泛采用面向对象思想的源程序中，随处可见这样的模式。

还是假设是A需要通知B一些事情。那么，可以在A中注册这个对象，然后调用它的方法就可以了。

class A { public: A() { m_pCallback = NULL; } void RegisterCallback(ICallback* pCall) { m_pCallback = pCall; } void ActiveA(int MsgID) { if(m_pCallback != NULL) m_pCallback->Do(MsgID); } protected: m_pCallback; };

而我们在实现B的时候，除了要实现B自己的东西以外，还需要将ICallBack派生并实现 void Do(int Msg)函数；

class B { public: class CCallback:public ICallback { public: CCallback(B* pB){ m_pB = pB; } void Do(int Msg) { switch(Msg) { case 0: m_pB->DoB(); break; case 1: ..... } } private: B* m_pB; } B( ) { m_pCall = new CCallback(this); } void SetA(A* pA){ m_pA = pA; m_pA->RegisterCallback(m_pCall);} protected: A* m_pA; }

这样，双方便很自然地通了信。而写类A的人根本不需要理会类B的人会怎么写，也不用去管类B会是什么样的类名。只要告诉写类B的人，你需要实现这个Callback接口，并且对应的MsgID是干什么用的就OK了。

也许初初的一看，这是吃力不讨好的工作。毕竟一个写A的人，会去想那么多事情。 而一个写B的人，还要去实现一个Callback类。但是，从可扩展性，和降低耦合上来讲，的确会起不少的作用。

而上面的void Do(int MsgID);函数，可以做得更强大一点。

写成void Do(void* pData); 而这个pData怎么使用，就要看A和B通信的具体内容了。

我正尽力地试着把自己想要说的讲清楚，谢谢！

近日很多朋友咨询Overlay中文显示问题，回答的多了想索性再写个文档算了，放在网上共享，于是就有了本篇。

       在Ogre1.2.5版本中，通过与Ogre官方论坛的开发者讨论实现了Overlay的中文显示，当初的实现非常的怪异，具体的实现可以参见Ogre官方论坛。

随着Ogre的更新，现在Ogre已经发布了1.4.7，1.4系列版本有一个重要的改进，就是加入了UTFString，这为Ogre中文显示予以很大的帮助。为了便于演示，我直接使用Ogre自带的Overlay，也就是大家熟悉的DebugOverlay，测试工程我选择Demo_ParticleFX，选择其他的也没有关系。现在编译它，运行后得到下图：

图的最左下角显示的就是英文DebugOverlay，接下来我们的任务就是把它编程中文的，^_^。

Overlay中文化操作步骤如下

1.      打开OgreSDK\media\packs\ OgreCore.zip。

2.      打开C:\WINDOWS\Fonts，把simhei.ttf添加到OgreCore.zip，（什么，没有simhei.ttf这个文件，那就还其他的中文ttf字体吧）。

3.      打开OgreCore.zip中的Ogre.fontdef，里面有BlueHighway这个字体定义块，在他的下面添加我们的SimHei，code_points里面的一大堆数字看不明白没关系，随后文章会解释。

SimHei

{

       type             truetype

       source         simhei.ttf

       size              16

       resolution  96

       code_points 33-166 24403-24403 21069-21069 24103-24103 36895-36895 29575-29575 24179-24179 22343-22343 26368-26368 39640-39640 20302-20302 19977-19977 35282-35282 24418-24418 25968-25968 37327-37327 25209-25209 27425-27425

}

4.      打开OgreCore.zip中的OgreDebugPanel.overlay，把BlueHighway全部替换成SimHei，我们要使用中文字体了，嘿嘿。

5.      修改完成后，确保所做的修改已经保存到OgreCore.zip。

6.      进入Ogre解决方案，打开文件ExampleFrameListener.h，把54-59行的代码替换如下：

              static String currFps = "Current FPS: ";

              static String avgFps = "Average FPS: ";

              static String bestFps = "Best FPS: ";

              static String worstFps = "Worst FPS: ";

              static String tris = "Triangle Count: ";

       static String batches = "Batch Count: ";

              static DisplayString currFps = L"当前帧速率: ";

              static DisplayString avgFps = L"平均帧速率: ";

              static DisplayString bestFps = L"最高帧速率: ";

              static DisplayString worstFps = L"最低帧速率: ";

              static DisplayString tris = L"三角形数量: ";

              static DisplayString batches = L"批次: ";

7.      最后重新编译工程，下面是我运行的截图，是不是已经显示中文了，^_^。

现在再来看看SimHei中的code_points是如何生成的，这个可以参考我上次写的这篇文章http://www.cnblogs.com/gogoplayer/archive/2008/05/09/1189795.html，至此，实现Overlay中文显示。

转载请注明出处：

作者：gogoplayer

E-mail : gogoplayer@163.com

QQ : 78939328

                                    谢伟亮       feiyurainy@163.com

                               转载请注明出处

    很早以前就想写一些关于OGRE的文章了，一直没机会。

    理解一个渲染引擎，我觉得最重要的是先抓住了它的主架构，它的主线，渲染流程，不然的话，一个引擎几万行，甚至几十万行的代码，光是打开solution就能吓你一跳了，OGRE也有十几万行的代码量，我一开始看它的时候也是无从下手，感觉代码太多了，不知道从哪开始看好，这个class看看，那个class看看，由于对整个引擎没有一个清晰的认识，看过了也印象不深，所以，最后，还是决定先找出它的主线，了解它的渲染流程，这样才能有机地把各个部分联系起来。

    这篇短文也是对OGRE的主要渲染流程的一个介绍，可能对一些class不会太多地去介绍具体的实现细节。我所用的代码都是取自于OGRE的最新的CVS版本。

    读者最好对OGRE有一定的了解，至少得看懂它的example，不然可能一些东西理解起来比较困难。对D3D，OPENGL有一定了解更好。

    如果你看过D3D SDK中带的例子，你一定知道一个比较简单的3D程序要运行起来，至少都会涉及以下的几部分：

    首先是数据的来源，包括顶点数据，纹理数据等，这些数据可以从文件中读取，也可以在程序运行时生成。

    接下来，我们会建立顶点缓冲区把顶点保存起来，建立texture对象来表示texture，对顶点组成的物体设置它在世界坐标系下的坐标，设置摄像机的位置，视点，设置viewport的位置和大小，然后就可以在渲染循环中开始调用渲染操作了，经过了front buffer和back buffer的交换，我们就能在屏幕上看到3D图形了，伪代码如下：

      setupVertexBuffer

      setWorldTransform

      setCamera

      setProjectionTransform

      setViewport

       beginFrame

      setTexture

      drawObject

      endFrame 

     以下就是渲染一个物体的主要步骤，在我看来，这就是3D程序的主线，同样道理，无论你多复杂的渲染引擎，都得实现上述的这些步骤，其他的一些效果如阴影，光照等，都是附着在这条主线上的，所以，如果你能在你所研究的渲染引擎上也清晰地看到这条主线，可能对你深入地研究它会大有帮助，下面，我们就一起来找到OGRE中的这条主线。

     OGRE的渲染循环都是起源于Root::renderOneFrame，这个函数在OGRE自带的example中是不会显式调用的，因为example都调用了Root::startRendering，由startRendering来调用renderOneFrame，如果你用OGRE来写真正的游戏，或者编辑器，你可能就需要在的消息主循环中调用renderOneFrame了，顾名思义，这个函数就是对整个OGRE进行一帧的更新，包括动画，渲染状态的改变，渲染api的调用等，在这个函数中，会包括了我们上述伪代码的几乎全部内容，所以是本文的重点所在。

     进入renderOneFrame，可以看到头尾两个fire函数，这种函数在OGRE中经常出现，一般都是fire…start和fire…end一起出现的，在这些函数中，可能会处理一些用户自定义的操作，如_fireFrameStarted就会对所以的frameListener进行处理，这些fire函数可以暂时不用理会，继续看_updateAllRenderTargets，在这个函数中，会委派当前所用的renderer对所有创建出来的render target进行update，render target也就是渲染的目的地，一般会有两种，一种是render texture，一种是render buffer，接着进入RenderSystem::_updateAllRenderTargets，可以看到在render system中，对创建出来的render target是用RenderTargetPriorityMap来保存的，以便按照一定的顺序来对render target进行update，因为在渲染物体到render buffer时，一般会用到之前渲染好的render texture，所以render texture形式的render target需要在render buffer之前进行更新。

     进入render target的update，可以看到，它仍然把update操作继续传递下去，调用所有挂在这个render target上的viewport的update。

     Viewport其实就是定义了render target上的一块要进行更新的区域，所以一个render target是可以挂多个viewport的，以实现多人对战时分屏，或者是画中画等效果，可以把OGRE中的viewport看成是保存camera和rendertarget这两者的组合，把viewport中所定义的camera所看到的场景内容渲染到viewport所定义的render target的区域里。

     Viewport还有一个重要信息是ZOrder，可以看到RenderTarget中的ViewportList带有一个比较函数，所以在RenderTarget::update中，ZOrder越小的，越先被渲染，所以，如果两个viewport所定义的区域互相重叠了，而且ZOrder又不一样，最终的效果就是ZOrder小的viewport的内容会被ZOrder大的viewport的内容所覆盖。

     继续进入Viewport::update，就像前面所说，它调用它所引用的camera来渲染整个场景，而在Camera::_renderScene中，是调用SceneManager::_renderScene(Camera* camera, Viewport* vp, bool includeOverlays)。SceneManager::_renderScene里就是具体的渲染流程了。从函数名称还有参数也可以看出来，这个函数的作用就是利用所指定的camera和viewport，来把场景中的内容渲染到viewport所指定的render target的某块区域中。根据camera，我们可以定出view matrix，projection matrix，还可以进行视锥剔除，只渲染看得见的物体。注意，我们这里只看标准的SceneManager的方法，不看BspSceneManager派生类的方法，而且，我们会抛开跟主线无关的内容，如对shadow的setup，骨骼动画的播放，shader参数的传递等，因为我们只注重渲染的主流程。

     在SceneManager::_renderScene中所应看的第一个重要函数是_updateSceneGraph，OGRE对场景的组织是通过节点树来组织的，一个节点，你可以看成是空间中的某些变换的组合，如位置，缩放，旋转等，这些变换，会作用到挂接在这些节点上的具体的物体的信息，也就是说，节点保存了world transform，对具体的物体，如一个人，在空间中的定位，都是通过操作节点来完成的。同时节点还保存了一个世界坐标的AABB，这个AABB能容纳所有它所挂接的物体的大小，主要是用于视锥裁减的，如果当前摄像机看不见某个节点的AABB，那么说明摄像机看不见节点所挂接的所有物体，所以在渲染时可以对这个节点视而不见。

     _updateSceneGraph的内部处理比较繁琐，我们只需知道，经过了_updateSceneGraph，场景节点树中的每个节点都经过了更新，包括位置，缩放，和方位，还有节点的包围盒。

     继续回到SceneManager::_renderScene，接下来要看的是setViewport，它会调用具体的renderer的setviewport的操作，设置viewport中所挂接的render target为当前所要渲染的目标，viewport中的区域为当前所要渲染的目标中的区域。

     接下来要碰到OGRE渲染流程中的一个重要的概念，Render Queue。这个东西实在内容比较多，还是以后有机会单独提出来说吧，你可以简单把它想成是一个容器，里面的元素就是renderable，每个renderable可以看成是每次调用drawprimitive函数所渲染的物体，可以是一个模型，也可以是模型的一部分。在RenderQueue中，它会按材质来分组这些renderable，还会对renderable进行排序。

     在每一次调用SceneManager::_renderScene时，都会调用SceneManager::prepareRenderQueue来清理RenderQueue，然后再调用SceneManager::__findVisibleObjects来把当前摄像机所能看见的物体都加入到RenderQueue中。

     SceneManager::__findVisibleObjects是一个递归的处理过程，它从场景的根节点开始，先检查摄像机是否能看见这个节点的包围盒（包围盒在_updateSceneGraph时已经计算好了），如果看不见，那么这个节点，还有它的子节点都不用管了。如果能看见，再检测挂在这个节点上的所有MovableObject，如果当前所检测的MovableObject是可见的，就会调用它的_updateRenderQueue方法，一般在这个方法里就可以把和这个MovableObject相关的renderable送入RenderQueue了。

     这里要说说MovableObject，MovableObject主要是用于表示场景中离散的物体，如Entity，顾名思义，能移动的物体，不过它的“能移动”这个能力是要通过SceneNode来实现的，所以MovableObject来能显示出来，首先得先挂接在某个场景节点上，通过场景节点来定位。你可以控制MovableObject的一些属性，如某个MovableObject是否要显示，是否要隐藏，都可以通过MovableObject::setVisible方法来实现。

     检测完该节点上的MovableObject之后，就继续调用所有子节点的_findVisibleObjects方法，一直递归下去。这样，就能把场景中所有要渲染的renderable所加入到RenderQueue中了。

     至此，我们就拥有了要渲染的物体的信息了，接下来就是对这些物体进行渲染了，你会发现跟D3D或OpenGL的代码很类似的调用：

       mDestRenderSystem->clearFrameBuffer

      mDestRenderSystem->_beginFrame   

       mDestRenderSystem->_setProjectionMatrix

       mDestRenderSystem->_setViewMatrix

       _renderVisibleObjects();

      mDestRenderSystem->_endFrame();

     这些api的作用和D3D中的类似调用的作用都差不多，这里再说一下_renderVisibleObjects()，在这个函数中，会对RenderQueue中的每个renderable进行渲染，用的是visitor模式来遍历操作每个renderable，最终在SceneManager::renderSingleObject中取出每个renderable所保存的顶点，索引，世界矩阵等信息，来进行渲染。这其中还包括了查找离该renderable最近的光源等操作，比较复杂。

     到这里，SceneManager::_renderScene的流程基本走完了，也就是说，OGRE一帧中的渲染流程差不多也结束了，你应该也发现，这个流程跟你用D3D写一个简单程序的流程基本是一样的，在这个流程的基础上，再去看具体的实现，如怎么样设置纹理，怎么样调用你熟悉的D3D或OpenGL的API来渲染物体，应该会简单得多。

     对OGRE的渲染流程的大概介绍到这里也结束了，很多细节都没涉及，以后有机会再写吧。

《游戏中的资源管理――资源高速缓存》
转载请注明出处：http://groups.google.com/group/jianguhan


1.什么是资源高速缓存
    资源高速缓存的原理与其它内存高速缓存的工作原理是相似的。在游戏的状态转换过程中，有些数据是刚才使用过的，那么直接从资源高速缓存中载入即可。例如，RPG­游戏中主角从大地图进入一个房间，探索一番后主角退出房间，此时只要直接从缓存中载入大地图数据即可，节省了从硬盘载入数据的时间，要知道从硬盘载入数据是非常­慢的。当然，如果你的游戏所使用的数据文件很少，那么你可以在游戏运行过程中把这些数据完全储存在内存中，而不使用资源高速缓存。

2.一个简单的资源高速缓存管理器
    下面我将向你展示一个比较简单的资源高速缓存管理器，源代码来自我上一个游戏，如果你需要知道更多关于资源高速缓存方面的知识，请参考<<Game Coding Complete>>的第八章。
首先，需要一个机制来唯一标识一个资源，我们用下面这个结构来做资源句柄：
struct ResHandle
{
     ResHandle(std::string &resName, void *buffer, int size)
     {
         m_resName = resName;
         m_size   = size;
         m_buffer = buffer;
     }

     ~ResHandle()
     {
         if (m_buffer != 0) delete[] m_buffer;
     }

     std::string   m_resName;    //资源名
     void          *m_buffer;    //资源句柄所标识的资源
     DWORD         m_size;       //资源所占内存大小

};

好了，现在我们可以从资源名来找出这个资源了，接下来实现这个资源高速缓存管理器：
class CacheManager
{
public:
     CacheManager();
     ~CacheManager();

     //载入资源，resName为资源名，若载入成功size被设为该资源的大小
    //注意，管理中的资源不能在管理器外用delete显示的删除它
    void*    Load(std::string resName, DWORD *size = 0);
    //设置缓存大小，单位MB
     void      SetCacheSize(int sizeMB)    { m_cacheSize = sizeMB * 1024 * 1024; }
     //得到缓存大小，单位MB
     int      GetCacheSize()              { return m_cacheSize / 1024 /1024; }

private:
     void     Free();                          //释放lru链表中最后一个资源
     void     *Update(ResHandle *res);         //更新lru链表
     ResHandle *Find(std::string &resName);     //找出该资源名的资源句柄

private:
     DWORD m_cacheSize;     //缓存大小
     DWORD m_allocated;     //已使用的缓存大小

//lru链表，记录最近被使用过的资源
     std::list<ResHandle*>                m_lru;  
    //资源标识映射
     std::map<std::string, ResHandle*>    m_resources;

};

CacheManager:: CacheManager ()
{
     m_cacheSize = 0;
     m_allocated = 0;

}

CacheManager::~ CacheManager ()
{
          while (!m_lru.empty()) Free();   //释放所有管理中的资源

}

void * CacheManager::Load(std::string resName, DWORD *size)
{
     ResHandle *handle = Find(resName);   //查找该资源是否在缓存中

     if (handle != 0) //如果找到该资源句柄，则返回该资源并更新lru链表
     {
         if (size != 0) *size = handle->m_size;
         return Update(handle);
     }
     else
     {
         //先检测资源大小
         DWORD _size = 资源大小;

         //是否有足够空间?
         while (_size > (m_cacheSize - m_allocated))
         {
              if (m_lru.empty()) break;
              Free();
         }
         m_allocated += _size;

         buffer = new char[_size];
//在这里用任何你能想到的办法载入资源文件到buffer
         …
         …

//记录当前资源
         ResHandle *handle = new ResHandle(resName, buffer, _size);
         m_lru.push_front(handle);
         m_resources[resName] = handle;

         if (size != 0) *size = _size;
         return buffer;
     }

     return 0;

}

void CacheManager::Free()
{
     std::list<ResHandle*>::iterator gonner = m_lru.end();
     gonner--;
     ResHandle *handle = *gonner;
     m_lru.pop_back();
     m_resources.erase(handle->m_resName);
     m_allocated -= handle->m_size;
     delete handle;

}

void * CacheManager::Update(ResHandle *res)
{
     m_lru.remove(res);
     m_lru.push_front(res);
     m_size = res->m_size;
     return res->m_buffer;

}

ResHandle * CacheManager::Find(std::string &resName)
{
     std::map<std::string, ResHandle*>::iterator it = m_resources.find(resName);
     if (it == m_resources.end()) return 0;
     return (*it).second;

}

至此，你已经可以在游戏中缓存任何你想缓存的资源了^_^

3. 资源管理进阶
    至此你已经可以在游戏中缓存任何你想缓存的资源了，但是你的任务还没完成，当你请求的资源存在于缓存之外时，那个闪耀的硬盘灯可能就是玩家最感兴趣的东西了。
因此你必须根据不同的游戏类型使用不同的载入方式： 
    一次载入所有东西：适用于任何以界面或关卡切换的游戏 
    只在关键点载入资源：很多射击游戏都使用这样的设计，如“半条命” 
    持续载入：适用于开放型地图的游戏，如“侠盗猎车手”
    如果有可能的话，你还可以使用缓存预测机制，当CPU有额外时间的时候可以把未来可能用到的资源载入到资源高速缓存。
    最后，尽管在游戏的资源管理中资源打包不是必须的，但仍然建议大家把资源文件按类型分别打包到单一的文件中，这将为你节省磁盘空间，并加快游戏的载入速度。

出自http://blog.csdn.net/duzhi5368/archive/2008/04/22/2314232.aspx

使用设计模式来提高程序库的重复利用性是大型程序项目开发必须的。但是在“四人帮”的设计模式概述中提到了23种标准设计模式，不但难以记住，而且有些设计模式更多的适用于应用程序开发，对游戏项目引擎设计并没有很多的利用价值。根据经验，精挑细选后，笃志在这里记录一些自认为有利用价值的设计模式，以便之后自己设计时使用。

一：观察者Observer

观察者的设计意图和作用是： 它将对象与对象之间创建一种依赖关系，当其中一个对象发生变化时，它会将这个变化通知给与其创建关系的对象中，实现自动化的通知更新。

       游戏中观察者的适用环境有：

1：UI控件管理类。当我们的GUI控件都使用观察者模式后，那么用户的任何界面相关操作和改变都将会通知其关联对象-----我们的UI事件机。

2：动画管理器。很多时候我们在播放一个动画桢的时候，对其Frame有很大兴趣，此时我们设置一个FrameLister对象对其进行监视，获得我们关心的事件进行处理是必须的。

观察者伪代码：

//-------------------------------------------------------------------------------------------------------

// 被观察对象目标类

Class Subject

{

       // 对本目标绑定一个观察者 Attach( Observer );

       // 解除一个观察者的绑定   DeleteAttach( Observer );

       // 本目标发生改变了，通知所有的观察者，但没有传递改动了什么

       Notity()

       {

              For ( …遍历整个ObserverList …)

              { pObserver ->Update(); }

}

// 对观察者暴露的接口，让观察者可获得本类有什么变动GetState();

}

//-------------------------------------------------------------------------------------------------------

// 观察者/监听者类

Class Observer

{

       // 暴露给对象目标类的函数，当监听的对象发生了变动，则它会调用本函数通知观察者

Void Update ()

{

pSubject ->GetState(); // 获取监听对象发生了什么变化

TODO：DisposeFun(); // 根据状态不同，给予不同的处理

}

}

//-------------------------------------------------------------------------------------------------------

非程序语言描述：

A是B的好朋友，对B的行为非常关心。B要出门，此时A给了B一个警报器，告诉B说：“如果你有事，立刻按这个警报器告诉我。”。结果B在外面遇上了麻烦，按下警报器（Update()），B就知道A出了事，于是就调查一下B到底遇到了什么麻烦(GetState())，当知道B原来是因为被人打了，于是立刻进行处理DisposeFun()，派了一群手下帮B打架。

当然关心A的人可以不止一个，C，D可能也对A很关心，于是A这里保存一个所有关心它的人的链表，当遇到麻烦的时候，轮流给每个人一份通知。

二：单件模式Singleton

单件模式的设计意图和作用是：    保证一个类仅有一个实例，并且，仅提供一个访问它的全局访问点。

游戏中适用于单件模式的有：

1：所有的Manger。在大部分的流行引擎中都存在着它的影子，例如SoundManager, ParticeManager等。

2：大部分的工厂基类。这一点在大部分引擎中还是见不到的，实际上，我们的父类工厂采用唯一实例的话，我们子类进行扩展时也会有很大方便。

单件模式伪代码：

//-------------------------------------------------------------------------------------------------------

Class Singleton

{

       Static MySingleton;       // 单件对象，全局唯一的。

       Static Instance(){ return MySingleton;}              // 对外暴露接口

}

//-------------------------------------------------------------------------------------------------------

三：迭代器Iterator

       迭代器设计意图和作用是：    提供一个方法，对一个组合聚合对象内各个元素进行访问，同时又不暴露该对象类的内部表示。

       游戏中适用于迭代器模式的有：    因为STL的流行，这个设计已经广为人知了，我们对任何形式的资源通一管理时，不免会将其聚合起来，或者List，或者Vector，我们都需要一个对其进行访问的工具，迭代器无疑是一个利器。

       迭代器伪代码：

//-------------------------------------------------------------------------------------------------------

// 迭代器基类

       Class Iterator

{

              Virtual First();              

              Virtual Next();

              Virtual End();

              Virtual CurrentItem();    // 返回当前Item信息

}

//-------------------------------------------------------------------------------------------------------

// 聚合体的基类

       Class ItemAggregate

{

              Virtual CreateIterator(); // 创建访问自身的一个迭代器

}

//-------------------------------------------------------------------------------------------------------

// 实例化的项目聚合体

       Class InstanceItemAggregate : public ItemAggregate

       {

              CreateIterator(){ return new InstanceIterator(this); }

}

//-------------------------------------------------------------------------------------------------------

四：访问者模式Visitor：

       访问者设计意图和作用是：    当我们希望对一个结构对象添加一个功能时，我们能够在不影响结构的前提下，定义一个新的对其元素的操作。（实际上，我们只是把对该元素的操作分割给每个元素自身类中实现了而已）

       游戏中适用于访问者模式的有：    任何一个比较静态的复杂结构类中都适合采用一份访问者。这里的“比较静态的复杂结构类”意思是，该结构类中元素繁多且种类复杂，且对应的操作较多，但类很少进行变化，我们就能够将，对这个结构类元素的操作独立出来，避免污染这些元素对象。

       1：例如场景管理器中管理的场景节点，是非常繁多的，而且种类不一，例如有Ogre中的Root, Irrchit中就把摄象机，灯光，Mesh，公告版，声音都做为一种场景节点，每个节点类型是不同的，虽然大家都有共通的Paint(),Hide()等方法，但方法的实现形式是不同的，当我们外界调用时需要统一接口，那么我们很可能需要需要这样的代码

       Hide( Object )

       { if (Object == Mesh) HideMesh(); if (Object == Light) HideLight(); … }

此时若我们需要增加一个Object新的类型对象，我们就不得不对该函数进行修正。而我们可以这样做，让Mesh,Light他们都继承于Object,他们都实现一个函数Hide(),那么就变成

       Mesh::Hide( Visitor ) { Visitor.Hide (Mesh); }

       Light::Hide(Visitor ){ Visitor.Hide (Light); }

我们在调用时只需要Object.Hide(Visitor){ return Visitor.Hide(Object); }

这样做的好处，我们免去了对重要函数的修正，Object.Hide(Visitor){}函数我们可以永久不变，但是坏处也是很明显的，因为将方法从对象集合结构中抽离出来，就意味着我们每增加一个元素，它必须继承于一个抽象的被访问者类，实现其全部函数，这个工作量很大。

所以，访问者是仅适合于一个装载不同对象的大容器，但同时又要求这个容器的元素节点不应当有大的变动时才使用。另外，废话一句，访问者破坏了OO思想的。

       访问者伪代码：

//-------------------------------------------------------------------------------------------------------

// 访问者基类

       Class Visitor

{

              Virtual VisitElement( A ){ … };             // 访问的每个对象都要写这样一个方法

              Virtual VisitElement( B ){ … };

}

// 访问者实例A

Class VisitorA

{

       VisitElement( A ){ … };         // 实际的处理函数

VisitElement( B ){ … };        // 实际的处理函数

}

// 访问者实例B

Class VisitorB

{

       VisitElement( A ){ … };         // 实际的处理函数

VisitElement( B ){ … };        // 实际的处理函数

}

// 被访问者基类

Class Element

{

       Virtual Accept( Visitor );        // 接受访问者

}

// 被访问者实例A

Class ElementA

{

       Accecpt( Visitor v ){ v-> VisitElement(this); };    // 调用注册到访问者中的处理函数

}

// 被访问者实例B

Class ElementB

{

       Accecpt( Visitor v ){ v-> VisitElement(this); };    // 调用注册到访问者中的处理函数

}

//-------------------------------------------------------------------------------------------------------

五：外观模式Façade

       外观模式的设计意图和作用是：  将用户接触的表层和内部子集的实现分离开发。实际上，这个模式是个纸老虎，之后我们看伪代码立刻就会发现，这个模式实在用的太频繁了。

       游戏中需要使用外观模式的地方是：   这个非常多了，举几个比较重要的。

       1：实现平台无关性。跨平台跨库的函数调用。

       2：同一个接口去读取不同的资源。

       3：硬件自动识别处理系统。

       外观模式伪代码

//-------------------------------------------------------------------------------------------------------

       // 用户使用的接口类

       Class Interface

{

// 暴露出来的函数接口函数，有且仅有一个，但内部实现是调用了两个类

       Void InterfaceFun()

{

       // 根据某种条件，底层自主的选择使用A或B的方法。用户无须关心底层实现

       If ( XXX )

       {

              ActualA->Fun();

}

Else

{

       ActualB->Fun();

}

};   

}

// 实际的实现，不暴露给用户知道

Class ActualA

{

       Void Fun();

}

// 实际的实现，不暴露给用户知道

Class ActualB

{

       Void Fun();

}

怎么样，纸老虎吧，看起来很高深摸测的命名而已。

//-------------------------------------------------------------------------------------------------------

六：抽象工厂模式AbstractFactory

       抽象工厂的设计意图和作用是：    封装出一个接口，这个接口负责创建一系列互相关联的对象，但用户在使用接口时不需要指定对象所在的具体的类。从中文命名也很容易明白它是进行批量生产的一个生产工厂的作用。

       游戏中使用抽象工厂的地方有：    基本上任何有批量的同类形式的子件地方就会有工厂的存在。（补充一句：下面代码中的ConcreteFactory1实例工厂就是工厂，而抽象工厂仅仅是工厂的一个抽象层而已。）

1：例如，在音频方面，一个音频的抽象工厂派生出不同的工厂，有音乐工厂，音效工厂。音效工厂中又有一个创建3D音效节点的方法，一个创建普通音效节点的方法。最终用户只需要SoundFactory->Create3DNode( pFileName );就可以创建一个节点了。

2：场景对象。

3：渲染对象。

4：等等……

工厂与单件，管理器Manager关系一定是非常紧密的。

       抽象工厂伪代码：

//-------------------------------------------------------------------------------------------------------

       class AbstractProductA {}; // 抽象的产品A基类
　　class AbstractProductB {}; //抽象的产品B基类

// 抽象工厂基类
　　class AbstractFactory
　　{
　　public:
　　　virtual AbstractProductA* CreateProductA() = 0 ;// 创建ProductA
　　　virtual AbstractProductB* CreateProductB() = 0 ;// 创建ProductB
       } ;

　　class ProductA1 : public AbstractProductA {};    // 产品A的实例1
　　class ProductA2 : public AbstractProductA {};    // 产品A的实例2

　　class ProductB1 : public AbstractProductB {};    // 产品B的实例1
　　class ProductB2 : public AbstractProductB {};    // 产品B的实例2

// 实例工厂1

     class ConcreteFactory1 : public AbstractFactory
　　{
　　　　virtual AbstractProductA* CreateProductA() { return new ProductA1() ; }
　　　　virtual AbstractProductB* CreateProductB() { return new ProductB1() ; }
　　　    static ConcreteFactory1* Instance() { } 　　     // 实例工厂尽量使用单件模式
　　} ;

// 实例工厂2

class ConcreteFactory2 : public AbstractFactory
　　{
　　　　virtual AbstractProductA* CreateProductA() { return new ProductA2() ; }
　　　　virtual AbstractProductB* CreateProductB() { return new ProductB2() ; }
　　　　static ConcreteFactory2* Instance() {}        // 实例工厂尽量使用单件模式
　　} ;

}

//-------------------------------------------------------------------------------------------------------

客户端代码：

Void main()
{
　　AbstractFactory *pFactory1 = ConcreteFactory1::Instance() ;
　　AbstractProductA *pProductA1 = pFactory1->CreateProductA() ;
　　AbstractProductB *pProductB1 = pFactory1->CreateProductB() ;
　　AbstractFactory *pFactory2 = ConcreteFactory2::Instance() ;
　　AbstractProductA *pProductA2 = pFactory2->CreateProductA() ;
　　AbstractProductB *pProductB2 = pFactory2->CreateProductB() ;
}

//-------------------------------------------------------------------------------------------------------