不管使用那种方式，都需要将离散点进行插值（interpolation）以便得到平滑路径。这里就牵涉到位置插值和朝向插值。

     从插值函数上可分为三类：1）线性；2）多项式；3）样条。顾名思义，线性插值采用线性函数，多项式插值采用多项式，而样条插值则采用了一组多项式组成的分段函数。由于摄像机的关键路径点通常都会大于2个，所以插值方法上就必须选取样条方法。

一、位置插值

1.1 样条类型选择

     在这里我们仅考虑三次样条插值，因为它们可达到C2连续。三次样条中主要以Bezier、Catmull-Rom、均匀B样条为考查对象，它们都具有计算开销小的优点。可以通过下面公式来定义它们：

     简化为：

     下面表格列出了三种插值曲线对应的G和M：

     如下图所示，对4个点进行Bezier插值得到的曲线只会有两个点被曲线穿过，而B-Spline插值得到的曲线不会经过控制点，只有Catmull-Rom Spline可以得到穿过除起点和终点之间的所有控制点。正因为Catmull-Rom具有这个特性，使得它被广泛地应用在关键帧平滑插值上，因此我们选择了Catmull-Rom样条作为摄像机位置点的插值算法。

1.2 实现

参考：

[1] Mathematics for 3D Game Programming and Computer Graphics 3e by Eric Lengyel

[2] http://en.wikipedia.org/wiki/Catmull-Rom_spline#Catmull.E2.80.93Rom_spline

[3] http://www.codeproject.com/Articles/30838/Overhauser-Catmull-Rom-Splines-for-Camera-Animatio

二、朝向（旋转）插值  

2.1 Euler Angles VS Quaternion        

     三维空间中描述旋转的主要方法有Euler Angles和Quaternion。Euler Angles有三个明显的问题：1）三轴上的旋转顺序敏感；2）Gimbal Lock现象导致旋转自由度丢失；3）独立地对三个旋转分量进行插值，忽略了三轴之间的依赖关系，导致插值结果不理想。与Euler Angles不同的是，Quaternion没有将旋转分解到三个轴向上，而是用一个旋转轴和绕该轴的旋转角度来描述，所以从根本上消除了Euler Angles的三大问题。有关Quaternion的详细描述可参考[1]，在此不再累述。

2.2 LERP VS SLERP

     四元数线性插值（Linear Quaternion interpolation）的计算公式为：

     四元数球面线性插值（Spherical Linear Quaternion interpolation）的计算公式为：

     其中，θ为两个四元数的夹角。

     为了方便展示，我们考虑在2D情况对角度V进行两次插值，两种算法在插值效果上存在的差异，如下图（b为LERP、c为SLERP）：

     从图中可以看出LERP其实是对两四元数在圆上的弦进行了等分，而SLERP则是对圆弧进行等分。由此得出的结论是，SLERP得到了比LERP更平滑的插值结果。

     为了保证插值曲线的C2连续性，需要使用球面四边形插值（Spherical Quadrangle interpolation）方法。例如，对q1和q2插值，首先要用q0、q1、q2、q3计算出两个控制点（Inner Quadrangle Point），公式如下：

     然后通过下式得到最终插值结果：

2.3 实现

     上面代码没有考虑两个四元数之间夹角大于180°的情况。例如，考虑q1->q2的插值角度θ>180°，我们可以让q1->q2反向旋转2π-θ，即旋转-(2π-θ)，根据四元数的定义[v*sin(θ/2) , cos(θ/2)]，那么对q2进行处理变为[-v*sin(θ/2) , -cos(θ/2)]。这个处理可以放在AddSplinePoint中来做：

参考：

[1] Quaternions, Interpolation and Animation by EB Dam - 1998

[2] Game Engine Architecture by Jason Gregory - 2009

[3] https://theory.org/software/qfa/writeup/node12.html

     内存泄漏检测的基本步骤是：1）包装（重载）内存分配/释放API；2）进行内存分配时记下相关信息：地址、大小、调用栈；3）释放时清除之前记录的对应信息；4）程序退出时（确保在所有内存释放操作完成之后），输出剩下的记录。其中，对进行分配操作是的调用栈回溯是个重点信息，它能够帮助我们找出内存泄漏代码。

     Windows中的Dbghelp库提供了丰富的调试API。StackWalk应该是进行栈回溯最直接的一种接口了，但是它不够快。如果能先记录下调用栈上的CALL指令地址，然后在输出日志时解析出符号，将会大大降低检测机制对程序本身性能的影响。Dbghelp库中提供了Sym*FromAddr系列API，可以通过指令地址获取函数符号，那么剩下的就是如何记录指令地址的问题了。从网上借了一张x86调用栈示意图，如下：

     从图中可以看出，Callee的EBP始终指向Caller的EBP，EBP下面是指向Caller下一条指令（注意x86体系下栈的增长方向是小地址），因此通过EBP就可以回溯整个调用栈了。通过下面代码可以实现此功能：

     宏参数frame是个void*指针数组，数组的大小取决于想要回溯的栈深度。内存分配和回收的包装代码如下：

     我们看到，内存管理系统内部终究还是要使用语言提供的内存分配/释放API，只要配对实现了分配与释放管理，系统内部的无泄漏是很容易保证的。在这里着重讲解原理，就不重载new/delete operator了。最后看一下调用栈函数符号的回溯代码：

     我们用下面代码做测试用例：

     泄漏检测结果：

参考：

[1] Using DbgHelp

[2] Intel x86 Function-call Conventions - Assembly View

     我想了两种方案，最初的方案灵感来自光线反射，如下图所示。

     因为阻挡格子是轴对齐的，通过法向量n可以得到b点的反射向量e'-o，将|e'-o|限定在一个固定值，此时如果e'不在阻挡里面，就将它作为新的终点。该方案的实验结果不太令人满意，当角色离阻挡较近时断续感太明显，因为|e' - b|的长度较短。另外它不能处理e'在阻挡里的情况，被卡住不动的概率依然较大。

     第二种方案是根据移动趋向在一个轴向找一个可达试探点，然后用限制了搜索空间（搜索节点在50以内）的A*算法找到一条到试探点的路径，如下图。

     设diff_x = 终点x - 起点x，diff_y = 终点y - 起点y，当diff_x > diff_y，认定为趋向x方向上移动，在这种情况下在终点y轴向上±10个格子内去找到一个最接近终点的无阻挡点（称它为可达试探点）。由于试探点与玩家当前点极有可能是直线不连通的，而且它们不可能太远，所以使用了一个将搜索节点个数限制在50以内A*来得到一条路径。该方案大部分情况都能在边缘找到合理点，但如果玩家垂直面朝阻挡内移动且不能在限制搜索范围内找到可达点，角色就会卡住不动，这种情况就只能让玩家自己调整一下朝向了。

void ActorMgr::GetPlayerEntityIDs( lua_Object lua_table )
{
       TEntityListIt tIt ;
       std::list <int> result;

       for(int i = 0; i < ACOTOR_BUCKET_LEN ; ++i)
      {
             for(tIt =mSceneEntities[i].mEntities.begin(); tIt != mSceneEntities[i].mEntities.end( ); ++tIt )
            {
                   TActorPtr tpActor  = tIt->second->mpActor ;
                   if(tpActor ->GetActorType() == LOCAL_PLAYER)
                  {
                         result.push_front(tpActor->GetEntityID());
                  }
                   else if (tpActor-> GetActorType() == REMOTE_PLAYER )
                  {
                         result.push_back(tpActor->GetEntityID());
                  }
            }
      }
       lua_State* L = LuaVM::GetInstPtr()->mLS ;
       assert(lua_istable (L , -1));
       std::list <int>:: iterator iter = result. begin();
       for(int i = 1; iter != result .end(); ++ iter , ++i )
      {
             lua_pushinteger(L , *iter);
             lua_rawseti(L , -2 , i);
      }
       lua_pop(L , 1);
}

需要注意的是，如果是多个参数，Lua的压栈顺序是object pointer、参数从左到右，所以栈顶元素是函数签名最右边的参数。

         核心数据结构我采用链表数组，将相同颜色且邻接的泡泡串成一个链表。采用这种数据结构，是基于下面考虑：1）通过颜色划分缩小搜索区域；2）没有排序，没有中间插入节点的需求；3）节省内存。当然，游戏界面中的泡泡还是把它对应到一个二维数组中，每个元素存储一个泡泡对象的指针，该对象中至少包含：颜色、坐标，分值。如下图所示：

         剩下需要考虑的是发射泡泡颜色如何产生？如果从空关卡开始，前面可以用随机，后面就要使用统计信息了。在每个链表头可以统计该堆泡泡开闭性、数量等，利用这些信息可以决定发射泡泡的颜色。

1. 建立源代码索引

     WinDbg提供了一套用于管理pdb对应的源代码的工具，位于其安装目录的srcsrv下，对VSS、SVN、CVS、Perforce提供了支持，分别对应vssindex.cmd、svnindex.cmd、cvsindex.cmd、p4index.cmd这四个perl脚本。其实，ssindex.cmd才是具体实现，它根据传入的版本控制系统标识，调用对应的perl module。

     svnindex.cmd通过/source和/symbols参数来指定源代码目录和PDB目录，/debug可输出处理的详细信息，/user和/pass提供svn账户和密码。PDB文件中有一节专门用于存放源代码文件列表及处理命令，可通过pdbstr -r -p:PdbFileName -s:srcsrv查看。

     svnindex.cmd /debug /source="E:\CodeBase_SVN\Client\trunk\tools\CutSceneEditor" /symbols="E:\CodeBase_SVN\Client\trunk\bin\Release\CutSceneEditor" /user="user" /pass="pwd"

     在执行上面命令前，确保Perl和Subversion已经被安装且设置了PATH环境变量。该命令将提取source code的服务器路径和当前Revision，然后写入PDB。下面是通过pdbstr获取的信息：

     上面输出是经过格式化的，原始信息可以通过srctool -n查看：

     可以看出，原始代码路径后面跟了一条svn cat指令，由于没有指定sourcepath，所以%targ%缺省为当前路径（"C:\Program Files\Debugging Tools for Windows (x64)\srcsrv"）。 

2. 创建符号服务器

    所谓符号服务器，最简单的形式就是文件共享服务器。我们使用symstore命令，将1中产生的pdb添加到一个文件共享服务器上，如：

     symstore.exe add /f "E:\CodeBase_SVN\Client\trunk\bin\Release\CutSceneEditor\*.pdb" /s "\\server.com\pub\Symbols" /t "CutSceneEditor" /v "Build 4171" /c "fix memory leak"

     该命令会根据PDB的signature和age产生一个GUID，并将PDB放置于以改GUID为名字的目录下：

    当debug时，将UNC路径添加到_NT_SYMBOL_PATH中（如：_NT_SYMBOL_PATH=CACHE*F:\Symbols;SRV*http://msdl.microsoft.com/download/symbols;SRV*\\server.com\pub\Symbols），调试器会自动到指定的符号服务器上去搜索对应的pdb文件。

     symstore大大简化了符号的版本管理问题，关于它的详细介绍可参考symstore介绍。

     值得注意的是，symstore没有锁机制，并不支持多人同时操作。实际情况中，也只有自动构建时才会做此操作。

3. 使用WinDbg分析Dump文件

      我们在代码中加入发生异常写MiniDump的功能，在程序崩溃时产生dump文件。在使用WinDbg分析dump文件时，需要设置Symbol File Path和Source File Path，也可以直接设置环境变量_NT_SYMBOL_PATH和_NT_SOURCE_PATH。在设置_NT_SOURCE_PATH时使用"SRV*CachePath"将表示启用代码提取功能，执行svn cat写入到CachePath指定的目录，否则将使用原始路径。此后，通过点击Call Stack中的函数调用便会触发从svn读取对应代码的操作（通常会有一个安全警告窗口弹出）。

     对于使用WinDbg进行调试在此就不多讲了，推荐一本不错的书《Advanced Windows Debugging》。

参考资料

[1] Source Indexing and Symbol Servers: A Guide to Easier Debugging

[2] Source Server Helps You Kill Bugs Dead In Visual Studio 2005

一、A* Path-Finding

     A*算法就不多讲了，可参考：

• http://theory.stanford.edu/~amitp/GameProgramming/
• http://www.policyalmanac.org/games/aStarTutorial.htm

二、预处理

     每个相邻区块（C1和C2）都有一条由公共边，该边两侧小格组成L1和L2，则连通点集E满足下列条件：

• E ⊂ L1 ∪ L2
• ∀t ∈ L1 ∪ L2 : t ∈ E ⇔ symm(t) ∈ E ，其中symm(t)为对称关系
• E不含不可行走格子

    对上面得到的位于同一区块的点集合使用local A*做连通性测试，下图用直线连接来表示两点互通：

三、寻路

     使用区块连通信息，进行区块级A*，得到区块之间的连接点，如果在预处理时保存了区块内互通点的路径，就不必再进行区块内的local A*了。

     实验结果表明，在未采用区块内预存路径的情况下，中长距离寻路使用层次A*后的平均效率是普通A*的5倍以上，距离越长效率对比越明显。

     A* 93ms

HPA* 15ms

     从上图中可以看出，HPA*得到的路径并不是最优的，它是在最优和效率上的折中，适合作为长距离寻路的一种优化方案。

四、优化点

• 可扩展为多层而不仅限于一层
• 预存区块内连通点路径
• 区块边界可通面积较大时，产生不自然路径，如下图所示：

          一个改进的方法是对过长的边界再做划分：

void D3DXQuaternionSquadSetup(
  __out  D3DXQUATERNION *pAOut,
  __out  D3DXQUATERNION *pBOut,
  __out  D3DXQUATERNION *pCOut,
  __in   const D3DXQUATERNION *pQ0,
  __in   const D3DXQUATERNION *pQ1,
  __in   const D3DXQUATERNION *pQ2,
  __in   const D3DXQUATERNION *pQ3
);

D3DXQUATERNION* D3DXQuaternionSquad(
  __inout  D3DXQUATERNION *pOut,
  __in     const D3DXQUATERNION *pQ1,
  __in     const D3DXQUATERNION *pA,
  __in     const D3DXQUATERNION *pB,
  __in     const D3DXQUATERNION *pC,
  __in     FLOAT t
);

其中，D3DXQuaternionSquadSetup用于返回内插的控制点。它们具体的实现公式和用法，有兴趣的同学可以参考MSDN。在此需要说明的是，

D3DXQuaternionSquad使用了Slerp作为内部实现，会导致在两个夹角为180°左右的Quaternion之间插值会出现断裂的问题。下面代码通过

实现一个考虑了上述情况的Slerp版本，在q1和q2夹角在0°或者180°时，使用线性内插而非球面，来解决该问题。

参考：

[1] http://msdn.microsoft.com/en-us/library/bb205419(v=vs.85).aspx

[2] http://msdn.microsoft.com/en-us/library/bb205420(v=vs.85).aspx

     前段时间遇到过这样的问题：已知一2D地图格子的长宽（w、h）及每个格子的边长（a，格子为正方形），给定物体的2D坐标（pos[x , y]）及半径（r），求解物体在2D地图格子中所占的格子，仅考虑n*n的情况。大概的求解过程如下：

1）根据半径，确定n*n中的n。假定计算公式为：n = Round(2*r / a)

2）根据2D坐标得到物体的“中心格子”。根据n的奇偶，计算公式不同，如下图所示。

n为偶数[1]                                                                    n为奇数[2]

[1]：grid(x , y) = Round(pos / a)

[2]：grid(x , y) = Floor(pos / a)

其中，格子坐标x >= 0 , y >= 0。

3）以“中心格子”为基础，求出物体占据的其他格子。这样的描述，让人容易想到递归，就像用深度优先方法遍历树那样，伪代码算法如下：

if n is even
{
    get the index of 'center grid' (row , col)
    ExtendHeldGrid(row , col , n)
    ExtendHeldGrid(row - 1 , col , n)
    ExtendHeldGrid(row - 1 , col - 1 , n)
    ExtendHeldGrid(row , col - 1 , n)
}
else
{
    get the index of 'center grid' (row , col)
    ExtendHeldGrid(row , col , n)
}

function ExtendHeldGrid(row , col , level)
{
    if(level <= 0)
        return

    if((row >= 0 and row < MaxGridWidth) and (col >= 0 and col < MaxGridHeight))
    {
        mark the grid(row , col)
        ExtendHeldGrid(row , col , level - 2)
        if(level - 2 > 0)
        {
            ExtendHeldGrid(row + 1 , col , level - 2)
            ExtendHeldGrid(row - 1 , col , level - 2)
            ExtendHeldGrid(row , col + 1 , level - 2)
            ExtendHeldGrid(row , col - 1 , level - 2)
            ExtendHeldGrid(row + 1 , col + 1 , level - 2)
            ExtendHeldGrid(row - 1 , col + 1 , level - 2)
            ExtendHeldGrid(row + 1 , col - 1 , level - 2)
            ExtendHeldGrid(row - 1 , col - 1 , level - 2)
        }
    }
}

虽然，该算法得到了正确的求解结果，但是由于每个格子都会标记周围的8个格子，所以存在大量的重复，再者如果上面的过程每帧都进行的话，函数调用开销也是相当可观。

循环自然是不可避免的，消除重复便成了优化的目标。分析格子图和n为2和3的情况，试图找出用循环代替递归的方法，我发现了下面一个有趣的规律：

从“中心格子”出发，顺时针（或逆时针）以上图方式可以走遍所求解的每个格子而不重复。在实现上，每个转角也是有规律的，可以通过一个2*2的转角矩阵来控制：

[1 , 0][0 , -1]

[0 , 1][-1 , 0]

顺时针方式的转角阵

矩阵中的每个元素代表从当前格子走到下个格子在row和col上的变化。加之，在转角之间的路长（以格子个数计）有每转两次递增单位1的规律，算法就不难得到了，下面同样以伪代码示：

conerMat = 
{
    {0 , -1} , 
    {-1 , 0} ,
    {0  , 1} ,
    {1  , 0}
}

dir = 0     /// 转角控制，四个转角顺时针0~3
span = 1    /// 转角间的跨度
count = 1   /// 每两次增加一个跨度
rin = 1     /// 下一个转角的循环索引

if n is even
    get the index of 'center grid' (row , col)
else
    get the index of 'center grid' (row , col)

for(i = 0; i < n * n; ++i)
{
    if((row >= 0 and row < MaxGridWidth) and (col >= 0 and col < MaxGridHeight))
        mark the grid(row , col)

    if(i == rin)
    {
        dir = (dir + 1) % 4

        if(count == 2)
        {
            ++span
            count = 1
        }
        else
            ++count

        rin = i + span
    }

    row = row + conerMat[dir][0]
    col = col + conerMat[dir][1]
}

用MFC程序验证了一下算法的正确性，标号展示了循环的路线（注意GDI的坐标系中Y的正方向朝下）：

一、系统调用

    通过使用WinExec、ShellExecute或system，如：

_snprintf(cmdbuf , 1024 , "p4 -c %s add \"%s\"" , argv[1] , ANSIToUTF8(path.c_str()));
system(cmdbuf);

    此方法的虽然简单，但存在效率问题，因为有创建进程的巨大开销。此外不同版本的Perforce也会出现不同的执行结果，针对特定的中文会出现操作失败的诡异问题。

二、Perforce SDK

    Perforce提供有SDK用以扩展或集成到其他应用中，虽然没有详细的文档，但可以通过学习SDK中的sample文件来学习，此方法最稳定。

    下面代码展示了通过SDK中ClientAPI来递归添加指定文件夹下的所有文件：

# include "clientapi.h"
# include "i18napi.h"
# include "CharSetConvertUtil.h"
# include <string>
# include <vector>
# include <list>
# include <io.h>

using namespace std;

// structure to hold a directory and all its filenames.
struct FILELIST
{
    string path;
    vector<string> theList;
};


void TransverseDirectory(string path, list<FILELIST>& theList)
{
    struct _finddatai64_t data;
    string fname = path + "\\*.*";
    long h = _findfirsti64(fname.c_str(),&data);
    if(h >= 0)
    {
        FILELIST thisList;
        theList.push_back(thisList);
        list<FILELIST>::iterator it = theList.end();
        it--;

        (*it).path = path;
        do {
            if( (data.attrib & _A_SUBDIR) )
            {
                // make sure we skip "." and "..".  Have to use strcmp here because
                // some file names can start with a dot, so just testing for the
                // first dot is not suffient.
                if( strcmp(data.name,".") != 0 &&strcmp(data.name,"..") != 0)
                {
                    // We found a sub-directory, so get the files in it too
                    fname = path + "\\" + data.name;
                    // recurrsion here!
                    TransverseDirectory(fname,theList);
                }

            }
            else
            {
                // this is just a normal filename.  So just add it to our vector
                (*it).theList.push_back(data.name);

            }
        }while( _findnexti64(h,&data) == 0);
        _findclose(h);

    }
}

int main( int argc, char **argv )
{
    list<FILELIST> MyList;
    string path;
    ClientUser ui;
    ClientApi client;
    StrBuf msg;
    Error e;

    if(argc < 4)
    {
        fprintf( stderr , "P4 Transverse Add: Arguments Error!\n");
        return -1;
    }

    client.SetPort(argv[1]);
    client.SetClient(argv[2]);
    client.SetTrans(CharSetApi::UTF_8 , CharSetApi::UTF_8 , 
        CharSetApi::UTF_8,
        CharSetApi::UTF_8);

    TransverseDirectory(argv[3],MyList);

    // Connect to server
    client.Init( &e );

    if( e.Test() )
    {
        e.Fmt( &msg );
        fprintf( stderr, "%s\n", msg.Text() );
        return -1;
    }

    list<FILELIST>::iterator it;
    for(it = MyList.begin(); it != MyList.end(); it++)
    {
        vector<string>::iterator its;
        for(its = (*it).theList.begin(); its != (*it).theList.end(); its++)
        {
            path = (*it).path + "\\" + (*its);
            char* pText = ANSIToUTF8(path.c_str());
            client.SetArgv( 1 , &pText);
            client.Run( "add" , &ui );
        }
    }

    // Close connection
    client.Final( &e );

    if( e.Test() )
    {
        e.Fmt( &msg );
        fprintf( stderr, "%s\n", msg.Text() );
        return -1;
    }
    
    return 0;
}

    此方法省去了创建p4进程的开销，任务执行效率会提高不少，而且也不会出现执行结果不稳定的问题。   

附一：SDK下载地址

ftp://ftp.perforce.com/perforce/

附二：附上ANSI转UTF-8代码

wchar_t* ANSIToUnicode( const char* str )
{
    int    textlen ;
    wchar_t * result;
    textlen = MultiByteToWideChar( CP_ACP, 0, str,-1,    NULL,0 );  
    result = (wchar_t *)malloc((textlen+1)*sizeof(wchar_t));  
    memset(result,0,(textlen+1)*sizeof(wchar_t));  
    MultiByteToWideChar(CP_ACP, 0,str,-1,(LPWSTR)result,textlen );  
    return    result;  
}

char* UnicodeToANSI( const wchar_t *str )
{
    char * result;
    int textlen;
    // wide char to multi char
    textlen = WideCharToMultiByte( CP_ACP,    0,    str,    -1,    NULL, 0, NULL, NULL );
    result =(char *)malloc((textlen+1)*sizeof(char));
    memset( result, 0, sizeof(char) * ( textlen + 1 ) );
    WideCharToMultiByte( CP_ACP, 0, str, -1, result, textlen, NULL, NULL );
    return result;
}

wchar_t* UTF8ToUnicode( const char* str )
{
    int    textlen ;
    wchar_t * result;
    textlen = MultiByteToWideChar( CP_UTF8, 0, str,-1,    NULL,0 );  
    result = (wchar_t *)malloc((textlen+1)*sizeof(wchar_t));  
    memset(result,0,(textlen+1)*sizeof(wchar_t));  
    MultiByteToWideChar(CP_UTF8, 0,str,-1,(LPWSTR)result,textlen );  
    return    result;  
}

char* UnicodeToUTF8( const wchar_t *str )
{
    char * result;
    int textlen;
    // wide char to multi char
    textlen = WideCharToMultiByte( CP_UTF8,    0,    str,    -1,    NULL, 0, NULL, NULL );
    result =(char *)malloc((textlen+1)*sizeof(char));
    memset(result, 0, sizeof(char) * ( textlen + 1 ) );
    WideCharToMultiByte( CP_UTF8, 0, str, -1, result, textlen, NULL, NULL );
    return result;
}

char* ANSIToUTF8(const char* str)
{
    wchar_t* pUnicodeBuff = ANSIToUnicode(str);
    char* pUtf8Buff = UnicodeToUTF8(pUnicodeBuff);
    free(pUnicodeBuff);

    return pUtf8Buff;
}

1）灵活、高可配置性，如：多重组合条件触发、多任务队列策略；

2）兼容目前几乎所有的流行SCM工具，使得多种异构系统能够由CruiseControl.NET统一监控和管理；

3）完善的使用文档，使上手和维护变得容易；

    而该项目引以自豪的代码check in触发构建的功能通过CC.NET也很容易实现。之前使用过Hudson，该系统采用主从式架构，使用者通过网页让Master控制Slave动作，由于Master由别的部门管理，出问题后需要联系相关人解决，会有一定的处理延迟，而且安装在构建机上的Slave服务经常崩溃。而CC.NET直接安装在构建机上，配置IIS后可通过网页直接访问，操作维护都较前者容易。由于之前的构建脚本是用VisualBuild实现的，所以不可能再花时间用CC.NET再写一遍。而通过实验得知，其实CC.NET能够以ExecutableTask的形式很好地与VisualBuild集成，目前每小时定时构建、NightBuild和构建成功后触发的自动测试都已经放到了CC.NET上了。

    ccnet.config Example:

<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
  <queue name="Q1" duplicates="ApplyForceBuildsReAdd" />
  <queue name="Q2" duplicates="ApplyForceBuildsReAdd" />
  <project name="AgileBuild" queue="Q1" queuePriority="1">
    <category>AutoBuild</category>
    <triggers>
      <filterTrigger startTime="18:00" endTime="10:00">
        <trigger type="intervalTrigger" name="Continuous" seconds="1800" buildCondition="ForceBuild" />
        <weekDays>
          <weekDay>Monday</weekDay>
          <weekDay>Tuesday</weekDay>
          <weekDay>Wednesday</weekDay>
          <weekDay>Thursday</weekDay>
          <weekDay>Friday</weekDay>
        </weekDays>
      </filterTrigger>
    </triggers>
    <tasks>
      <exec>
        <executable>VisBuildCmd.exe</executable>
        <buildArgs>E:\GAMEDev\AgileBuilder.bld</buildArgs>
        <baseDirectory>D:\VisBuildPro7</baseDirectory>
        <buildTimeoutSeconds>3000</buildTimeoutSeconds>
      </exec>
    </tasks>
  </project>
  <project name="NightBuild" queue="Q2" queuePriority="1">
    <category>AutoBuild</category>
    <triggers>
      <scheduleTrigger time="23:00" buildCondition="ForceBuild" name="Scheduled">
        <weekDays>
          <weekDay>Monday</weekDay>
          <weekDay>Tuesday</weekDay>
          <weekDay>Wednesday</weekDay>
          <weekDay>Thursday</weekDay>
          <weekDay>Friday</weekDay>
        </weekDays>
      </scheduleTrigger>      
    </triggers>  
    <tasks>
      <exec>
        <executable>VisBuildCmd.exe</executable>
        <buildArgs>"BUILD_OPTION=clientworldeffect" "PACK_TYPE=RAR" E:\GAMEDev\NightBuilder.bld</buildArgs>
        <baseDirectory>D:\VisBuildPro7</baseDirectory>
        <buildTimeoutSeconds>0</buildTimeoutSeconds>
      </exec>
    </tasks>
  </project>
  <project name="NightAutoTest" queue="Q2" queuePriority="2">
    <category>AutoTest</category>
    <triggers>
      <projectTrigger serverUri="tcp://heath-builder:21234/CruiseManager.rem" project="NightBuild">
        <triggerStatus>Success</triggerStatus>
        <innerTrigger type="intervalTrigger" seconds="60" buildCondition="ForceBuild" />
      </projectTrigger>
    </triggers>
    <tasks>
      <exec>
        <executable>VisBuildCmd.exe</executable>
        <buildArgs>E:\GAMEDev\AutoTest.bld</buildArgs>
        <baseDirectory>D:\VisBuildPro7</baseDirectory>
        <buildTimeoutSeconds>0</buildTimeoutSeconds>
      </exec>
    </tasks>
  </project>  
</cruisecontrol>

References

[1] http://cruisecontrol.sourceforge.net/

[2] http://www.kinook.com/VisBuildPro/

Jason Gregory在他的引擎架构设计一书中也用“To SLERP or Not to SLERP (That’s Still the Question)”一小节介绍了开发者对Slerp的争论，并介绍他在Naughty Dog的同事针对PS3的优化方法，使Slerp可达到20周期/关节，相比Lerp的16.25周期/关节已经很不错了。

之前确实没对Slerp的效率问题作过多的考虑，引擎的Slerp直接使用的是D3DXQuaternionSlerp，MS应该对其做了优化，效率怎么样要测一下才知道了。