通过阅读ConsoleWindow代码，想到了一个解决思路：自己实现OnOpenAsset，通过获取ConsoleWindow中的ListView得到当前选中的row，然后在LogEntries中取得该行对应的LogEntry，其中的condition字段保存了StackTrace字符串，最后过滤掉包装的日志类后拿到脚本文件名和代码行，用OpenFileAtLineExternal直接打开。在实现过程中发现，完全没有必要拿到LogEntry，因为ConsoleWindow中的m_ActiveText就是StackTrace字符串，直接处理就好了。

在想到该方案之前，看过两个解决方法：1）将日志类编译成DLL；2）输出日志时自己记录StackFrame，通过一系列手段在OnOpenAsset查找LogEntry中对应的StackFrame。不过这两种方案都不能满足个人的完美主义情节，方案1失去了预编译宏的灵活，一旦日志系统改动需要重编DLL和处理依赖，方案2低效且过于复杂。

最后摘出代码供参考，实现环境为：Unity 4.7.5f1, UnityVS+Visual Studio 2015 Pro。

从A*到Navmesh都是完备的寻路方案，能满足任意距离的路径搜索。它们都需要根据场景预先生成相关数据（A*是规整的2D格子数据，Navmesh则是mesh数据），在场景尺寸确定的情况下，Navmesh算法的网格数会随障碍的复杂程度改变，而A*是固定的。就时空复杂度而言，通常情况下Navmesh要优于A*，但一些优化的变种A*算法（如：Hierarchy A*）在长距离寻路上要优于Navmesh。然而对于动态改变的场景障碍，在使用以上两种算法时都会有性能和设计上的限制。在实际项目中，我们通常将战斗约束在一定区域内，而且这些区域有可能是诸如移动平台之类的，此时A*和Navmesh可能会面临无法使用的境地。下面这个方案是在洗澡时突然想到的，确切点应该称之为避障算法，因为它源自之前做智能避障小车时的经验。

设，角色到目标点的方向向量为D₀，投射线长度为L，探测间隙角为θ，N = 180 / θ，算法流程如下：

算法通过优先搜索目标方向左右无障碍空间，减少检测次数，通过设置θ和L可以控制检测精度和范围。此外，设置合适的Collision Matrix和检测频率可以约束RayCast的性能开销。

团队在使用UGUI时，发现其Outline实现是将文字的顶点在上下左右方向上做偏移生成了新的顶点，所以顶点和三角面数量都增加了4倍。受Glow中Gaussian Filter可实现边界外扩效果的启发，做了个实验，在第一个pass中使用Filter对Font Texture的Alpha进行4或者8方向采样，第二个pass正常渲染字体，然后将两者进行Alpha blend。

No Outline

Tow-Pass Outline with Four-Direction Sampling

Outline in UGUI

从结果上来看，在一定范围的纹理坐标偏移下可以接受，但限制也很明显，下图是偏移过大导致失真

     不管使用那种方式，都需要将离散点进行插值（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、参数从左到右，所以栈顶元素是函数签名最右边的参数。

一、扩展Lua

        Lua核心很小，主要包含一个解释器，其他功能可以通过动态库的形式作为插件来扩展，io、string、math、table等内置库都是通过此方式来实现，只是他们被集成到了一个lua.dll中罢了。制作一个动态库形式的module，需要在代码中通过luaL_Reg数组指定lua function到c function的映射，接着实现c function，最后在luaopen_xxx(xxx为module name)注册这个luaL_Reg。这里给出一个非常简单的例子，它使用VC++创建一个Console DLL：

#include "lua.h"
#include "lualib.h"
#include "lauxlib.h"
#include <math.h>

int mysin (lua_State* L);

static const struct luaL_Reg mymathlib [] =
{
    { "sin" , mysin } ,
    { NULL , NULL }
};

static int mysin( lua_State* L )
{
    double d = luaL_checknumber( L , 1);
    lua_pushnumber(L , sin( d));
    return 1;
}

__declspec(dllexport) int luaopen_mymathlib(lua_State * L)
{
    luaL_register(L , "mymathlib" , mymathlib);
    return 1;
}

编译成dll后放到lua解释器目录下。Lua test code：

require "mymathlib"

local a = mymathlib.sin(0.5)
print(a)

二、作为脚本系统

        Lua应用最多的领域当属游戏开发，WOW的UI和插件让它名声大噪。在这种应用中，Lua作为应用程序的一个子系统，用作配置或者业务处理。在将Lua与应用集成起来时，必须用到Lua C API，根据其规范，你需要写一系列的static函数，作为Lua与应用程序的粘合代码。如果要在Lua使用C++对象，可将其作为userdata，为它创建一个metatable，并将粘合函数放入其中，关键是要让__index指向metatable自身，这样当Lua访问userdata的field时，__index会引导它去搜索metatable自身，从而获得注册的粘合函数。

        有很多开源的粘合代码生成器，他们都是在precompile时做了一些工作，因而不是使用macro就是template，这两种方法的代表是toLua++和luaBind。个人更倾向使用toLua++，一方面这种方式比较直白，另一方面本人弱于使用template。在WGAME中也将原来写得不是很好的bind代码替换成了toLua++，目前UI和关卡逻辑重度使用了Lua，产生的bind代码会有几万行，由于项目采用事件驱动的方式，在profile时看到对游戏整体性能影响非常小。luaBind大概了解过，没有在实际项目中用过，在此就不做评论了。

        在使用toLua++时我最好奇的是它对C++关键特性是如何支持的。除了上面说的成员函数外，对于多态的支持，它是通过在static函数后加编号，调用时判断参数是否对应来遍历找到正确static函数的；对于复杂成员变量，它会自动生成get/set方法；而继承关系，则是通过子类将父类作为metatable来实现。秉着重新发明车轮的精神，我试着写了一个简化的自动生成器[我在github上]。我定义了几个关键字作为类与方法的导出标识：

    {module_begin = "LUACBIND_MODULE_BEGIN" , module_end = "LUACBIND_MODULE_END" , method_begin = "LUACBIND_METHOD_BEGIN" , method_end = "LUACBIND_METHOD_END"}

    util.h定义了产生bind代码需要的宏，parser.lua对指定的.h文件进行扫描产生bind代码，在main函数中register后，就可以在lua中使用了。

三、调试器

        Lua的C API和Debug库提供了实现调试器的必要方法，对应了两种实现方式：一种是Remdebug所采用的，直接用lua实现；另外一种是使用C API。不管哪种方式，使用HOOK都是必须的，但使用Lua debug库会比C API更方便，因为不用考虑栈平衡问题。在用C API实现调试器时，可用lua_newthread创建一个coroutine，之后yield/resume/getstack/getlocal都作用它上面，breakpoint通常会采用在hook中yield的方式来实现，但不能等hook返回之后去进行栈回溯，因为traceexec根据hook mask调用对应hook函数后，如果state是为LUA_YIELD状态，将会调用luaD_throw，最终使用longjmp导致无法进行回溯。

        利用春节值班两天清闲时光，基于lua 5.2实现了一个命令行调试器[我在github上]，目前仅有几个简单的功能：加载/运行lua脚本、设置/清除断点、单步、查看简单类型变量值，命令格式可参考README。

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

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

准备:

1）USB DOS启动盘；

2）HDDHackr 1.3和360 320 GB固件；

3）一台支持SATA接口的电脑。（我有一台SATAIII接口的PC和一台支持SATAII的ThinkPad X200笔记本）

        在PC上运行失败了,出现不能写入的问题，在X200笔记本上成功了。在此过程中,只需要选择写入固件,程序会帮你自动备份原固件。需要妥善保管原固件，以便后面需要用做数据硬盘的时候可以恢复。

        然后进入BIOS，将SATA模式从AHCI改为Enhanced IDE（在我的电脑上也不能用Compatible IDE，不然会出现可以识别不能读取的问题）。至于XBOX何时启动的问题，我给出的结论是无所谓，如果XBOX后启动，则需要进设备管理器扫瞄一下新设备。在整个操作过程中，虽然在设备管理器中看不到光驱，但是进入JF的DVDKey 32页签是可以看到的（注意选择I/O Port）。如果是第一次提取光驱的KEY，DVD KEY一项会显示not found，这是正常的，因为程序找不到与已知KEY匹配的。最后点击SlimKey，过程中不要unlock。

        接下来就是去网上淘9504，将0225上提取的KEY合入其中。

        被骗了，拿到的还是0225，值得庆幸的是光驱是02年4月份的MXIC版，具体用什么方法破解的，我也难的去拆开细究。问了LT刷的是哪个版本，回答是3.0。在网上又买了两张LT3.0和一张不分版本的（应该就是低于AP2.5的吧）。结果是3.0可以安装，运行提示＂此光盘不支援＂，另外一张不分2.0还是3.0的可以运行，于是开始怀疑光驱刷的是2.0。为了验证自己的怀疑，决定自己动手刷LT plus 3.0，另一方面也验证一下破解是否完美（不用拆板焊线就可以反复刷），结果将决定是否退掉光驱。

        在Win7下试了N次，SATA1,6都试了，就是写入不了（status 0x051），但是可以识别和读KEY。没办法，改变策略：1)先用JF拿前面提取的KEY和LT+3.0合成固件；2)用U盘启动，到纯DOS下使用dosflash来写入固件。这个方案很奏效，成功写入固件，到win7下用JF查看光驱KEY的状态是verified。启动360，买的LT3.0碟子都能玩了。

        网上的资料繁杂而难以辨别真伪，所以凡事都要自己实践。补充一下：

1）dashboard版本与刷光驱固件有没有关系？没有。光驱的电源接口提供三种电压(3.3、5.0、12）、出舱控制、托盘状态外其余都是地线，所以刷机时的数据通讯只会通过SATA线传输，因此360无法干预刷机过程。我用u盘离线从13599更新到了最新的15574，能玩「黑色行动2」、「极品17」、「忍龙3」。

2）验证光盘是否是LT3.0：用abgx加载光盘信息，如果出现Topology data is currently verified就说明是LT3.0（注意对于超刻的碟，普通光驱无法识别，或者读取出错）。

3）dosflash使用注意事项：将SATA线接在第一个口上。进入dos后先别启动360，运行dosflash一次，确保所有sata接口没有错误提示。然后执行dosflash，正常情况下应该没有错误提示，最后选w直接选合好的固件写入。

     测试代码需要做一些调整，才能更好地体现出GPU的平行计算优势，这其中牵涉到支持CUDA的GPU架构知识，在这里做一下梳理。

     在Nvidia推出Fermi架构之前，支持CUDA的Nvidia显示芯片都是由多个Streaming Multiprocessor（简称SM）组成，每个SM包含了八个Stream Processor（简称SP），每四个SP组成一个组，也就是说SM实际上可以看成包含两组4D的SIMD处理器。此外，每个SM还包含Register、share memory、texture cache以及constant cache。在执行 CUDA 程序的时候，每个SM对应一个 block，而每个SP就是对应一个 thread。虽然一个SM只有八个SP，但是由于SP进行各种运算都有延迟，更不用提内存存取的延迟了，因此 CUDA 在执行程序的时候，实际是以 warp 为单位。目前的支持CUDA显卡，一个 warp 里面有32个 threads，分成两组16 threads的half-warp。由于SP的运算至少有4个时钟周期的延迟，因此对一个4D的SP来说，一次至少执行16个 threads(即 half-warp)才能有效覆盖掉各种运算的延迟[1]。

图 1

     在GeForce GTX 400系列上，Nvidia采用了全新的Fermi架构[2]，之后的显卡的Compute Capability也从1.3跃升至2.0。SP改名为CUDA Core，提升到了32个/SM[3]。图2为Fermi核心演变，从GF104和由其发展起来的GF114、GF106、GF108的CUDA Core都上升到了48个/SM，支持2.1的Compute Capability，而GF100和GF110依旧是32个。最新基于Kepler架构的GeForce GTX 680支持3.0的Compute Capability，CUDA Core数量达到了192个/SM。

图 2

     由于测试平台采用的是GTX 560 Ti，所以需要分析一下它的架构。GTX 560 Ti由8个SM组成，下图中，左边是从程序获取的设备属性，右边为单个SM内部结构示例图。可以看到，GTX 560 Ti的每个SM配备了两个Warp调度器，因此每个周期对两个包含32个线程的Warp进行分发。另外，对于一个二维图像，为kernel指定2D的grid和block可使代码更加直观。为此，block采用（16,16），总共分配256个（64*4）threads在一个SM上执行，如果需要产生1024*1024的Julia分形图，则需要grid为（64,64）。

图 3

     测试平台为：

     测试代码说明：

     1）代码分为CPU实现和CUDA实现；

     2）均采用CPU计时方法；

     3）只针对计算部分测试，不包括内存分配、传输以及文件写入；

     下面列出main函数代码，左边为CPU实现，右边为CUDA实现，均编译为release版本。

     测试结论：CPU版本耗时244ms，CUDA版本耗时2.1087ms。这可是100倍的效率提升啊。不过CPU版本没有经过多核优化，所以这样这样对比实在不公平，但这却凸显出CUDA C将并行思想融入语言规则的优势。

     在惊讶GPU用作通用计算的执行效率时，别忘了它还是有诸多应用上的问题：

     1)初始化耗时，需要在显存分配空间，然后将数据从内存copy到显存；
     2)数据量受GPU显存限制；
     3)对本身就需要GPU参与运算的程序，如：3D游戏，通用计算会争夺GPU资源，如果做平衡？
     4)计算数据之间的不相关性限制了GPU通用计算的应用范围；

     5)CPU算法到适合GPU架构算法的移植；

     最后，GPU硬件设计本身就已经决定了它的强项是密集数据处理（如：科学计算、医疗图像处理），在逻辑处理方面还是CPU的天下，所以它们是互补的，只会有整合而非替代的趋势。

[1] http://www2.kimicat.com/gpu%E7%9A%84%E7%A1%AC%E9%AB%94%E6%9E%B6%E6%A7%8B

[2] http://www.chip.cn/index.php?option=com_content&view=article&id=2857:geforce-gtx-400-gpu&catid=7:test-technology&Itemid=15

[3] http://www.geeks3d.com/20100606/gpu-computing-nvidia-cuda-compute-capability-comparative-table

[4] http://www.expreview.com/13590-2.html

[5] http://en.wikipedia.org/wiki/CUDA

        有时候，你会突然对某事很感兴趣，但理性思维会让你冷静一下，看是不是一时冲动。N年前，对摄影的需求仅满足于旅游记录，所以一般DC就足够。一个多月前，想要提升照片品质的需求突然串了出来，让这种想法发酵了几天后，发现可能是该入一台DSLR的时候了。在Nikon D7000/Pentax K-5/Canon 60D中选择了K5，就成像效果D7000与K5是同一档次，喜欢K5的手感和味道，小巧是个很重要的因素，这样同样喜欢摄影的Rain也可以用得很好。宾得的对焦系统和镜头群一向都被CN饭喷，不过个人认为K5的对焦在日常拍摄中已经够用，镜头少但全。对于刚使用DSLR不久的我来说，DA 18-55mm F/3.5-5.6 AL虽然在成像锐度方面弱了点，但日常的风景人像还是足够了。DA 55-300mm F/4-5.8 ED近端大光圈拍人像的虚化效果和远端打鸟的远摄效果都还比较满意，由于55-110光圈可以恒定在4，110-200最大光圈恒定在4.5，所以两者组合起来在性价比上要比DA 18-135mm F/3.5-5.6 ED高。凤凰50mm F/1.7手动头，在成像效果方面真心对得起315RMB，有兴趣的同学可以看这里。

        摄影技术的提高是个漫长的过程，对初级阶段需要掌握的知识，我总结如下：

        1）器材的熟悉到精通：阅读使用手册，熟知各个按钮及选项的意义。

        2）保证对焦点（想拍摄物）清晰。

        3）相机的基本原理：快门、光圈、感光度对影像的影响。

        4）构图：左右对称、三等分、曲线、对角线、T/L型、明暗对比…

        5）光线感知：如何才能做到合适的曝光。

        6）利用学到的新知识，不断练习，让相机成为你的另一只眼睛。

        在参考书方面，虽然反感“宝典”之流，但《数码单反摄影完全宝典》还算是本不错的入门书了，涵盖了DSLR的基础知识，加上配图（包括拍摄参数），可以提升对好照片的认知。

        写此文的同时，快门数也近3k了，遂将一些习作（没有后期）整理了放入flickr上，ID就萌一点吧『Pentax的小眼睛』。

        彼得森的《理解曝光》是我学习的第二本书，对掌握测光技巧从而正确曝光有很大帮助，距离所想即所得的目标有近了一步。此书还涉及了快门速度、光圈对拍摄效果产生的影响，应该是入门者必读的一本经典之作。

        国庆去了厦门，经过一个月的准备，拍出的片较之前有很大进步，感觉生活又多了些乐趣。

     从大学到现在配过两台PC，第一台Celeron的机器从大二用到研究生毕业，之后开始用笔记本。第二台PC是09年入手的，那阵子玩超频，但心浮气躁，胡乱尝试一下就浅尝辄止了，连一些基本原理都没有弄清楚。最近刚搞好新房安顿下来，有了自己的工作间，在重新组装PC和设置BIOS的时候又想超频了，但这次我期望做到知其所以然，故在网上查阅了一些资料恶补了一下硬件知识，权当作学习笔记。由于网络上关于硬件（特别是内存部分）知识很杂，仅以自己认为比较靠谱的内容为依据，如有不准确之处，欢迎指正。由于使用的是Intel CPU，本文限于Intel架构，且不适用I系列架构。

总线概览

二、术语

主板芯片组：北桥芯片和南桥芯片。

北桥（Northbridge）：PC主板芯片组其中之一，设计用来处理高速信号，与CPU、内存、AGP/PCIE、南桥芯片进行通信。

南桥（Southbridge）：PC主板芯片组其中之一，设计用来处理低俗信号，通过北桥和CPU通信，与大多数I/O控制设备接口，如PCI控制器、ATA控制器、USB控制器、网络控制器、音效控制器。各个芯片厂商对南桥芯片的命名有所不同，Intel将其称为ICH，nVidia称为MCP，ATI称为IXP/SB。

前端总线（FSB, Front Side Bus）：指CPU与北桥芯片之间的数据传输通道。

锁相环（PLL, Phase-Locked Loop）：一个闭环的反馈控制系统，它可以使PLL的输出可以与一个参考信号保持固定的相位关系。

时钟频率：确切点是晶振频率，与锁相环电路配合使用为PC提供定时信号，通过倍频/分频产生不同频率的基准信号，用以同步系统的每一步操作。对于CPU主频，它是由晶振提供的频率通过CPU内部的PLL电路倍频而来。

CPU外频：系统总线的工作频率，体现了CPU与芯片组之间的总线速度。

前端总线频率：CPU与北桥芯片之间的总线工作频率。之所以将CPU外频与前端总线频率区分开来，是因为Intel在Pentium 4中加入了Quad Pumped Bus架构，使得系统总线在一个时钟周期内传输4次数据，也就相当于工作频率为CPU外频的4倍。

CPU倍频：为倍频系数的简称，是指CPU主频与CPU外频之间的相对比例关系。在PC发展初期，由于CPU速度不高，大部分元件时钟均保持同步，直到80486时代，在CPU制程持续进步下，CPU的速度也加速增长，当时由于其他外部元件受电气结构所限，无法跟进成长，因此Intel首次在CPU中加入了倍频设计。它的作用是使系统总线工作在相对较低的频率上，而CPU速度可以通过倍频来提升。

双倍数据速率（DDR, Double Data Rate）：使SDRAM在一个时钟周期内进行两次数据传输的技术，具体地说它在信号的上升沿和下降沿传输数据一次，数据传输率是之前仅利用上升沿进行数据传输的SDRAM的两倍。

内存频率：分为核心频率(Internal rate)和I/O总线频率(Bus clock)。每条内存都是由内存芯片组成，内存芯片的频率就是核心频率。I/O总线频率是指北桥与内存之间的总线频率。通常内存条标称的实际上是最大数据传输频率：I/O总线频率X2。其实，从DDR到DDR3，其内存颗粒的频率没有怎么提升，提升的是总线频率。JEDEC制定的DDR三代参数对照如下表所示：

双通道：就是在北桥芯片里设计两个内存控制器，这两个内存控制器可相互独立工作，每个控制器控制一个内存通道。在这两个内存通道上CPU可分别寻址、读取数据，从而使内存的带宽增加一倍，数据存取速度也相应增加一倍（理论上）。流行的双通道内存构架是由两个64bit DDR内存控制器构筑而成的，其带宽可达128bit。因为双通道体系的两个内存控制器是独立的、具备互补性的智能内存控制器，因此二者能实现彼此间零等待时间，同时运作。两个内存控制器的这种互补“天性”可让有效等待时间缩减50%，从而使内存的带宽翻倍。双通道内存技术是解决CPU总线带宽与内存带宽的矛盾的低价、高性能的方案。

三、原理

CPU主频=外频×倍频

     从公式可以看出，要提升CPU主频可以从提高外频和倍频两方面着手。然而在实际操作过程中，两者都会受CPU本身及外部硬件（主要是主板）体质的限制，如：锁倍频、主板FSB Frequency上限。

1）提高外频

     因为CPU外频的设置直接影响系统总线工作频率，所以通过提升外频和搭配合适的内存，可以在主板支持的前端总线频率上限内有效提升系统的整体性能。之所以要搭配合适的内存，是因为前端总线频率提高，最大的受影响者就是内存，所以内存能够支持的最高工作频率也需要考虑。虽然GPU数据也要通过前端总线由CPU经过北桥到达显卡，但是在仅针对CPU超频的情况下，一般会将CPU与显卡之间通信的频率锁定在100MHz。举个例子：有一块前端总线上限频率为1600MHz的主板，假如搭配一块上限为1600MT/s的DDRIII内存，1:2分频比的前提下，需要将CPU的外频提升到接近400MHz，整个系统才会比较平衡。

2）提高倍频

     通过倍频的定义，可以看出，在外频一定的情况下，提高倍频，只能单纯地提高CPU工作频率。虽然，CPU的计算能力除了跟工作频率有关外，还与硬件架构和指令集有关，成倍提高工作频率肯定不等于成倍提高了计算能力，但可以肯定的是频率提高肯定会在一定程度上提高计算能力。

四、实作

    五电容版E5200具有很强的超频空间，在倍频定在X8的情况下，1.2V便可以轻松上370MHz。主板在不超频情况下FSB就已经支持1600MHz了，Corsair在使用XMP时支持1600，在整体考量（散热、CPU寿命）后决定将CPU外频定在350MHz、倍频设为x10，这样FSB可工作在1400MHz，内存按照 1:2分频比I/O总线工作在700MHz下（数据传输频率为1400MT/s）。BIOS设置如下：

内存CL、tRCD等值让其自动读取SPD配置。

参考：

[1] 前端总线 http://zh.wikipedia.org/wiki/%E5%89%8D%E7%AB%AF%E6%80%BB%E7%BA%BF

[2] 晶振及其选用指南 http://www.naiteli.com.cn/Info/Detail_50139_7547.html

[3] 倍频 http://baike.baidu.com/view/25647.htm

[4] DDR SDRAM http://en.wikipedia.org/wiki/DDR_SDRAM

[5] DDR2 SDRAM http://en.wikipedia.org/wiki/DDR2_SDRAM

[6] DDR3 SDRAM http://en.wikipedia.org/wiki/DDR3_SDRAM

[7] 五电容E5200 http://tech.163.com/digi/09/0316/08/54H0RJNT001618J7.html

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

          首先要介绍一下USB Host Shield[1]。它是Oleg从2009年春开始设计的Arduino Shield，采用MAX3421E控制芯片，目前最新版本为2.0，旨在让Arduino能够与USB设备（如，键盘、鼠标、游戏手柄、相机、GPS、手机）进行通讯，当然也能完成ADK的功能。在软件方面，Oleg也在github上开放了驱动代码和例子程序[2]，此后又有人基于前者的代码给出了更为方便简洁的USB蓝牙适配器与PS3手柄通讯的示例代码[3,4]。

           PS3手柄只能与具有相同蓝牙地址的主机配对，所以需要先将USB蓝牙适配器的地址写入PS3手柄。可以使用[3]中的PS3Pair代码，将BDADDR值修改为蓝牙适配器的地址。[4]中提供的PS3BT例子，将蓝牙地址修改和通讯功能整合到了一起，省了一次sketch的upload，注意也需要将代码中的my_bdaddr修改为适配器的地址。配对时需要将PS3手柄连接线与USB Host Shield相连，待完成后将蓝牙适配器接上，打开手柄，可从Serial Monitor看到日志（注意波特率的一致）。

        USB Host Shield占用了SPI、P9、P10，注意不要冲突了。

Reference:

[1] http://www.circuitsathome.com/arduino_usb_host_shield_projects

[2] https://github.com/felis/USB_Host_Shield_2.0

[3] https://github.com/Lauszus/PS3-Controller-BT-Library-for-Arduino

[4] https://github.com/TKJElectronics/USB_Host_Shield_2.0

    手上的ShenZhen Tong和HongKong Octopus均是SONY的Felica Card，与ISO/IEC 18092（NFC）使用类似的调制方法，采用曼切斯特编码，在13.56MHZ以212kbit/s进行通讯。使用动态密钥，加密算法为DES、3-DES、AES，攻击难度较大，但是从动态密钥的交换过程入手，还是有机会的。目前，有些手机制造商（NOKIA,SAMSUNG,BLACKBERRY）将NFC Reader集成到手机上，未来RFID的应用将比现在更广，安全问题也会越来越受到关注。

References:

http://rfidiot.org/

http://wiki.yobi.be/wiki/RFID

http://www.openpcd.org/

http://cq.cx/proxmark3.pl
http://www.proxmark.org/

http://www.libnfc.org/documentation/introduction

http://www.cs.ru.nl/~flaviog/publications/Pickpocketing.Mifare.pdf

http://www.sos.cs.ru.nl/applications/rfid/2008-esorics.pdf

rm /root/.kde/cache-root/plasma_theme_Volatile.kcache

rm /root/.kde/cache-bt/icon-cache.kcache

rm /root/.kde/cache-bt/plasma_theme_Volatile.kcache

一、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

    在_hash_fun.h中有针对各种类型的哈希值计算特化版本，下面仅摘录针对C字符串的代码：

    __stl_hash_string实现了一个简单的哈希算法，因为算法中使用了字符的ASCII码，为了达到大小写不敏感的目的，可将每个字符转换成小写/大写来计算。对于hash functor，我们也需要一个string的特化版。

    在_function_base.h中定义了equal_to functor：

    通过定制一个string版本的equal_to，使用stricmp进行字符串比较。下面列出实现及测试代码：

1、search时程序死掉

2、debug时锁住pdb不释放，下次build时出现文件写错误

    对于第一个问题，在devenv.exe属性的Compatibility的Settings中勾选“Disable visual themes”，或者停用Aero主题，使用Basic themes。

    对于第二个问题，可使用sysinternals工具handle来释放对pdb的引用，在此不列出handle的使用，有兴趣可以自己研究。下面给出一个批处理，关闭指定名称的pdb文件占用：

@echo off
cd /d "%~dp0"
for /f "tokens=2-3 skip=5 delims=:" %%a in ('handle -p devenv.exe "%1.pdb"') do (
  for /f "tokens=1,4" %%c in ("%%a%%b") do (
      handle.exe -c %%d -y -p %%c
  )
)
@echo on

    将其保存到一个文件，放在project的pre-build event。当然，还需要一个参数来喂批处理中的%1。

     前段时间遇到过这样的问题：已知一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的正方向朝下）：

    首先想到的是用TSVN的hook script(client side)，但仔细研究后发现传入script的参数仅有操作路径，且通过script也不可能访问/修改Notify对话框中的信息和字体颜色。唯一的办法就是修改源代码重新编译，从TSVN官方代码库获取到了trunk source code后，按照根路径下的build.txt文档进行构建（doc\build-zh_CN.txt有些过时了，不要按照该文档进行构建），最新代码需要用到VC++10.0编译，过程中除了hunspell下affixmgr.cxx、hashmgr.cxx和hunspell.cxx三个文件由于svn的编码转换导致文件内容异常外，没什么大问题。

    TSVN的代码写得很beautiful，这个要赞一下。在清晰的结构下很快对source code进行了分析，发现TSVN的操作处理代码位于src\TortoiseProc下面，而对各种操作的UI反馈主要放在SVNProgressDlg中。找到要修改的地方，添加了几行代码，用NAnt构建后，替换现装版中的对应文件，出现subversion too old问题，点开TortoiseProc.exe发现最新代码中的subversion版本已经用到了1.7.2，而TSVN对外发布的最新版却还是1.6.15，可能是开发者认为跨MinorVersion就算too old了吧。算了，不折腾了，直接拉发布版1.6.12的tag来修改吧。

    1.6.12版的source code用VC++9.0编译，按照build文档调整一下与前面构建有差异的地方，值得注意的是TSVN用到了Ribbon，所以必须先安装一下vs2008 sp1补丁。在构建TortoiseProc时，有个头文件中重复声明了MFC中已经定义了的类型，导致构建失败，需要将重复定义之处注释掉。TortoiseProc一出，我的目的就达到了，由于构建的版本与我安装的一致，所以只需替换TortoiseProc.exe，经测试一切OK。

    个人觉得，对TSVN的扩展还是麻烦了一点，整个构建过程花费了大量时间，建议增强hook script。

psfServiceMod Recovery Images

Commtivia Z71 - 0.3.1 » 3.7 MiB - 55 hits - December 21, 2010

HTC Aria - 0.3.1 » 3.8 MiB - 35 hits - December 21, 2010

HTC Desire (CDMA) - 0.3.1 » 3.4 MiB - 74 hits - December 21, 2010

HTC Desire (GSM) - 0.3.1 » 3.4 MiB - 381 hits - December 21, 2010

HTC Desire HD - 0.3.1 » 4.2 MiB - 166 hits - December 21, 2010

HTC Desire Z (G2) - 0.3.1 » 4.3 MiB - 55 hits - December 21, 2010

HTC Dream/Sapphire (32B) - 0.3.1 » 3.3 MiB - 156 hits - December 21, 2010

HTC Droid Eris - 0.3.1 » 3.4 MiB - 39 hits - December 21, 2010

HTC Droid Incredible - 0.3.2 » 3.6 MiB - 75 hits - December 21, 2010

HTC Evo 4G - 0.3.1 » 3.4 MiB - 109 hits - December 21, 2010

HTC Hero (CDMA) - 0.3.1 » 3.4 MiB - 75 hits - December 21, 2010

HTC Hero (GSM) - 0.3.1 » 3.4 MiB - 94 hits - December 21, 2010

HTC Magic/Sapphire (32A) - 0.3.1 » 3.4 MiB - 73 hits - December 21, 2010

HTC Tattoo - 0.3.1 » 3.2 MiB - 77 hits - December 21, 2010

HTC Wildfire - 0.3.1 » 3.6 MiB - 140 hits - December 21, 2010

Motorola Droid - 0.3.1 » 3.4 MiB - 132 hits - December 21, 2010

Nexus One - 0.3.1 » 3.4 MiB - 122 hits - December 21, 2010

T-Mobile myTouch 3G Slide - 0.3.1 » 3.8 MiB - 34 hits - December 21, 2010

T-Mobile myTouch 4G - 0.3.1 » 4.3 MiB - 30 hits - December 21, 2010

    笔者用的HTC Magic(32A)也在其中，于是用fastboot的USB方式（关机后按Power+Return进入后接上USB至PC，当然PC必须安装Driver）刷了Recovery。进入Recovery模式（关机后按Power+Home），断开USB连接，选择"PSFreedom settings"进入发现用于DG的"Put PS3 in Service Mode"、用于JB的"Jailbreak FW 3.41"、以及从SD卡加载Payload的功能项一应俱全。

    剩下的就和用Dog一样的操作方式来DG&JB了，值得注意的是操作时都需要接在右边USB口上（JB操作提示是接在左边）：

    1）关闭PS3并切断电源，选择"Put PS3 in Service Mode"进入；

    2）将手机连接至PS3右边USB口；

    3）打开PS3电源，按开机键后迅速按出仓键；

    4）手柄连接主机重新配对后，PS3进入Factory/Service Mode，关闭PS3；

    5）找一个U盘（只要是PS3识别的FAT/FAT32格式，未必需格式化）插上PC，解压3.41修改版固件，有三个文件夹：“Lv2diag.self FILE 1”，“Lv2diag.self FILE 2”和“Modified 3.41 PUP”。 将Lv2diag.self FILE 1中的Lv2diag.self以及Modified 3.41 PUP中的PS3UPDAT.PUP拷贝到U盘根目录；

    6）拔下U盘插入PS3右边的USB口，打开PS3，屏幕没有任何显示，PS3主机的硬盘灯和U盘的指示灯会闪烁，等待大约3分钟直到PS3电源绿灯闪烁并自动关机；

    7）拔下U盘，PS3正常开机，仍在服务模式，确认系统信息已经变成3.41。（如需继续降级到更低系统版本，勿删除U盘上的Lv2diag.self，将其它系统版本PS3UPDATE.PUP放入U盘，重新执行一遍步骤6）。若不需继续降级，关闭PS3电源；

    8）在PC上，删除U盘中的Lv2diag.self和PS3UPDAT.PUP两个文件，把Lv2diag.self FILE 2文件夹中的Lv2diag.self拷贝到U盘根目录。将U盘插上PS3并开机，仍然黑屏，等待10秒后会自动关机。再开机，会出现重新连接手柄、新建用户的初始开机画面，完成设置后进入系统信息查看，已是普通的3.41系统了，降级步骤全部完成。

    1）关闭PS3并切断电源，选择"Jailbreak FW 3.41"进入；

    2）将手机连接至PS3右边USB口；

    3）打开PS3电源，按开机键后迅速按出仓键；

    4）确认JB成功与否，查看Game下面是否多了两个新菜单项；

    5）之后就可以到PS3-Hacks去下载BackupManager/OpenManager了。

    其实JB就是让PS3进入Debug模式，一旦进入后便可移除JB设备。PS3刚JB那会儿，BackupManager是必备工具，后面出的Manager都是在其基础上增强，OpenManager比BackupManager多了从外接硬盘copy/play game的功能。此外Gaia manager也是个很受欢迎的Manager，除了在UI上比OpenManager好看之外，还加入了Direct Boot/FTP Server等功能，但Direct Boot并不是那么好使，比如《忍者龙剑传 Sigma2》用Gaia就花屏死机，用OM就不会，总体感觉还是OM更稳定。

Reference

[1] http://www.klutsh.com

[2] http://www.ps3-hacks.com/

[3] Simple Tutorial on How to Downgrade and Jailbreak your PS3 with PsfServiceMod

[4] http://ps3.cngba.com/ps3_xw/20101215119290.shtml

一、系统调用

    通过使用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;
}

    心理学为该影片了理论基础，盗梦的目的就是为了窥探目标埋藏在心里的秘密，因为梦是伪装得最少的潜意识表现。而作为进入目标梦境的工具，导演却是一笔带过，不得不说是一个遗憾，因而该影片也就成了一部纯科幻电影。

    观影毕，个人感觉Dream Design应该也和Game Design相似吧：故事、人物、时间、场景的设计。Programmer也深刻地温习了一下递归吧。

B.T.W. 多年以来，能够撼动我思想的影片仅有两部："The Matrix"和"Inception"。

1）Free 3G速度快，看新闻方便；

2）分辨率高，字体清晰；

2）Native PDF Support，翻页速度已经很快了，对于内嵌中文字体也有很好地支持。看PDF文档时，9.7寸屏比6寸屏更易于阅读。Zoom功能近乎鸡肋，因为很不喜欢拉着滚动条阅读，看扫描书的时候顶多用一下横屏。此外，由于Kindle会把颜色转换为灰度，所以对于非纯色的文字，会显得很淡。

3）由于Amazon将Mobipocket收归旗下的缘故，所以对mobi/prc文件格式的支持和azw格式一样好，提供指译、字体缩放、注释/笔记等功能；

4）通过Gift Card的方式购买电子书也挺方便，免去了买纸质书的运费和运输延迟。不过技术书的电子版本很少，且价格昂贵；

5）待机时间长，这是E-INK阅读器的一大优势；

6）加上原装皮套，重量和一本A4 600页左右的书差不多。

    对于电子书转换工具，个人推荐：Mobipocket和Calibre（仅Mac OS）。后者是开源的，功能和输出文件质量胜于前者。

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/

    Table实际上是数组和哈希表的混合体。当保存以连续整数为索引的内容时，使用数组结构；而对于离散索引及键值对，则使用哈希表存储。这样做对于空间节省和查找效率都是有好处的，举例：

tt = {"a" , "b" , "c"}
print(#tt)  --> 3
tt[100] = "d"
print(#tt)    --> 3 (100-"d"键值对放入哈希表)
tt[4] = "e"
print(#tt)    --> 4

二、Closure

    Lua的变量引用规则造成了闭包的出现，在Lua中一个复杂数据结构（table、function）被赋予一个变量时，变量仅仅拿取其引用。试考虑下面代码片段：

local f1 = function() ... end
local f2 = function() ... end
local f3 = f1

    判断f1与f2是否相等，得到的结果为假，而f3与f1则为真。这是因为f1与f2引用了两个不同的函数chunk（也可称为“定义”），而f1直接将其引用（可以看成C/C++中的地址）赋给f3，故而相等。
理解了上面问题，再看看下面的一个函数：

function createCounter()
    local x = 0
    return function()
        x = x + 1
        print(x)
    end
end

    那么，下面c1与c2相等吗？

c1 = createCounter()
c2 = createCounter()

    由于createCounter中的return部分创建了一个新函数，因此c1和c2引用的函数并不相同。因为return的匿名函数中使用到了外部函数(即createCounter)的局部变量x，所以Lua必须要在某个地方保存这个变量，又因为每次返回的都是一个新函数，所以Lua不能共享createCounter中的x，进而Lua必须为每个新函数分配一个保存x的地方，这个问题导致了闭包概念的产生。
    通过上面分析，可以明白是语言机制导致了闭包，而绝非Lua作者故意制造出这么一个看似有点神秘的东西。
    下面给出闭包的定义：一个保留了创建时上下文的函数。而upvalue的定义是：被闭包访问的保留变量。实际上所有在Lua中创建的函数都是闭包，在许多情况下仅有一个原型的闭包存在，因为函数块只执行了一次（也可以说定义了一次）。

    下面代码用闭包实现了一个对象工厂：

local function CounterFactory()
    local x = 0
    return 
    {
        Increase = function()
            x = x + 1
        end ,
        Decrease = function()
            x = x - 1
        end ,
        GetValue = function()
            return x
        end
    }
end

local c1 = CounterFactory()
local c2 = CounterFactory()

c1.Increase()
c1.Increase()
print(c1.GetValue())

三、Tail Call

     首先需要明确What is ‘Tail Call’?——其形式为“return f(…)”，return语句中的函数调用仅限于单一调用，涉及函数返回值运算的复合表达式不是尾调用，如：return i * f(i - 1)。由定义可以看出尾调用实际上是对位于返回语句中的函数调用的优化。通常调用一个函数都需要将其上下文入栈，然后再进入被调函数。在Lua中执行符合尾调用形式的函数时，因为该函数已经没有代码需要执行了，故作者作了不保存上下文的优化。这样带来的好处是：对于精心构建的递归调用，不需要有栈的消耗，因而绝对不会出现overflow，看看下面递归调用产生的死循环：

local function f(n)
    local i = n + 1
    print(i)
    return f(i)  -- tail call
end

f(0)

四、Metatable

    Metatable常用来扩展table的行为，通过setmetatable(table , metatable)将metatable挂接到table上，很多开发者用该特性来实现面向对象的设计。Metatable中提供了Metamethods，这些方法都以双下划线__开头，如：

        __add , __call , __concat , __div , __eq , __index...

    以上Metamethods中，__index被调用的条件是：key不在对应的table中。利用该特性可以实现类-对象、继承等面向对象概念，下面是个简单例子：

local Actor = {}
Actor.name  = "unnamed"
Actor.hp    = 100
Actor.dead  = false
Actor.level = 1
Actor.type  = "unknown"

function Actor:Say(text)
    print(self.name..":"..text)
end

function Actor:IsDead()
    return self.dead
end

local AttackableActor = setmetatable({ } , { __index = Actor })
AttackableActor.damage = 20

function AttackableActor:ReceiveHit(attacker)
    self:Say("I'm being attacked by "..attacker.name)
    self.hp = self.hp - attacker.damage
    if self.hp <= 0 then
        self:Say("I'm died :(")
        self.dead = true
    else
        self:Say("My HP is "..self.hp)
    end
end

function AttackableActor:Attack(target)
    if target.dead == true then
        self:Say("Oh, "..target.name.." has been dead!")
    else
        self:Say("I'm is attacking "..target.name)
        target:ReceiveHit(self)
    end
end

function CreateMonster(name , damage)
    local m = setmetatable({ } , { __index = AttackableActor})
    m.name = name
    m.damage = damage
    m.type = "monster"
    return m
end

function CreatePlayer(name , damage)
    local p = setmetatable({ } , { __index = AttackableActor})
    p.name = name
    p.damage = damage
    p.type = "player"
    return p
end

math.randomseed(os.time())

local boss = CreateMonster("Kerrigan" , math.floor(100 * math.random()))
local player = CreatePlayer("Raynor" , math.floor(100 * math.random()))

while player:IsDead() == false and boss:IsDead() == false do
    player:Attack(boss)
    boss:Attack(player)
end

五、Performance Tips

    请参考Lua Performance Tips

六、总结

    Lua是一门语法简洁，用法灵活的动态语言。在全面掌握之后，需悉心使用乃可构造出简洁高效的代码。

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应该对其做了优化，效率怎么样要测一下才知道了。