Dev in Nightmare

术语：Obfuscation

nightmare:qrli — Sun, 24 May 2009 07:42:00 +0800

在软件开发领域，Obfuscation指对代码做模糊处理，使其难于理解、难于反编译。
翻译：
A. 代码混淆
B. 模糊处理

相关的Obfuscator一词的翻译：
A. 混淆器
B. 模糊处理器

术语：纤程（fiber）不是轻量级线程

nightmare:qrli — Thu, 07 May 2009 00:12:00 +0800

根据Eric Eilebrecht的blog，纤程本质上并不减小内存开销，也不具有更好的性能。当我们需要使用非常多（比如100以上）的线程时，各线程的堆栈空间开销总和线性增长，线程切换的开销所占的时间比例也会过大，甚至会超过程序执行的开销。这时，我们会需要设计某种类似线程池的管理机制，使用少量的线程来分配执行众多的任务。纤程就是系统提供的一套这种机制的实现，省去我们自己设计制作的麻烦。

因此，每个纤程仍然有自己的堆栈，并不减少内存开销。但是，多个纤程可能会在同一个线程上执行，也就是说纤程没有自己的线程局部存储（thread local storage）和线程静态变量，任何依赖于它们的代码都不能正常地在纤程里执行。

所以，纤程只在一些极端情况下有用，如SQL Server，而对普通情况其代价通常远大于收益。

术语：游戏机制（Game Mechanics）

nightmare:qrli — Sun, 03 May 2009 01:58:00 +0800

游戏机制（Game Mechanics）是一个游戏中的构成这个游戏的所有规则，也就是游戏的虚拟世界的所有规则，包括物理的和非物理的。所有的游戏都有其游戏机制，但是原理、风格各不相同。一般来说，游戏设计的过程，就是在构造其游戏机制，包括游戏内所有的实体存在，所有的交互关系，所有的公式、参数，所有的公理法则。通俗的说，这个词和游戏规则的含义比较接近。

业内人士一定会觉得这听起来很像我们常说的游戏逻辑，但这个词更专业。事实上我还从没听到过国外用类似游戏逻辑的说法，因为英文的逻辑（logic）一词和我们的理解不一样。

Wikipedia的定义： http://en.wikipedia.org/wiki/Game_mechanics

术语：Workaround

nightmare:qrli — Thu, 02 Apr 2009 21:44:00 +0800

Workaround是指当问题无法从根本上解决时而采用的规避问题或者临时解决方法

中文翻译：
1. 变通方法
2. 权宜之计
3. 应急措施

术语：Homoiconicity(同像)

nightmare:qrli — Wed, 25 Mar 2009 19:02:00 +0800

在计算机编程领域，Homoiconicity(同像)是一种编程语言的属性，用来指该语言的程序的基本表现形式本身同时也是该语言自身的数据结构。如LISP就是Homoiconic(同像的)。C#的Lambda表达式也是同像的，可以被传唤成表达式树结构，但C#本身不是。

staging resource的翻译

nightmare:qrli — Mon, 16 Mar 2009 19:11:00 +0800

staging一词有两种含义，一个是表示正在上演，另一个是阶段性的。后者来源于一个舞台演出会有很多幕组成，也就是多个stage。所以有了分阶段的、分级的、分期的、过渡状态的、临时的等含义。如staging disk是阶梯磁盘，用于磁带备份前的过渡性存储；staging base是中继补给站；rocket staging是火箭分级；staging flight是中途降落的飞行等。staging资源也是取阶段性的、过渡性的含义。D3D10对staging类型的定义是资源在内存中，用来从显存往内存传送数据。其实也就是D3D9里的scratch类型。另外，可以map的staging资源也可以用来更新不能map的default资源。那么staging resource应该翻译成什么呢？A. 阶段资源B. 中继资源C. 登台资源D. 其他

设计日志三：3D游戏内的GUI系统

nightmare:qrli — Sun, 15 Mar 2009 00:17:00 +0800

3D游戏内往往无法使用操作系统的标准GUI，主要是由于GDI和3D是完全不同的加速模块处理的，如果把它们放在一起，会有闪烁、其中一个不可见等不确定的结果。另一方面，也有游戏程序普遍使用不同于系统的个性GUI的原因。游戏内的GUI可以做得简单、也可以做得复杂，但无论如何，它做起来总是比预想的复杂。

矩阵和向量的乘法顺序

nightmare:qrli — Thu, 12 Mar 2009 21:04:00 +0800

矩阵和向量的乘法顺序

似乎经常有人被这个问题转晕。向量有两种表达形式，行向量和列向量，对应的矩阵也有行矩阵和列矩阵。采用哪种形式和左右手系无关。

行矩阵：
    三个轴向量为前三行，最后一行为位移变换
    连乘时从左到右接合，左边的变换先应用
    变换向量时为vector * matrix
列矩阵：
    三个轴向量为前三列，最后一列为位移变换
    连乘时从右到左接合，右边的变换先应用，注意这和*运算符的接合顺序相反
    变换向量时为matrix * vector

DirectX采用了行矩阵，OpenGL采用了列矩阵，而基于OpenGL的OpenInventor却采用了行矩阵。图形学的书籍多使用列矩阵和列向量，或许是学术上的传统，或许是节省版面的原因；而不少图形库选择了行矩阵是因为行矩阵在现有的内存架构上效率要略高于列矩阵。另外，行矩阵的接合顺序和*运算符是一致的，这一点非常适合运算符重载。

而四元

设计日志二：脚本系统

nightmare:qrli — Sun, 08 Mar 2009 20:25:00 +0800

根据经验，修改程序的速度远远赶不上策划修改游戏设计的速度，如果用流程强制他们减慢改变的频率，也就限制了他们的创造力。如果能让他们自己做些修改和尝试，将大大提高游戏的整体开发效率。脚本系统正是用来解决这个问题。

设计日志一：保留模式的3D图形引擎

nightmare:qrli — Sun, 08 Mar 2009 05:22:00 +0800

如今，随着渲染技术越来越复杂，立即模式的图形引擎已经变得很不方便了。因为不同的渲染方法需要不同的绘制流程，很多渲染算法又需要多趟(Multi- pass)，而从模块设计和封装的角度看，不应该把具体的渲染方式暴露给外部，其他模块也不关心图形模块使用什么样的渲染技术。而这正是保留模式解决的问题。