云风的 BLOG

在游戏（包括引擎）开发的过程中，谈及 UI 模块，通常所指有二：

1. 开发工具所用到的 UI 。
2. 游戏本身所用到的 UI 。

这两者很多时候都是共用的一个模块，比如之前的 Unity 就直接把引擎开发用的 UI 模块扔给开发者开发游戏使用。但很快，开发者就发现，适合工具开发的 UI 模块，在做游戏时就不那么顺手了。所以就有了第三方 UI 插件的流行，以至于最后又倒逼 Unity 官方重新制作游戏 UI 模块。

开发工具面临的需求和游戏场景面临的需求很不一样：

开发工具需要的时候更好的将内部数据以可视化方式呈现出来，供用户浏览和修改，以适应数据驱动的开发。UI 的呈现需要的一致性，风格统一有利于减少学习成本，同时需要清晰的表达复杂的数据结构。有时还需要将内部数据的变化过程同步的动态呈现，给开发者更直观的感受。

游戏 UI 是游戏过程的情感体验的一部分，外观和交互需要根据游戏设计专门化。它往往并不需要表达游戏内部复杂的数据结构，而是将那些数据以额外面对玩家的形式展现出来。玩家通过界面下达的指令也并非直接对数据的修改，而是以指令流的形式传递过去。另外，HUD 也是很大的一个部分，和 UI 对话框在设计上也有很大的不同。

他们两者之间在技术上的共性其实很小，针对这些共性的技术实现可能也只有几百到上千行代码的规模，远少于差异部分需要的代码量。我比较倾向于把这两个东西分开实现。

阅读全文 "游戏 UI 模块的选择" »

云风 提交于 10:30 AM | 固定链接 | 留言 (10)

skynet 的内核是一个多线程的消息分发器。每个服务有一个消息队列，任何服务都可以向其它任意服务的消息队列投递消息，而每个服务只可以读自己的消息队列，并处理其中的消息。

目前的工作原理是，在任意消息队列不为空的那一刻，将该消息队列关联的服务对象放在一个全局队列中。框架启动固定数量的工作线程，每个工作线程分头从全局队列中获取一个服务对象，并从关联的消息队列中获取若干条消息，顺序调用服务设置的回调函数。如果处理完后消息队列仍不为空，则将服务对象重新放回全局队列。

这样，就完成了尽量多（远超过工作线程数量）的并发服务的调度问题。

我这些年一直在考虑这个模型可否有改进之处。能不能设计得更简单，却还能在简化设计的基础上进一步提高并发性。同时，还可以更好的处理消息队列过载问题。

阅读全文 "skynet 并发模型的一点改进思路" »

云风 提交于 01:03 PM | 固定链接 | 留言 (18)

最近给 bgfx 的 lua binding 做了一点改进，因为修改了原有的 api 语义，所以需要做一点记录。

对于 3d 库来说，API 涉及大量的内存块的操作。创建 Buffer ，贴图，shader ，都需要输入一个数据块。大多数数据块是只读的，少部分是需要回写的。对于只读数据块，封装层可以用 lua string 替代，可写的用 userdata 。

bgfx 自己抽象了一个叫做 Memory 的结构，用来统一描述这类内存块对象。按 bgfx 的定义，Memory 的构造由用户决定，而释放通常由 bgfx 管理，而非调用者。

即，用户负责构造出 Memory 对象，将数据拷贝进去，然后再传递给 bgfx 的 api 后就可以撒手不管了。但是，如果你构造出 Memory 对象不传递给 bgfx 则会造成内存泄漏（因为没有任何直接释放它的方法）；也不可以将一个 Memory 对象使用多次（传递给 bgfx 多次），因为一旦传给 bgfx ，就失去了对象的控制权。

阅读全文 "内存块对象的 Lua 封装" »

云风 提交于 02:14 PM | 固定链接 | 留言 (6)

在 blog 上，我写过好几篇关于场景管理模块的树结构的文章。这些也是我这两年在做游戏引擎中对象管理的思考历程。

通常游戏引擎中会把可渲染对象以树结构储存，这是场景管理模块最常见的作法。顺便说一句，GUI 界面也是用类似的方式。但是，我始终认为，从 gameplay 的层面上来看，游戏逻辑需要关注的对象并不需要用层次结构的方式管理。因为，空间结构上的层次很可能发生变化，从而引起关注的对象的层次路径变化。我们最终关注的那些东西不变，但它们在空间中的位置却会经常改变。

我一直在思考的问题是：为什么一定要用树结构组织可渲染对象？树结构到底带来了什么好处？

最直接的好处是，减少矩阵运算的次数。因为，渲染层最终需要对象在整个世界中的位置，而每个被渲染的部件本身却是逐级组合起来的（为了减少数据重复，我们不能因为一个部件换了个位置，就复制一次），部件只会记录相对整体的一个局部空间变换。如果我们平坦的保存没有可渲染部件，势必在计算它最终被渲染到屏幕时的世界矩阵的时候，需要连乘一长串局部矩阵。而组织成树结构，以一定的次序计算，可以大大减少最终矩阵乘法的数量。

但这一点好处，我认为还没有触及本质。表达空间位置的矩阵，仅仅是可渲染对象的一个属性而已。

层次结构的本质是让属性可以用继承的方式优化储存，并方便批量修改。对于每种属性，会定义一种对应的继承方法。

阅读全文 "层次结构和状态继承" »

云风 提交于 10:43 AM | 固定链接 | 留言 (12)

最近一段时间，lua 的邮件列表中有好几个主题讨论 hash 表的设计。我读下来受益匪浅。比如 前两周的这个主题 中，有同学主张去掉 lua hash table 中的链表指针，而改成固定步长的冲突链表。具体这里就不展开了，有兴趣的同学可以自己看。

这两天的讨论是围绕 lua 的 hash 函数的，暂时还没有固定链接，我把我的理解和思考记录下来，不一定正确，如有行家发现错误，请不吝赐教。

unsigned int
luaS_hash (const char *str, size_t l, unsigned int seed, size_t step) {
  unsigned int h = seed ^ cast_uint(l);
  for (; l >= step; l -= step)
    h ^= ((h<<5) + (h>>2) + cast_byte(str[l - 1]));
  return h;
}

来看这样一个 hash 函数：

阅读全文 "lua hash 函数的一点讨论" »

云风 提交于 01:15 PM | 固定链接 | 留言 (4)

前几天晚上 21 点洗澡的时候感觉左腹部疼痛。因为前一天有过一次腹泻，便以为是吹空调着凉还没有好。继续蹲在马桶上又拉了一次肚子，但和之前不同，并没有减少痛苦的感觉，反而加重了。

我转而怀疑是吃错了什么东西引起的肠胃问题，但是努力回忆也想不出什么来。只觉得如果能把腹中的东西排空应该就好了。想了一下就抠了一下喉咙，趴在马桶上将肚子里没消化完的食物吐了出来。可是依然不见好转。

这个时候已经是坐立不安了，找不到一个姿势可以让自己好受一点。

我自觉还是对疼痛忍耐指数挺高的，攀岩的时候手指肚上拉下一块皮也不觉得有什么，可以继续爬；有次拔智齿的时候甚至没打麻药，牙科医生都赞我是看过的病人里最能忍痛的。可这次真的有点受不了。

阅读全文 "记一次生不如死的经历" »

云风 提交于 11:22 AM | 固定链接 | 留言 (30)

我在翻译《程序员修练之道》第二版时，一开始拿到的版本并不是现在出版的这个。所以在中途更换过一个版本，即最后英文版的最终版。前后两个版本都不是原始 markdown ，而是 pdf 格式的。试过几个 diff 软件都无法很好的比对，只好花了不少时间人肉校对了一遍。

虽然两个版本先后只差了几个月，但是增加，调整的段落非常之多，可见作者维护的非常频繁。我当时特别想一观他们的内部写作仓库。记忆比较深刻的是有一大段谈团队的文字被删掉了。不知道原因。但我觉得挺可惜的，这是我很喜欢的一个段落。为了忠于原著，我也从中译版里删除。

下面记录一下这段废稿：

阅读全文 "《程序员修炼之道》中的一段废稿" »

云风 提交于 11:18 AM | 固定链接 | 留言 (11)

Unity 推广了预制件 Prefab 这个概念，在此之前，Unreal Engine 里有个类似的东西叫做蓝图 Blueprint 。当然它们不完全是一种东西。我现在自己设计游戏引擎，更喜欢 Unity 中的 Prefab ，但我认为 Blueprint 这个名字其实更贴切一些。

当我们说制作一个 Prefab 的时候，其实制作的是一个预制件的模板。引擎运行时对应的那些数据，其实按照这个模板生产出来的。所以，工具制作出来的 Prefab 其实是一个 template ，所以，它本质上就是一张蓝图。但因为 Unity 深入人心，所以我还是打算基于把这个东西叫预制件。

对于 ECS 系统来说，预制件是一组数据，通常保存在文件中，可以以该资源文件的内容为模板，来构造一组 Entity。注意：预制件作为资源文件时，和贴图、模型数据等这些资源文件是不同的。贴图之类的资源，映射到内存后，就是一个数据块或一个引擎中的 handle ，可以被共享使用。但预制件本身只是一个模板，它用于生产数据，本身不是数据。从这个角度讲，如果把预制件文件当作资源纳入资源管理模块统一管理的话，预制件资源对应的是一个 function （生成器）而不是 table （数据集）。

阅读全文 "游戏引擎中预制件的设计" »

云风 提交于 10:58 AM | 固定链接 | 留言 (3)

这篇是对 游戏引擎中的资源生命期管理问题 的延续。

最近对我们游戏引擎的资源模块做了一次重构，大概花了一周的时间，其中核心模块的代码实现花了 2 天。比之前的方案简洁很多。新方案的设计是基于以下原则来实现的：

1. 引擎应该围绕数据来设计。ECS 更是数据驱动的模型。
2. 数据全部都用一致的数据结构来表达，方便统一处理。因为我们采用 lua 做开发，所以，一切数据都是 lua table 。我们的引擎与其说是基于 lua 开发，不如说是基于 lua 的数据结构开发。即使某些模块因为性能因素用 C/C++ 实现，操纵的还是 lua table 。读写 lua table 的性能和读写 C struct / array 相比，并无显著的劣势。
3. 在使用上尽量不区分外部不可修改的静态数据和运行期动态修改的数据。
4. 惰性加载，延迟异步加载，替代资源，这些尽可能的隐藏起来，不必对外透露细节。尽可能的减少外部干预。
5. lua 虽然有 metatable 这个神器，可以帮助我们抹平不同数据、不同策略之间的差异。但不要过多依赖语言特性。

阅读全文 "资源模块的重构" »

云风 提交于 01:18 PM | 固定链接 | 留言 (3)

这篇是对 场景层次结构的管理 的再思考。

最近在重构引擎的场景管理模块。主要动机之一，还是觉得现在已经实现的东西（由于需求不断增加）太复杂了，以至于老在修补其中的 bug 。

经过了几天的思考后，我决定把场景管理中的一部分挪出来，单独作为一个模块。那就是对层次结构的排序。

具体是这样的：

阅读全文 "场景层次结构的排序" »

云风 提交于 03:56 PM | 固定链接 | 留言 (2)

我翻译的 The Pragmatic Programmer 20th Anniversary Edition 已经摆上了书店的货架。今天收到了出版社快递来的几本样书。纸张挺精良的，对得起这本著作。听朋友说，京东上的预定也陆续到货了。我非常期待各位学友的反馈。

去年几乎是一口气翻译完的。倾注了颇多心血。一边翻译一边和身边的朋友分享，几乎每个读过的人都很喜欢。我希望每个程序员都能读一读这本书。即使你已经读过第一版，也绝对不能放过这个新版。我在翻译过程中一直在做新老版本的对照，能明显感到与时俱进的内容。而且即使是没怎么修订的章节，这次因为读得非常细致，也有很多新的领悟。

限于水平，这次的翻译一定会有差错。希望发现错误的朋友能不吝指教。我会尽力在重刷的时候修正过来。

另外，这次的译本同时拿到了 kindle 上出版的版权（挺不容易的）。kindle 电子版应该会在 2-3 月内上线。不太喜欢囤实体书的同学可以再等等。

勘误见这里： https://github.com/cloudwu/tpp_feedback/

6 月 24 日，kindle 电子版上线。

云风 提交于 03:50 PM | 固定链接 | 留言 (13)

我们的游戏引擎中，有个重要的功能是将一个矩阵分解成 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 的时候，就不必再开方了。

阅读全文 "矩阵 decompose 的一点优化" »

云风 提交于 02:33 PM | 固定链接 | 留言 (5)

去年的时候，我们对正在开发中的游戏引擎做了一点 profile 工作。后来发现，在场景中对象很多的时候，有一处运算占据了 10% 以上的 cpu 时间。当时我的判断是，这处地方值得优化，但并不是工作重点，所以就搁置了。

问题的具体描述是这样的：

我们的引擎每帧会将场景中的对象依次提交到一个渲染队列中，每个可渲染物件，除了自身的网格、材质外，还有它自身的包围盒（通常是 AABB），以及它在世界空间中的矩阵。

我们有一套资源系统，场景中的对象会引用资源系统中的对象，这些资源对象是一个不变量，会被多个场景对象所引用。而资源对象又可以是一个树结构，比如一个模型就可以由若干子模型所构成。提交到最终渲染队列中的是不可再拆分的子模型的信息。

也就是说，在场景管理的层次，对象的数量是远少于提交到渲染队列中的对象数量的。这就是为什么我们渲染每次重建渲染队列，而没有将每帧提交给渲染队列的列表持久化为一个链表并作增减维护的原因。

问题出在提交给渲染队列的每个物件的包围盒上。

阅读全文 "不变量及运算优化" »

云风 提交于 01:17 PM | 固定链接 | 留言 (5)