早上上班的路上，在必经的一条马路，看到一个蓝衣人趴在路中间隔离带的水泥桩上。车流比较大，一晃就开过去了。我问坐在副驾驶的老婆：刚才那个人好奇怪啊。她说是啊，那个人怎么了？我说，昨天你没看到吗？他保持那个姿势已经一整天了，感觉连手指头都没动过。
说到这里，我赶紧把车靠边停下来打了 110 ，附近的派出所联系了我，说马上派人过去看看。我的心情久久不能平静。走在路上，我喜欢观察四周的细节，其实昨天就感觉不对了。路上没有血迹，我以为他/她（看不到脸）是在翻越隔离带时身体不舒服想休息一下。但一个人保持那种姿势几分钟而不动肯定不正常。如果昨天这个时候就报警或许更好呢？
最近一段时间都在公司内寻找项目可以合作推进 Ant Engine 的使用。我觉得自研引擎的一个重要优势在于我们可以针对具体游戏更好的做性能优化。在目标设备硬件性能允许的范畴内，把画面质量和交互体验做到更好。而同样的优化手段，在通用商业引擎上面做会困难的多，甚至无法顺利完成。
我们用 Ant Engine 制作的第一款游戏 Red Frontier 在一年前是性能完全不达标的。它在 iPhone 8 上甚至都达不到 30fps ，无法流畅游戏。很多性能问题是已知问题，比如我们用 Lua 搭建了整个引擎，一开始只考虑了引擎结构和正确性，把性能搁置在一边待后面再处理。
优化方案是一开始就想好的：借助 lua ecs 框架，把数据结构放在 C 内存中，必要时可以绕过 Lua 代码，直接用 C 代码控制核心数据。我们花了大约 3 个多月的时间将核心渲染系统用 C 重写后，就把性能提高了 1 个数量级以上。这个过程可以说是一直掌握在手中，按计划推进。
但即使可以让游戏运行在 60fps 下，优化的目标也远远没有达到。这是因为对于手机设备来说，用户更容易产生电量焦虑。在固定座位上插着电玩主机或 PC 游戏，玩家不会去想游戏机耗了多少电；即使把 switch 外带玩游戏，也可以一直玩到没电；但用手机不光是用来玩游戏的，如果消耗电量太快，玩家会担心手机等一下会不会无法支付交通费用，不能扫码吃饭……
我甚至一度怀疑，手机并不适合长时间沉浸式的游戏类型。或许放置游戏这类玩一下放一下的游戏类型更合适一些？
ltask 是 Ant engine 的基础设施之一，在对 Ant engine profile 的过程中，我们发现了 ltask 的一些值得提升的地方。
我们希望尽可能的提升游戏帧率，缩短渲染每一帧的的时间。因为 Ant engine 是由很多并行任务构成的，任务调度器的策略会直接影响单帧需要的时间。
ltask 虽然和 skynet 想解决的问题是一样的：管理 m 个线程（任务/服务），让它们运行在 n 个 cpu 核心上。而它们的应用场景不同，ltask 目前用在游戏客户端，它由一两个重负荷任务和若干低负荷任务构成，优化目标是低延迟；而 skynet 主要用在服务器上，由数以千计的类似负荷的任务构成，优化目标是高负载。
在 skynet 中，服务之间并行运行，而每个服务自身的业务都是串行的。一个服务由开发者自行切分成多个时间片，每个时间片串行运行在不同的工作线程上。最常见的做法是在每个服务中运行一个 Lua 虚拟机，用 coroutine 切分时间片，这样从编写代码的角度看，任务是连续的。
这个设计的目的是，让开发者轻松享受到多核带来的并发性能优势，同时减轻编写多线程程序带来的心智负担。
用过 skynet 的应该都碰到过：当我们在服务中不小心调用了一个长时间运行而不返回的 C 函数，会独占一个工作线程。同时，这个被阻塞的服务也无法处理新的消息。一旦这种情况发生，看似是无解的。我们通常认为，是设计问题导致了这种情况发生。skynet 的框架在监测到这种情况发生时，会输出 maybe in an endless loop 。
如果是 Lua 函数产生的死循环，可以通过发送 signal 打断正在运行运行的 Lua 虚拟机，但如果是陷入 C 函数中，只能事后追查 bug 了。
虚拟文件系统 (vfs) 是 Ant 引擎的核心模块。在 wiki 上有介绍 ，blog 上也有总结。
最近在按前段时间拟定的思路重构编辑器。在这个过程中对 vfs 有了一些新想法。短期内不打算把工作重心放到重构 vfs 上面，先记录一下。
最早设计 vfs 的时候，是从网络文件系统的角度看待它的。我把它设想为一个类似 git 的组织方式，带版本控制的网络文件系统。所以，很多设计思路都是延续这个而来。但是，经过了这些年的数次重构，我对最初的思路产生了一些怀疑。
其中，最重要的一条：在游戏运行时，游戏程序看到的 vfs 是一个树结构的不变快照。这样，它像 git 一样，就可以用一个 Merkle tree 的 hash 值就可以代表这个快照，也可以方便的通过网络同步它。
为了实现编辑器，我们在这个设计上打了一些补丁，让编辑器可以在运行时动态的修改它。而我今天反思，“不变快照” 这一点是否是多余的？或者并不需要这个约束，也可以用简单的方案实现现在所有的功能。
这两天在改 log 模块。我们需要一个并发写 log 的模块，它有多个 log 生产者一个消费者，这个唯一的消费者在 log 线程中把 log 数据持久化。
大多数 log 生产者是在第三方库的 callback 函数中调用的，比如 bgfx ，如果写 log 不够快的话，就会阻塞渲染。这个 callback 需要自己保证线程安全。因为 bgfx 支持多线程渲染，所以写 log 的 callback 可能在不同的线程触发。
过去在实现 bgfx 的 luabinding 时，我实现了一个简单的 mpsc 队列，get_log 这个函数就是那个单一消费者，它取出队列中所有的 log 信息，返回到 lua 虚拟机中。
它是用 spin_lock 实现的。这两天，我想应该可以实现一个更通用的无锁版本。
bgfx 提供了一组调试文本输出的 api ，可以把一些文本信息显示在屏幕上。这些 API 非常简陋，只是提供了一个文本模式缓冲区。离控制台还很远。
具体见 文档中 的 dbgText* 系列函数。
随着我们的游戏引擎中越来越多的信息需要展示，直接使用这些 api 就越发简陋了。最近萌发的想法是干脆使用 imgui 来绘制调试信息界面。但我又觉得保留 bgfx 自带的这个文本模式也有一些好处。
我在自己研发的游戏引擎上已经工作了 6 年了。在 2017 年底，我写下了对这个新引擎最初的构想 。现在回头来看，当初的想法居然都落实了，只有一点例外：我们中途把编辑器从 IUP 转移到了 ImGUI 上。
2022 年，我们启动了第一个用这个引擎开发的游戏项目，它是一个和日本公司合作的动作游戏。后来，这个项目没有走下去就取消了。之后，因为我们的引擎开发组喜欢 Factorio ，便想用自己的引擎在手机上重现一个 Factorio Like 的游戏，这一干就是一年多。
现在，游戏的技术部分基本完成，可以验证引擎的可用性（功能完整、性能达标），只是游戏性方面还有不少路要走。简单说就是还不太好玩。
从一开始，我就希望以开源模式经营这个游戏引擎，但同时又觉得没有得到验证的东西不适合拿出来。既然引擎已经初步可用，现在就应该迈开这一步了。
我们游戏 UI 基于 RmlUI 的 fork，做了大量的改造。它实际上类似目前的 web 前端技术，使用 CSS 来表示 UI 的布局。所以，我们做的底层工作也都是围绕如何高效实现一套基于 CSS 的 UI 引擎来做的。
一年多前，我写过一篇 blog 介绍了一些优化的工作。
最近，在游戏开发的使用中，我们又发现了一些性能热点，最近在着手优化。这一篇 blog 记录一下其中的一个优化点。
上周五在公司内做了一个技术分享，介绍我们最近五年来自研的游戏引擎，以及最近一年用这个引擎开发的游戏。大约有一百多个同学参加了这次分享会，反响挺不错。因为这些年做的东西挺多，想分享的东西太多，很多细节都只是简单一提，没时间展开。
我谈到，我们的引擎主要专注于给移动设备使用，那么优化的重点并不在于提高单帧渲染的速度，而在于在固定帧率下，一个比较长的时间段内，怎样减少计算的总量，从而降低设备的能耗。当时我举了几个例子，其中有我们已经做了的工作，也有一些还没做但在计划中的工作。
我提了一个问题：如果上一帧某个像素被渲染过，而若有办法知道当前帧不需要重复渲染这个像素，那么减少重复渲染就能减少总的能耗。这个方法要成立，必须让检查某个像素是否需要重复渲染的成本比直接渲染它要低一个数量级。之所以现存的商业引擎都不在这个问题上发力，主要是因为它们并没有优先考虑怎么给移动设备省电，而要做到这样的先决条件（可以廉价的找到不需要重新渲染的像素），需要引擎本身的结构去配合。
提起游戏引擎，特别是商业通用游戏引擎，比如 Unreal 或是 Unity ，给人的第一印象会是它们的可视化编辑器。而在实际开发中，在不同引擎下做游戏开发，影响最大的是引擎层的 API 以及这些 API 带来的模式。
而对于使用自家专有引擎开发出来的游戏，却少见有特别的编辑器。比如以 Mod 丰富见长的 P 社游戏，新系列都使用一个名叫 Clausewitz 的引擎，玩家们在之上创造了大量的 Mod ，却不见有特别的编辑器。Mod 作者多在文本上工作，在游戏本身中调试。游戏程序本身就充当了编辑器：或许只比游戏功能多一个控制台而已。在这类引擎上开发，工作模式还是基于命令行。
我们的游戏引擎是基于虚拟文件系统，可以通过网络把开发机上的目录映射到手机上。这对开发非常方便，开发者只需要在自己的开发机上修改资源，立刻就能反应到手机上。
但当游戏发行（也就是我们正在准备的工作），我们还是需要把所有资源打包，并当版本更新时，一次性的下载更新补丁更好。
之前一直没时间做这方面的工作，直到最近才考虑这个问题。我们到底应该设计一个怎样的补丁更新系统。
Lua 的数据类型非常有限，用 C 编写的 Lua 模块也没有统一的生态。在不同模块间传递内存块就是件很头疼的事情。
简单通用的方法就是用 Lua 内建的 string 类型表示内存块。比如 Lua 原生的 IO 库就是这么干的。读取文件接口返回的就是字符串。但这样做有额外的内存复制开销。如果你用 Lua 编写一个处理文件的程序，即使你的处理函数也是 C 编写的模块，也会复制大量的临时字符串。
我们的游戏引擎是基于 Lua 开发的，在文件 IO 上就封装了自己的库，就是为了减少这个不必要的字符串复制开销。比如读一个贴图、模型、材质等文件，最后把它们生成成渲染层用的 handle ，数据并不需要停留在 Lua 虚拟机里。但是，文件 IO 和资源组装（比如贴图构造）的部分是两个不同的 C 模块，这就需要有效的内存交换协议。
死亡 (3)
kknd :
想对于有尊严的死亡没有希望并痛苦的活着可能更可怕...
Ant Engine 的一些优化 (3)
zyb :
虽然该项目短期不开(太)可能更换引擎。有个错别字...
死亡 (3)
乐为舟 :
眷念到释然，有时难以跨越，有时却是转瞬。...
Ant Engine 的一些优化 (3)
怪物公司 :
https://mp.weixin.qq.com/s?__biz=Mz...
Ant Engine 的一些优化 (3)
fangcun :
2023年GDC谷歌分享了安卓的动态性能框架：https://www....
让 Erlang 的控制台支持中文 (19)
name great :
现在应该没啥人用erlang了吧...
避免帧间不变像素的重复渲染 (19)
Zerman :
https://gdcvault.com/play/1034828/1...
避免帧间不变像素的重复渲染 (19)
ouyang :
博主可以考虑参考一下视频编码中的帧间编码，有类似的思想可以提供...
重构 ltask 的任务调度器 (1)
cat :
任务偷取加抢占, 一个goroutine最多占用CPU 10ms，防止...
