最近和公司一个开发团队探讨了一下他们正在开发的游戏中遇到的性能问题，看看应该如何优化。这个游戏的战斗场景想模仿亿万僵尸(They are billions）的场景。在亿万僵尸中，场景中描绘了上万的僵尸潮，但我们这个游戏，超过 500 个僵尸就遇到了性能问题。固然，手机的硬件性能比不上 PC ，但 500 这个数量级还是略低于预期。
对于游戏中大量类似的动画物体，肯定有方法可以优化。我们来看看渲染这些动画可行的优化方向：
常见的方式是把僵尸先预渲染成图片，而动画自然就是多个图片帧。对于亿万僵尸这个游戏来说，它本身就是基于 2D 渲染引擎的，这么做无可厚非。
最近一段时间都在公司内寻找项目可以合作推进 Ant Engine 的使用。我觉得自研引擎的一个重要优势在于我们可以针对具体游戏更好的做性能优化。在目标设备硬件性能允许的范畴内，把画面质量和交互体验做到更好。而同样的优化手段，在通用商业引擎上面做会困难的多，甚至无法顺利完成。
我们用 Ant Engine 制作的第一款游戏 Red Frontier 在一年前是性能完全不达标的。它在 iPhone 8 上甚至都达不到 30fps ，无法流畅游戏。很多性能问题是已知问题，比如我们用 Lua 搭建了整个引擎，一开始只考虑了引擎结构和正确性，把性能搁置在一边待后面再处理。
优化方案是一开始就想好的：借助 lua ecs 框架，把数据结构放在 C 内存中，必要时可以绕过 Lua 代码，直接用 C 代码控制核心数据。我们花了大约 3 个多月的时间将核心渲染系统用 C 重写后，就把性能提高了 1 个数量级以上。这个过程可以说是一直掌握在手中，按计划推进。
但即使可以让游戏运行在 60fps 下，优化的目标也远远没有达到。这是因为对于手机设备来说，用户更容易产生电量焦虑。在固定座位上插着电玩主机或 PC 游戏，玩家不会去想游戏机耗了多少电；即使把 switch 外带玩游戏，也可以一直玩到没电；但用手机不光是用来玩游戏的，如果消耗电量太快，玩家会担心手机等一下会不会无法支付交通费用，不能扫码吃饭……
我甚至一度怀疑，手机并不适合长时间沉浸式的游戏类型。或许放置游戏这类玩一下放一下的游戏类型更合适一些？
上周五在公司内做了一个技术分享，介绍我们最近五年来自研的游戏引擎，以及最近一年用这个引擎开发的游戏。大约有一百多个同学参加了这次分享会，反响挺不错。因为这些年做的东西挺多，想分享的东西太多，很多细节都只是简单一提，没时间展开。
我谈到，我们的引擎主要专注于给移动设备使用，那么优化的重点并不在于提高单帧渲染的速度，而在于在固定帧率下，一个比较长的时间段内，怎样减少计算的总量，从而降低设备的能耗。当时我举了几个例子，其中有我们已经做了的工作，也有一些还没做但在计划中的工作。
我提了一个问题：如果上一帧某个像素被渲染过，而若有办法知道当前帧不需要重复渲染这个像素，那么减少重复渲染就能减少总的能耗。这个方法要成立，必须让检查某个像素是否需要重复渲染的成本比直接渲染它要低一个数量级。之所以现存的商业引擎都不在这个问题上发力，主要是因为它们并没有优先考虑怎么给移动设备省电，而要做到这样的先决条件（可以廉价的找到不需要重新渲染的像素），需要引擎本身的结构去配合。
我们的手机游戏引擎一直在跟随着游戏项目的进程不断优化。一开始是因为游戏引擎在手机上帧数达不到要求。得益于 ECS 框架，我们把初期用 Lua 快速开发出来的几个核心 system 用 C 重写后，得到了质的飞跃。
其实这些核心代码总量并不算大。例如在 profile 中表现出来的非常消耗 CPU 的一个场景树更新系统，用 C 重写了也才 200 行代码 ，但在优化前 Lua 版本会消耗超过 1ms 的时间，而用 C 重写后，时间已可以忽略不计。
另外，我们采用了类似 skynet 的 ltask 做多线程框架，把业务尽量拆分到多线程中并行处理，这也极大的减少了每帧的耗时。除了主业务逻辑外，UI 、粒子系统、IO 被分为几个并行线程。且渲染底层的 bgfx 也是按多线程渲染设计的。这些并行流程间只通过少量的消息通讯，所以，并行的总工作量并没有比单线程模型更多。ltask 也可以很方便的调节工作线程的个数，用来更好的适配手机的 CPU 。
从xcode 的调试信息看，在游戏场景丰富时，大约会占用 280% 的 cpu 。换句话说，如果我们采用的是单线程架构，在不删减特性的前提下，做到流畅是相当困难的。
今天是年前最后一天工作，我想对最近做的一些事情做一些记录。
我们在使用自研引擎开发游戏时，遇到了不少和预期设计有距离的问题，针对问题再反思了原有的设计并做出改进。我认为、凭空设计一个通用游戏引擎是不可能的，必须结合实际项目，做许多针对性的实现。但同时应不断反思，避免过多的技术债。在最近一年，我参与的引擎具体编码工作很少，更多的是站在一个反思者位置，监督代码和设计的演变。
我们的引擎主体框架是基于 Lua 的，受益于 Lua 的动态性，可以很方便的把各个模块粘合在一起。但是、Lua 和 C/C++ 相比，又有两个数量级的性能差异，对于渲染代码而言，若将和 GPU 沟通的 API 完全放在 Lua 的 binding 层，对于对象数量巨大的场合，很容易出现性能问题。我估计、在手机环境这个“巨大” 差不多在 10K 这个数量级吧，而 PC 环境还能支撑到 100K 左右。
Lua 项目的优化无非两条路：使用 jit 技术、把热移到 C side 。正如 Roberto 所言，"Finally, keep in mind that those two options are somewhat incompatible" 这两条路需要的操作往往是互斥的。而我不喜欢 jit 带来的复杂度和不确定性，所以选择了后者。
为了解决大数量对象的批量操作问题，我在 2021 年引入了 luaecs 。这个库现在已经是引擎的核心，专门用来解决 Lua 处理大数据重复事务的性能问题。通过 luaecs ，我们可以把对象的初始化这个繁杂的过程使用 Lua 编写，而每帧都迭代的事务用 C 来实现。
一般来说，如果 10K 是场景可渲染对象的数目的话，那么对于很多游戏场景还是适用的。但如果Lua 调用的图形 API 放在太底层，手机上（以 Apple 的 A9 芯片为下线）一个流畅的场景却很难支撑到 10K 对象。这是因为，每个可渲染对象需要一系列参数传到图形 API 层，设置 VB/IB 渲染状态，尤其是大量的 uniform ，这些 API 差不多会在 10 个调用左右，它们会吃掉一个数量级，最终 Lua 层能流畅处理的数量大约只剩下 1K 左右了。
传统的蒙皮数据需要在模型顶点上存两组数据，其一为该顶点受哪些骨头的影响，其二为受这些骨头影响的权重。因为 GPU 的对齐影响，通常游戏中会将同一顶点受影响的骨头数量上限设为 4 。如果不做任何优化，骨头总数在 256 以下时，每个顶点需要 4 个字节保存骨头编号，再用 4 个 float 表示分别的权重。
因为权重之和总是为 1 ，所以，只用 3 个 float 也是可以的（第四个权重通过简单的计算就可以得到）。
因为权重总是 0-1 之间的数字，所以 32bits float 的精度远超所需，我们也并不需要浮点数。所以用 16bits [0,65535) 甚至 8bits (0,255] 来表示 0-1 的权重也够了。
所以，蒙皮一般至少占用 64bit 的定点数据 （4+4 bytes) 。
如果想进一步压缩，就需要一些复杂的技巧了。这两天读了几篇关于动画蒙皮数据压缩的 paper ，挺受启发的。
首先是这一篇 Vertex-Blend Attribute Compression 。
这两天写代码时用到之前写的一个对 Lua 配置表的 cache 模块 。感觉用起来还是不够简洁方便。我今天动手重新设计了一下。
需求是这样的：
项目有非常多的配置信息保存在 Lua 的 （树状层级的）table 中，大部分逻辑代码直接用 Lua 的语法便可直接访问。但是，有少量有性能要求的业务是在 C 中实现的，C function 中也需要读取这些存放在 Lua 中的配置数据。
配置项随着项目开发，变更非常频繁。如果我设计一个小语言，定义出配置表，用代码生成的方式把表项翻译成对应的 C/C++ 结构，再在 C side 根据 Lua 中的数据重建一组 C 数据也未尝不可。这就是 google protobuf 官方采用的方式（用代码生成的方式，根据数据的 schema 构建出 C++ 类，让 C++ 可以方便访问这些数据）。
但我不想搞得这么复杂（浪费？）。大部分业务循环次数很多，而需要读取的配置表象却比较单一（反复取相同的条目）。所以，虽然第一次通过字符串 key 逐级解析 Lua 配置表或许较为低效；但只要在 C side 用一个 cache 模块缓存下高频访问的配置项应该就能解决性能瓶颈。
这两天和同事讨论一个问题，我写了个小玩意。
事情起因是，我们公司上海的工作室的一个 MMO 项目做服务器压力测试。谈及优化，涉及到服务器中使用的 C 模块。他们把同一套 C++ 加上 namespace 编译了很多份，供多个服务使用。我很好奇，一般来说，Lua 的 C 模块是可以供多个 vm 共用的，并不需要实际链接很多份。仔细探究发现，原来这个代码中用到了一些全局对象（singleton 模式）。
我本能的觉得全局对象的设计中透着糟糕的味道，在逐个分析每个全局对象的必要性时，发现了一个有趣的东西：寻路模块。
我们的游戏引擎中，有个重要的功能是将一个矩阵分解成 S 缩放，R 旋转，T 位移三个分量。这里 T 直接取矩阵的第四行即可，代价比较高的是 S 和 R 的分解，其中 R 又取决于 S 的提取。
但是，游戏中大量的矩阵中是不包含缩放的，即 S 分量大多是 (1,1,1) 。一旦不用缩放，又可以简化 R 提取的操作。所以我打算对传统算法做一点优化。在提取 S 的时候多加一次判断，看值是否接近 1 。
计算 S 的方法是将矩阵的前三行当作三个 vector 3 分别取 length 。length 其实是取 dot 然后计算 sqrt。由于大多数情况预测 dot 值很可能为 1 ，那么当 dot 接近 1 的时候，就不必再开方了。
去年的时候，我们对正在开发中的游戏引擎做了一点 profile 工作。后来发现，在场景中对象很多的时候，有一处运算占据了 10% 以上的 cpu 时间。当时我的判断是，这处地方值得优化，但并不是工作重点，所以就搁置了。
问题的具体描述是这样的：
我们的引擎每帧会将场景中的对象依次提交到一个渲染队列中，每个可渲染物件，除了自身的网格、材质外，还有它自身的包围盒（通常是 AABB），以及它在世界空间中的矩阵。
我们有一套资源系统，场景中的对象会引用资源系统中的对象，这些资源对象是一个不变量，会被多个场景对象所引用。而资源对象又可以是一个树结构，比如一个模型就可以由若干子模型所构成。提交到最终渲染队列中的是不可再拆分的子模型的信息。
也就是说，在场景管理的层次，对象的数量是远少于提交到渲染队列中的对象数量的。这就是为什么我们渲染每次重建渲染队列，而没有将每帧提交给渲染队列的列表持久化为一个链表并作增减维护的原因。
问题出在提交给渲染队列的每个物件的包围盒上。
最近我们开发中的游戏引擎在修理资源管理模块中的 bug 时，我提出了一些想法，希望可以简化资源对象的生命期管理。
其实这个模块已经被重构过几次了。我想理一下它的发展轨迹。
最开始，我们不想太考虑资源的生命期问题，全部都不释放。当然，谁都明白，这种策略只适合做 demo ，不可能用在产品中。
因为我们整个引擎的框架是用 lua 搭建，那么，最直接的想法就是利用 lua 自带的 gc 来回收那些不被引用的资源对象。我不太喜欢这个简单粗暴的方法。因为首先， gc 不会太及时，其次 gc 方法触发的时机很难控制，容易干扰正常的运行流程。图形显示模块是时间敏感的，如果因为资源释放占用了 cpu 的话，很容易变成肉眼可查的卡顿。
另一个促使我们认真考虑资源管理模块的设计的原因是，当我们从 demo 过渡到现实世界的大游戏场景时，过多的资源量触发了 bgfx 的一个内部限制：如果你在一个渲染帧内调用了过多资源 api （例如创建新的 buffer texture 等），会超出 bgfx 的多线程渲染内部的一个消息管道上限，直接让程序崩溃。
所以我们不得不比计划提前实现资源的异步加载模块，它属于资源管理模块的一部分，所以也就顺理成章的考虑整个资源管理模块的设计。
前两天写了 快速字符串对象比较 ，我把这个想法提交到 Lua 的邮件列表，建议 Lua 的未来版本去掉长短字符串，不做 string interning ，用这个方法解决字符串比较的性能问题。Lua 的主要维护者 Reberbo 表示了兴趣，同时也提出了几点问题。
其中一个问题是，Lua 未必运行在 64bit 平台上，所以并没有直接使用 64bit 整数类型。而如果使用 32bit id 就无法简单的通过自增来保证 id 永远唯一。
我就这个问题考虑了几天，提了好几个解决方案，其中一个方案我最为满意，在这里重新用中文记录一下。
Lua 中的短字符串做了 string interning 的处理，即在同一个虚拟机内，值相同的字符串只存在一份。这可以极大的提高用字符串做 key 的 hash 表的查询速度。因为字符串比较的时间复杂度从 O(n) 下降到 O(1) ，比较查询的 key 和 hash 表内的 key 是否一致，只需要对比一下对象的指针是否相同即可。
我在解决多 Lua 虚拟机共享字符串对象这个问题时，合并了不同的 Lua 虚拟机中的短字符串表。让同一进程所有虚拟机共享一个短字符串表（ SSM ）。
我最初在实现 SSM 的时候，考虑到多虚拟机 GC 的复杂性，采用了只增不减的方案。即让部分短字符串进入 SSM ，设置一个上限，避免 SSM 无线膨胀。但 Lua 并没有把经过 interning 处理的字符串作为独立类型，目前只用字符串长度作为区分，也就是无法和不 interning 的短字符串共存。所以，那些已存在本地虚拟机短字符串表中的字符串，就不从 SSM 中获取对象。
修改过 Lua 的 string interning 算法是这样的：
查看字符串是否存在于本地字符串表 (LSM) 如果存在，就立刻返回。这一步和原版 Lua 一致。
查看字符串是否存在于 SSM ，如果存在，就返回。
检查是否 SSM 上限已到，如果不能再增加新字符串，把字符串添加到 LSM ，返回。
将字符串添加到 SSM ，返回。
今天一个同事反应，在使用 recastnavigation 库时，判断一个点是否在一个三角形内，遇到了精度问题，而且精度误差很大。
具体是 dtClosestHeightPointTriangle 这个函数。
他给出了一组测试参数，abc 三点为 {261.137939, 8.13000488} , {73.6379318, 8.13000488}, {76.9379349, 10.2300053} ，测试 p 为 {74.4069519 , 8.6093819 } 应该在这个三角形内，但是这个函数计算出来并不是。
我为 3d engine 项目设计的向量运算库 已经用了一段时间了。在使用过程中也一直在改进 。从一开始，我就考虑过，这个库的设计主要考量是减少 lua 和 C 交互间的开销，提高内聚性。而易用性方面，计划再上面再做封装。这段时间继续在想怎样从更自然的表达形式转换到这个库的逆波兰指令流上。
大致的方向有两个：
其一，实现一个小语言，用字符串输入表达式组。
其二，利用 Lua 已有的语法解析设施，把 lua 的一个函数翻译成对应的数学运算指令流。
两者都可以看成是一种 jit 的过程，在第一次运行的时候，做一些翻译工作，把要进行的数学运算打包成 C 代码可以处理的指令流，或翻译成现有数学库支持的指令流；或者，增加一个 lua 源码的预处理流程，在预处理阶段做好编译工作（aot）。
这个需求可以分解成三个问题：
首先，如何把更易用的的源码对接到 lua 原生代码。
其次，如何转换为正确的数学运算指令流。
最后，为以上过程选择 jit 或 aot 集成。
最近在做 3d engine 时发现，我们使用的渲染 api 库 bgfx 提供的 log 回调函数是需要自己保证线程安全的。也就是说 bgfx 有可能在不同线程（采用多线程渲染时）调用这个 log 回调函数。
如果回调函数仅仅只是把 log 串写入文件（例如标准输出），那么可以由 crt 本身来保证线程安全。但如果想自己处理 log ，例如把 log 串压回 lua 虚拟机，那么就必须自己负责线程安全的问题。
最近在做新引擎 UI 模块的工作。汉字字体纹理需要占比较大的一张贴图，考虑到这张贴图只需要用一个通道就够了，所以我决定使用压缩贴图。在手机设备上，GL_COMPRESSED_R11_EAC 是一个不错的选择。
EAC 是 Ericsson 提出的对单通道贴图的压缩方案，现已进入 OpenGL 的官方标准。它通常会结合 ETC2 一起使用。ETC2 负责 RGB 部分，EAC 负责 Alpha 通道。偶尔也可以单独使用。它会将每个像素解码为 [0,2047] 的整数，有 11bits 的精度，故而被称为 R11_EAC 。不过，我阅读文档后发现，其实有效精度是 8 bits ，一般也是从 8bits 的原始数据中编码得到的。压缩后，每 4 * 4 = 16 个像素会被编码为 64 bits ，压缩比 2 : 1 。用于字体纹理的话，可以节省一半的显存空间。
如果用纯 lua 来做向量/矩阵运算在性能要求很高的场合通常是不可接受的。但即使封装成 C 库，传统的方法也比较重。若把每个 vector 都封装为 userdata ，有效载荷很低。一个 float vector 4 ，本身只有 16 字节，而 userdata 本身需要额外 40 字节来维护；4 阶 float 矩阵也不过 64 字节。更不用说在向量运算过程中大量产生的临时对象所带来的 gc 负担了。
采用 lightuserdata 在内存额外开销方面会好一点点，但是生命期管理又会成为及其烦心的事。不像 C 中可以使用栈作临时储存，C++ 中有 RAII 。且使用 api 的时候也会变得比较繁琐。
我一度觉得在 lua 层面提供向量运算的基础模块是不是粒度太细了。曾经也想过许多方法来改善这方面。这两天实践了一下想了有一段时间的方案，感觉能初步满意。
最近在用 Lua 实现一个 ECS 框架，用到了一些有趣的 Lua 语法技巧。
在 ECS 框架中，Component 是没有方法只有数据的，方法全部写在 System 中。Entity 本身仅仅是 Component 的组合，通常用一个 id 表示。
但实际写代码的时候，使用面向对象的语法（用 Lua 的冒号 这个语法糖）却是比较自然的写法。比如我们在操作一个 Component 数据的时候，用 component:foobar() 比用 foobar(component) 要舒服一些。好在 Lua 是一门非常动态的语言，我们有一些语法技巧在保持上面 ECS 原则的前提下，兼顾编码的书写体验。
今天在读 https://github.com/guillaumeblanc/ozz-animation 这个动画库的代码时，发现它使用了一个有趣的四元数压缩技术。
我们用四元数来表示 3D 空间中的旋转，通常需要 4 个浮点数。不过用四元数表示旋转时，四元数通常会先做一次归一化，即 x*x + y *y + z*z + w*w = 1 。所以我们只需要保留 x,y,z 和 w 的符号位就够了。
但三个 float 来表示四元数既然有压缩余地。这是因为用来表示旋转量时， float 提供的 23 bit 精度是多余的。 1/2^23 的转角在视觉上完全是忽略不计的。而且 x,y,z 都一定小于 1 ，所以 float 的指数位也浪费了 1bit 。
ozz-animation 这个库采用了一个有趣的方法来做进一步压缩。
因为图形引擎中的对象天然适合用树 (n-ary tree) 表达，所以它在图形引擎中被广泛使用。通常，子节点会继承父节点的一些状态，比如变换矩阵，在渲染或更新的时候，可以通过先序遍历逐级相乘。
在 PC 内存充裕的条件下，我们通常不必考虑树结构储存的开销，所以大多数图形引擎通常会为每个渲染对象独立生成一个树结构，比如 Unity 中的 GameObject 就是这么一个东西。在 Ejoy2D 中，从节约内存的角度考虑，把树节点上的一部分可共享的状态信息（不变的矩阵、纹理坐标等）移到了资源数据块中，但是树结构的拓扑关系还是在新创建出每个 sprite 时复制了一份。
随着游戏制作的工艺提高，而大众使用的移动设备的内存增长有限，这部分的开销慢慢变得显著。在我们正在开发的几个项目中，渲染对象本身，而不算图形资源（贴图、模型等），也占据了以 M 为单位计算的可用内存。比如在一个项目中，某个巨型对象由多达 2000+ 个节点构成，创建速度和内存开销都成为一个不可忽视的问题。由于是于自研引擎，所以同事尝试过一些优化的尝试。
图形引擎处理的大多数的树结构对象，其实仅在编辑环境会对树的拓扑关系进行调整：增加、移动、复制节点。而运行环境下，树结构本身几乎是不变的。一般的树结构的实现是用指针来相互引用，编辑好的资源是树结构的序列化结果，而创建过程是一个反序列化过程，在内存中重建整棵树，并用指针重新建立节点间的联系。比如在 Unity 中，就把这种编辑好的树对象叫做 prefab 预制件。如果预制件比较复杂，加载预制件和从预制件中构建对象的时间成本都不算低。
一个优化方法是去掉运行时内存中的指针，改用 id 或资源数据块中的偏移量，这样，预制件可以直接从资源文件中成块读入，创建内存对象时也只需要用指针引用即可。可以节省大量在内存中重建的时间。Ejoy2D 现在就是这么做的。去掉指针的额外好处是在 64 位系统下，可以从 8 字节的引用开销减少到 4 字节（或更少）。Ejoy2D 当初做此修改，为一个项目一举减少了 10M+ 的运行期内存占用。而且资源文件可以在暂时不用的时候移出内存，等需要的时候再加载回来，而不用担心数据的内存地址发生了变化。
最近同事碰到的一个需求：需要频繁把一组数据在 skynet 中跨网络传递，而这组数据实际变化并不频繁，所以做了大量重复的序列化和传输工作。
更具体一点说，他在 skynet 中设计了一个网关节点，这个网关服务可以负责把一条消息广播给一组客户端，每个客户端由内部的一个 uuid 串识别，而每条消息都附带有客户端 uuid 列表。而实际上这些 uuid 列表组有大量的重复。每条广播消息都重复打包了列表组，且列表组有大量重复信息。
一开始我想的方法是专门针对这个需求设计一组协议，给发送过的数据组编上 id ，然后在发送方和接收方都根据 id 压缩通讯数据。即，第一次发送时，发送全量信息，之后再根据数据变化发送差异；如果完全没有变化，则只需要发送 id 。
之后我想，能不能设计一种较为通用的差异同步方法，可以在跨节点传递数据组的时候，避免将相同的数据重复传输，而采用差异同步的方法同步对象。
我们公司的一个 MMORPG 项目最近在内存方面碰到了红线，昨天开会讨论了一下。我提出了一个改进方案，写篇 blog 记录一下。
问题是这样的。在当下的手机及平板硬件设备条件下，操作系统留给应用的可用内存并不多，大约只有 500M 左右。
和 PC 环境不同，手机上是交换分区的机制来对应一些临时突发性内存需求的。而手机必须保证一些系统服务（某些高优先级后台业务）的运行，所以在接电话、收取推送等等意外任务发生时，有可能多占用一些内存，导致操作系统杀掉前台任务让出资源。
根据实际测试，游戏想跑在当前主流高端手机上必须把自己的内存占用峰值控制在 400M 内存以下，350 M 会是一个合理的值，而这个值是远远低于 10 年前的 PC 游戏标准的。而我们的项目却是一个写实类型的 拥有大场景的 MMORPG 。
在 ejoy2d 里，我将 sprite 的结构信息储存在一组叫 sprite pack 的结构中。其中包括动画的 frame 数据，sprite 由若干部分组成，每个部分的变换矩阵，对应贴图的编码和坐标等等。
通常这些数据不会太大，所以我建议一次加载到内存就不再删除。而动态生成的 sprite 对象则直接引用这些数据，不必做引用计数。这些数据之间的交叉引用（可以像搭积木一样用很多部件构成复杂的 sprite ）也不需要额外记录。但如果保存了大量的动画信息，或 sprite 是由非常多的小部件构成，数据量也可能非常可观。
在我们的 心动庄园 里，达到了数十 M 内存之多。前几天同事提到这个问题，我便动手做了一点简单的优化，居然省出了几十兆内存。
2d 游戏通常都用到很多图素，由于显卡硬件特性，我们又不会把单个图素放在独立贴图中。这样会导致渲染批次过多。在移动设备上，非常影响渲染效率。
所以，游戏运行时，这些图素一般都会合并在很少几张贴图上。要么采用离线合并的方式（利用 texture packer 这样的工具），或者在运行时使用装箱算法。
最近，朱光同学一直在为 ejoy2d 编写运行时合并图素的模块。今天我们讨论了一下他做的诸多尝试。
我们的游戏中需要对渲染字体做勾边处理，有种简单的方法是将字体多画几遍，向各个方向偏移一两个像素用黑色各画一遍，然后再用需要的颜色画一遍覆盖上去。这个方法的缺点是一个字就要画多次，影响渲染效率。
前几年有人发明了另一种方法，google 一下 Signed Distance Field Font Rendering 就可以找到大量的资料。大体原理是把字体数据预处理一遍，把每个像素离笔画的距离用灰度的形式记录在贴图上，然后写一个专门的 shader 来渲染字体。好处是字体可以缩放而不产生锯齿，也比较容易缺点边界做勾边处理。缺点是字模数据需要离线预处理。
我们的手游项目以及 3d 端游项目都大量使用了勾边字体，我希望直接利用系统字体而不用离线预处理字体把字体文件打包到客户端中。前段时间还专门实现了一个动态字体的贴图管理模块 。btw, 苹果的平台提供了高层 API 可以直接生成带勾边效果的字模。
但是，勾过边的字模信息中同时包含了轮廓信息和字模主体信息，看起来似乎很难用单通道记录整个字模数据了。这给染色也带来了麻烦。
根据 Lua 文档中的说法，lightuserdata 比 fulluserdata 要廉价一些。那么，其中的区别在哪里呢？
空间开销上，fulluserdata 是一个 GC 对象，所以比 lightuserdata 要多消耗一点内存，这点内存往往对程序不造成太大的影响。
时间开销上，fulluserdata 在访问它时和 lightuserdata 并无太大区别，它们都只能通过元方法才能在 Lua 中使用。所有 lightuserdata 共用一个元表，不如 fulluserdata 灵活，在元表访问效率上却是几乎相同的。对程序性能有影响的部分在于它们对 GC 环节的开销不同。
fulluserdata 本身是一个 GC 对象，所以在扫描的时候要复杂一些。它可能有附带的 uservalue 需要扫描，但不设置 uservalue 几乎就没有额外的扫描开销了。当 fulluserdata 有 gc 元方法后，就给 GC 流程增加了额外的负担。GC 模块需要额外记录一个链表来串接起所有有 gc 元方法的对象，推迟到 gc 的最后环节依次调用。
对于对延迟相当敏感的游戏程序来说，最容易造成运行过程中瞬间延迟增加，却又很难控制的部分就是 GC 了。所以我们在开发中经常需要关注怎样合理的使用 Lua 避免 GC 的负担过大。
最近特别忙, 每天写程序的时间都不够。有些东西在做完之前不想公开谈，所以只把一些笔记发在公司内部的周报里了。等这段时间过去，再贴到这里来。
不过还是有一些泛泛的心得可以写写的。
前几天遇到一个优化的问题。我想采用定期计算路图的方式优化寻路的算法。而不用每次每个单位在想查找目标的时候都去做一次运算并记录下路径结果。一切都看起来很顺利，算法的正确性很快就被验证了。可是最后实际跑的时候，发现在生成路图的地方会稍微卡一下影响流畅性。
我们的系统的应用场合比较特殊，在同一个进程内存在数千个 lua_State 。
Lua 的虚拟机占用的内存已经足够小了，但还是抗不住数量多啊。所以我希望有版本节约一些内存。
最想做的一件事情是把不同 lua_State 中相同的函数字节码合并起来共用一块内存。要做到这一点并不复杂。而且可以提高一些内存访问的效率。（因为大部分 lua 程序在并行执行相同的逻辑）
首先我们需要准备一个用来共享数据块的模块，它必须是线程安全的。因为既然分到了不同的 lua_State 就是想利用并发的优势。针对这个特定需求定制这样一个模块可以做到 lock-free 。
最近三周按计划在做第一里程碑的发布工作，几乎所有新特性都冻结了。大家都在改 bug 和完善细节。
服务器的性能还有不小的问题，压力测试的结果不能满意。原本我希望可以轻松实现 40 人对 40 人的战场。现在看起来在目前台式机上还有困难，虽然换上高配置的服务器可以达到，但会增加不少成本。我们决定动手做一些优化。
固然过早优化的必要性不大，但早期发现的性能问题有可能是设计原因造成的。尽早发现设计中的错误，早点改正，比后期在低层次优化要省力的多。
我们采用的是大量进程（非 OS 进程，这里指 Erlang 进程）协作工作的模式。可以充分利用多核的优势，但却对内部通讯的数据交换产生的极大的压力。初步发现在多人对战时，90% 的内部通讯包是状态包的同步 。虽然我们的框架实现，会让单台机器上的 Erlang 进程间通讯，变成同一进程内的简单函数参数传递。但数据列集和内存复制还是会带来一些负荷。
目前还不太确定内部数据包传递的边际成本到底是否影响到整体性能，我打算从优化这一部分的设计和实现入手，确定问题所在。
状态同步，简单说就是一个玩家的 Agent 在做一个动作时，它需要把这个行为通知所有在虚拟场景中他附近的玩家。当很多人（超过 50 人）在一起时，就有大量的数据包需要广播出去。我们目前的做法是基于这样一个假设：服务器内部数据包的传递非常廉价。广播包比逐个发送更加廉价，这是因为，单机内部广播，可以避免大量的数据复制。所以，在同一张地图上，我们会简单的把任意一个 Agent 的状态改变信息广播给同张地图的所有其他人。这样就不需要动态维护分组信息。当每个 Agent 收到广播包后，再根据自身的逻辑进行过滤，再发给对应的客户端。
或许我们需要一个更为高效的广播方案，避免一些无谓的包复制。
我想实现这样一个数据结构：
这是一篇命题作文，源于今天在微薄上的一系列讨（好吧，也可以说是吵架）。其实方案没有太多好坏，就看你信不信这样做能好一些或坏一些。那么，整理成 blog 写出，也就是供大家开拓思路了。
我理解的需求来源于网络服务提供程序的一个普遍场景：一个服务器程序可能会收到多个客户端的网络数据流，在每个数据流上实际上有多个独立的数据包，只有一个数据包接收完整了才能做进一步的处理。如果在一个网络连接上数据包并不完整，就需要暂时缓存住尚未接收完的数据包。
问题是：如何管理这些缓冲区比较简洁明了，且性能高效。
其实这个有许多解决方案，比如为每个网络连接开一个单独的固定长度的 buffer 。或是用 memory pool 等改善内存使用率以及动态内存分配释放，等等。今天在微薄上吵架也正是在于这些方案细节上，到底好与不好，性能到底如何。既然单开一篇 blog 了，我不像再谈任何有争议的细节，仅仅说说，用 Ring Buffer 如何解决这个问题。
前几天写的 pbc 初衷就是想可以方便的 binding 到动态语言中去用的。所以今天花了整整一天自己写了个简单的 lua binding 库，就是很自然的工作了。
写完了之后，我很好奇性能怎样，就写了一个非常简单的测试程序测了一下。当然这个测试不说明很多问题，因为测试用的数据实在是太简单了，等明天有空再弄个复杂点的来跑一下吧。我很奇怪，为什么 google 官方的 C++ 版性能这么差。
我的 lua 测试代码大约是这样的：
local protobuf = require "protobuf"
addr = io.open("../../build/addressbook.pb","rb")
buffer = addr:read "*a"
addr:close()
protobuf.register(buffer)
for i=1,1000000 do
local person = {
name = "Alice",
id = 123,
}
local buffer = protobuf.encode("tutorial.Person", person)
local t = protobuf.decode("tutorial.Person", buffer)
end
100 万次的编码和解码在我目前的机器上，耗时 3.8s 。
这周我开始做场景模块。因为所有 PC 在 server 端采用独立的 agent 的方式工作。他们分离开，就需要有一个模块来沟通他们。在一期目标中，就是一个简单的场景服务。用来同步每个 agent 看到的世界。
这部分问题，前不久思考过 。需求归纳如下：
大批量的数据同步对性能需求比较高。因为在 N 个角色场景中，同步量是 N*N 的。虽说，先设计接口，实现的优化在第二步。但是接口设计又决定了实现可以怎样优化，所以需要比较谨慎。
比如，同步接口和异步接口就是不同的。
请求回应模式最直观的方式就是设计成异步接口，柔韧性更好。适合分离，但性能不易优化。流程上也比较难使用。（使用问题可以通过 coroutine 技术来改善 ）即使强制各个进程（不一定是 os 意义上的进程）在同一个 CPU 上跑，绕开网络层，也很难避免过多的数据复制。虽有一些 zero-copy 的优化方案，但很难跨越语言边界。
今天跟同事闲扯的时候谈到 GAE SDK 刚刚支持了 Go 语言。这对于 Go 语言爱好者来说是个让人欢心鼓舞的消息。几乎所有人都相信它能比 Python 的执行效率高一些。从开发效率上来说，不会比 Python 差，那么 Go 语言的支持可能是比 Java 更好的选择（开发效率和执行性能的均衡）？
这也让我想到了前段在北京时跟 Douban 的同学聊 Go 的事情。那天，有同学问起 GC 的事，是个 C++ 程序员。C++ 程序员对 GC 知之甚少是可以理解的。我大约花了 10 分钟介绍简单的 GC 算法(：根扫描清理、三色标记、移动或不移动内存等等。那段时间我正在研究 lua 的 gc 实现，刚巧看了不少文章。
极尽简洁，然过犹不及(As simple as possible, but not simpler.)——爱因斯坦
这段时间的工作是把上次提到的 VFS 系统实现了。而写这篇 Blog 的促因是 twitter 上有同学想让我谈谈对 Linus 最近的一篇老生常谈的看法。哦，看似既然是语言之争。C 好，还是 C++ 好。但这次他平和了许多。Linus 惯有风格依旧，但少了些须三年前的争论 中的刻薄。
我想说，C 的三个特质(见引用文最后一段) 哪一点都不可忽略。Linus 这次强调的大约是第三点，也是 C++ 程序员们不屑一顾的一点。可对于多人协作构建的项目，这一点实在是太重要了。这并不是人人都聪明就能回避的问题。如果程序员们都足够睿智，反而更能意识到沟通之成本。其实即使是你一个人在做整个项目，从前的你和现在的你以及将来的你，同样有沟通（记忆）的成本。人不可能两次踏进同一条河流。
Windows 早期默认支持的中文编码方案是 GBK ，它是对早期 GB2312 的一个扩展。后来国家又发布了 GB18030 标准，扩展了 GBK ，增加了一些 Unicode 里才有的汉字，这样就可以做到和 Unicode 字符集做完全的映射了。
而后来 Unicode 逐渐成为标准，几乎所有的系统处理多国语言时，都把 Unicode 做为默认设置了。Unicode 有两套编码集，UCS-2 和 UCS-4 ，后者是对前者的补充，虽说字面说写的 4，但实际上只用到了 3 个字节不到。
Windows 的内部其实是用的 UCS-2 标准，并用 UTF-16 来实现。而非 Windows 系统大多采用了 UTF-8 。UTF-8 在很多情况下更有优势，首先它不需要考虑大头小头的问题，其次，数据损坏的时候，不会有半个汉字的问题。并且 UTF-8 可以完整的表达 UCS-4 而不需要有额外的付出。
前几年，处于 Windows 程序员转型期，经过一些痛苦的实践，我终于意识到，VC 提倡的所谓为软件维护 UNICODE 和 非 UNICODE 两个版本是件巨傻 X 的事情。之后，我们的程序再也不为内码分版本了，一律采用 UTF-8 。
不过，UTF-8 的设计明显是用英文为主的西方人搞出来的东西。对于中文一点都不环保。所有汉字和中文标点都需要 3 个字节才能表达。而少量欧洲字母可以用 2 字节表达，英文的 ASCII 符号则可以只用单字节。
我不指责这个设计，因为兼容 ASCII 是 UTF-8 的最大优势。其它，则是 KISS 原则下的产物。
不过，若是内部使用的话，如果你介意这 1/3 的储存空间的浪费的话，是不是有改进的余地呢？下面我们来讨论这个问题。
几年前我曾经写过一篇 blog 介绍我发明的一种高度图压缩算法 。最近几天，我将这个算法用于目前正在开发的 engine ，如之前所料，效果不错。由于数据被压缩，更改善了资源加载的速度。并在同等内存条件下，让用户得到更高的体验。（这是因为，现代操作系统，都会把暂时不用的物理内存全部用于磁盘缓存，更小的文件体积同时意味着在同等内存条件下能缓存更多的数据）
因为我们需要做动态地形数据的加载，所以地形高度数据也被切割成了一小块一小块。采用这个算法后带来的一个问题是：由于压缩有数据损失，两个相临块之间不能严丝合缝的衔接在一起。
为了解决这个问题，这两天想了好几个方法。
C 语言里有一个 alloca 函数，可以在堆栈上分配一块内存，当前函数退出时，由于系统堆栈指针的调整，这块内存会被自动回收。
alloca 的函数原型是
void * alloca(size_t size);
今天，在各种编程文档中已经不太提倡使用了。因为它有许多不安全因素。这里暂且不讨论。
另外，在 CRT 库里，通常还会提供一个 _alloca 函数，供编译器内部生成代码使用。比如在 C99 标准中，允许程序员在堆栈上开启变长数组，gcc 其实就是通过 _alloca 分配的内存来实现这个特性的。
另外，当你分配为局部变量数组申请空间过大时，gcc 也会调用 _alloca 。（大概是因为 crt 在实现 alloca 时，附带增加了一定的检测功能，测试堆栈溢出）
我想用 C++ 的人都用过 std::vector 。它是一个可变长的数组，在很多时候都比 C 固有的定长数组要灵活。
C 里没有这样的标准化设施，但是写软件的人通常都会实现一个。正所谓，不厌其烦的重造轮子 :D 。这里我们不讨论造轮子的好坏问题，直接讨论下实现这么个东西的一点小技巧吧。总是固执于用谁做的轮子的问题，眼光就太短浅了。
一般的 vector 的实现，需要记录三个数据：数据空间的地址，空间大小，数组里已存在的元素个数。也可能是这三个元素的变体。比如在 msvc 的 stl 实现中，vector 保存的是三个 iterator：数组头指针、最后一个元素的指针、分配出来的全部空间的末尾指针。
本来不打算立刻写关于这次 软件开发大会 的事情。太多可以写的东西，反而不知道怎么写起。今天才有机会上网到处转转，转到 周伟民老师 的 blog 上，看到这么一篇 。里面既然提到我，就想在上面回上两句。可惜 csdn 的 blog 系统实在是太烂了（这个话题我们在周六的沙龙上集体声讨过，暂且按下不表），硬是没发上留言。那么我还是在自己的地盘单独提出来说说吧。
周老师那个 session 正好排在我的前面。同一间会议室，而且内容我也颇有兴趣。也就顺理成章的听了。讲的东西其实满不错的，唯一的抱怨是太像在大学里授课，互动少了点。会场气氛远不如后来 Andrei 讲 Lock-Free Data Structures 那么精彩。
周老师讲的这块内容，正巧我前几年写多线程安全的内存分配器时碰到过，有点研究。加上前几年对 Intel 的东西颇有兴趣，便有了发言的冲动 :) 。当时的会场上下文环境正好是有个朋友提问说：实际上，InterlockedIncrement 的调用是多余的。（事后交换名片得知，提问的这个哥们是来至 google 的程序员）
以下的这个 C++ 技巧是前段时间一个同事介绍给我的，而他是从 fmod 中看来。当时听过后没怎么在意，主要是因为这两年对 C++ 的奇技淫巧兴趣不大了。今天跟另一同事讨论一些设计问题时，突然觉得似乎在某些地方还有点用途，就向人介绍了一番。讲完了后觉得其实还是有点意思，不妨写在 blog 上。
问题的由来是这样的：音频播放的模块中比较难处理的一个问题是，波形（wave sample）数据对象的生命期管理问题。因为你拿到一个对象后，很可能只对它做一个播放（play）的操作，然后就不会再理会它了。但是这个对象又不能立刻被释放掉。因为声卡还在处理这些数据呢。我们往往希望在声音停止后，自动销毁掉这个对象。
另一些时候，我们还需要对正在播放的声音做更细致的控制。尤其在实现 3d 音效，或是做类似多普勒效应的声音效果的时候。
C++ 中传统的方法是用智能指针的方式来管理声音对象，但这依赖语言本身的一些特性。fmod 提供了诸多语言的接口，它在为 C++ 提供接口的时候利用了一个更为巧妙的方法。
前段时间写过一篇 blog 谈到 用 timer 驱动游戏 的一个想法。当 timer 被大量使用之后，似乎自己实现一个 timer 比用系统提供的要放心一些。最近在重构以前的代码，顺便也重新实现了一下 timer 模块。
这次出于谨慎，查了一些资料，无意中搜到这样一篇文章：Linux内核的时钟中断机制 。真是一个不错的设计啊 :D 和我的 timer 实现的思路是一致的，但是在细节上要优秀。
今天同事在调试一个 win32 程序的时候，希望从 console 输出一些调试信息。他威胁说，否则，就要动用邪恶的 MessageBox 了。
我们以前的库倒是提供了一个 console 模块，可以从 win32 程序中创建出一个 console 。然后把标准输入输出定向到上面。这并不麻烦，就算不用翻出以前的代码重用一下，查下 MSDN 自己写上几句也可以解决。
今天突然想到，其实还有一个更 kiss 的解决方法。那就是直接开一个 console ，再在上面执行需要调试的程序。只不过直接运行是不会得到任何输出的，需要多做一步的是使用管道操作。
例如，需要调试的程序是 test ，那么只需要写 test | more 就可以把 test 的标准输出导向 more ，那么 more 就能捕获所有 test 的标准输出并显示在控制台上了。
我们的 engine 中定义了一个自己的类型叫做 boolean ，是这样定义的： typedef unsigned long int boolean;
我们的程序不主张使用 windows.h ，一直以来也没有去包含 windows.h
但是，今天包含 windows.h 时发现，boolean 被 redefinition 了。因为 C 语言里的 #ifdef 只能检查宏定义，而不能检查 typedef 定义，所以这个问题比较棘手。
周末我们遇到一个问题。运行时的资源需要统一的管理，资源本身是用垃圾回收的方法管理的。但是，有时候资源需要 lock 住，发生 gc 的时候绝对不能清理掉。我们最初的想法是，把加栽的资源 lock 的时候挂到一个 lock 链上，unlock 的时候取下来。
但是资源这个东西经常被重复使用，而我们又没有引用记数，导致 unlock 的操作无法正确工作。
我们现在的引擎中，所有的单件由一个管理类来管理。任何一个模块想取到一个单件，都可以通过一个统一的方法从管理类中拿到。
在调试程序的过程中，我遇到了一个奇怪的需求。我需要在一个单件的方法被调用时，程序都会停下来，进入调试器。
诚然，如果每次单件都通过 get_instance 取得，然后调用其方法的话，我们在 get_instance 里设置断点即可。但是，在我们的引擎中，每个模块都是在初始化阶段，拿到单件的指针。然后放在了全局变量中。单件的使用，直接运用这个指针。这样，就对监视这个单件的调用造成了麻烦。
为了解决这个问题，我用了一个很 trick 的方法，下面列出代码。
前段时间写过一篇 blog: _ftol 的优化。 今天在读 lua 5.1 的 source 的时候，发现一个更加有趣的技巧。把 double 转成 int 居然可以这样的简单。
union luai_Cast { double l_d; long l_l; };
#define lua_number2int(i,d) { volatile union luai_Cast u; \
u.l_d = (d) + 6755399441055744.0; (i) = u.l_l; }
这个宏神奇的在正数和负数的双精度浮点数时都可以正确工作，以四舍五入方式转换为 32 位整数。
今天读 freebsd 的源码时发现一个小技巧，经过同事指点，恍然大悟。原来 C 里面还是有好多东西自己不知道的啊。
typedef struct _jmp_buf { int _jb[_JBLEN + 1]; } jmp_buf[1];
这个是 setjmp.h 里的一行定义，把一个 struct 定义成一个数组。这样，在声明 jmp_buf 的时候，可以把数据分配到堆栈上。但是作为参数传递的时候则作为一个指针。这样和 c array 的表现一样了。
btw, 读 freebsd 的源码后，感觉头文件组织比 vc 的强太多了。
周一在上海的 <a href="http://www.zhucheng.biz/seminar">Modern C++ Design & Programming 技术大会</a> 上做了一个演讲。这里是<a href="http://www.codingnow.com/2005/optingames.ppt">讲稿 PPT</a>
这次 C++ 大会收获颇丰，刚从成都出差回来很累，今天就不写了。
在很多编译器中，memcpy 是一个 intrinsic 函数，也就是说，这个函数是由编译器实现的。它比 inline 函数更容易被编译时优化。编译器可以根据 memcpy 的参数是常量还是变量做出多种版本，达到最佳的性能。这一点，用 inline 或者 template 的技巧都无法办到。