不知道 backtrace-mingw 的同学，可以看这里 。

实际上，我为它提供的接口要更多一些，比如删除一个元素。

  void array_erase(struct array *, seqi iter);

原来的语义就是删除 iter 引用的元素。但这里引出一个问题：删除后，iter 是否应该保持有效？

从语义上说，iter 应该在调用完毕后变成一个无效引用。但实际应用中，往往需要在迭代 array 的过程中，删除符合条件的元素。让迭代器失效的做法，用起来很不方便。

第一件事是考察 License 。结果用的人做多的 ffmpeg 是 GPL 的，不适合我这种商业应用。虽然有一部分功能可以以 LGPL 的方式使用，但是遵守起来也是麻烦一大堆。想了一下还是做罢。我可不想学暴风影音和 QQ Player 那样上耻辱榜。

最终考察结果，居然没太多的选择。还是 google 的 vp8 最好。License 最为宽松，所以就去下载了一份 libvpx 的最新版试用。

上周的工作主要是设计了一个新的包格式，然后整合入前段时间实现的虚拟文件系统中。

这个工作和前段实现的 zipfs 有相似之处，所以做起来也很快。不过前面没仔细测试。今天比较闲，就设计了几组复杂的测试数据，感觉覆盖了各种边界情况。一测试果然发现了 Bug 。

这个 Bug 有点启发意义，所以在解决掉之后，决定记录一下。

当初的设计目的是：方便解析，快速定位资源包内的文件，方便更新、每次更新尽可能的节约带宽。这些年来，虽然各个项目修修补补的改进了资源包的格式，但本质上并没有特别大的修改。

一开始我们直接把需要打包的文件连接起来，在文件末尾附上文件索引表。当初为了快速定位文件名，文件名做了 hash 处理，可以用 hash 值直接定位文件。而资源包里并没有储存文件名信息，而是保存在一个额外的 index 文件中。这个 index 文件并不对外发布。所以直接对资源包解包是无法准确还原文件名的。

btw, 暴雪的 mpq 文件也是作类似处理的。除非你猜测出文件名，否则也很难对文件名还原。网上许多 mpq 解包工具都针对特定游戏附了一个额外的文件名列表。

和许多其它游戏 Client （比如暴雪的 MPQ 文件）不同。我们的包格式里文件与文件之间是允许有空洞的。这是考虑到资源包文件都比较大。如果用传统的打包软件运作的方式：从包内删除一个文件，就重新打包或移动内部数据。在玩家更新资源的时候，就会有大量的文件 IO 操作。比如 WOW 或 SC2 在更新的时候，下载更新包的时间往往只占整个更新时间的一小部分，大部分时间花在把补丁打在已有的资源包上。

如果频繁更新客户端，对于用户，这会有很讨厌的等待。

所以当初考虑到这个因素，我们在删除包内文件时，并不移动资源包内的数据，而是把空间留下来。如果新增加的文件较之小，就重复利用这个空间。如果利用不上，就浪费在那里。这有点像内存管理算法，时间久了，资源包内会有一些空洞，但也是可以接受的。

同时，还有另一个方式更新新的资源。那就是将需要更新的文件单独打包，以相同文件名（后缀不同）保存在用户硬盘上。游戏引擎在读取资源的时候，优先在更新的资源包内检索。这个方式在 Id soft 的 Quake/Doom 系列中也有采用。

为了保证用户补丁更新速度。我们的补丁中并不是保存的资源包内的小文件。而是在开发机上以增量方式重新打包。补丁文件其实是整个资源包的 diff 文件。由于前面所述的打包方案，这个 2 进制 diff 文件其实可以做到很小。尤其对某些文件的局部修改，对整个资源包的影响很小。

在公司，有后来的同事质疑过这种方式，觉得其对减少补丁体积的作用不大。反而增量打包增加了许多制作补丁包的时间。主张直接在补丁中放入更新的小文件，然后让最最终用户机上以小文件为单位做 patching 。

的确，2 进制 diff 的作用有限，现在很多项目改用文本数据格式，很小的修改就会影响整个文件的 diff 结果。不过原始的设计也有其历史原因。因为 10 年前硬盘 I/O 速度很慢，而大话西游在设计时又需要实现无缝加载的大地图。所以地图文件的格式是经过特别设计的。这种方式很适合地图文件的修改和更新。另外，对于未压缩的图片文件的更新也有其意义。

1. protobuf 本身的格式，google 是自描述的。定义为 google.protobuf.descriptor 。我先自己实现的 parser 图方便，用了自己的中间交换格式。为了日后更通用，稍微修改了一下，可以生成于官方相同的结构。解析的性能稍有下降，不过应该兼容性更好。

2. 一开始实现的 api 虽然性能非常好。（经简单测试，是 python 库的 30~40 倍，和 C++ 库性能相当）但若消息格式复杂，实现起来稍有麻烦。所以我做了点小封装。即为每个消息生成一对函数，可以用来打包和解包完整的消息，映射到 lua 的 table 结构上。lua 生成代码供自己调用的技巧在 lua 社区广泛使用。比如 kepler 项目。这使得 lua 可以用很短的代码行数完成很复杂的工作，不失性能。我这个封装层只有 100 行代码左右，一大半代码是为了解决消息展开时有递归定义的情况，否则更简短。（message 中有一些 field 的类型是自己，这是一种不多见的用法，但 protobuf 似乎并没有拒绝这种用法）

Google Proto Buffers 的意义在于，定义了一个不错的 PDL 。protobuffers 的实现反而不那么重要了。

这几天我一直在倒腾 lua 下的 proto buffers 的支持。一直在思考，怎样的接口才是最适合 lua 使用的。

大多数语言下的 proto buffers 实现，都是将编码的数据块展开成本地语言的数据结构。对于 C/C++ ，这是最高效的形式。但对于动态语言，那就未必了。虽然 google 为 python 做的 proto buffers 的官方实现也是如此，但我依然想考虑一下，是否有更高效的方式来做这件事。

又把代码注释干净，程序正常了。仔细考虑了一下，最后注释掉的代码间接 link 了 lua 的库。而 lua 的库引用了 lua 的动态库。程序运行时可能是因为没有找到 dll 而退出。

把 lua 的 dll 加到 path 中就正常了。但是奇怪的是，系统并没有弹出对话框提示。仔细想了一下，原来是我没有从 explore 启动控制台，而是在编辑器里启动的，可能是编辑器软件没有写好，把本应该系统弹出的缺少 dll 的对话框拦截了。

Soloist 同学说，他也碰到过一次 Total Commander 吃掉缺少 dll 无法启动程序的对话框。记录一下这个问题，祭奠我找问题逝去的半小时。

比如说今天，我们写的模型编辑器发到广州美术同事使用时，就出了问题。3d 程序在不同显卡环境下的确容易出故障，异地调试程序非常困难。这个时候，多么想看看调用栈啊。

The GNU C Library 是提供了 Backtraces 的，可惜 MinGW 不支持 :( 。最后打算自己写一个。

曾经也考虑过 iPhone 或是 Palm Pre ，请教了我公司的手机大神，大神同学说，他买过两款 iPhone ，用一段时间总想换，不推荐长期使用。至于 Palm Pre ，大神同学也买过一个，评价是极其垃圾，完全比不上 Treo 系列。他最近半年买过 Milestone ，Desire ，Nexus One ，X10i ，i9000 等等几款，每个都有不同的缺憾，最终比较下来，给我推荐了三星 i9000 。

我比较信任亲身使用者的感受，尤其是对手机如此挑剔，以至于每一两个月就情不自禁的买新手机的同学的现身说法。没太多犹豫就去 taobao 下了单。

结果…… 等了 8 天还是没寄来，卖家一直说缺货。昨天忍不住退了款，还是很干脆的。再一看，原来是涨价了，从 3450 涨到了 3600 。换了一家重新下单，今天一早就寄到了。

缺点在于，网络环境并不那么可靠。跨进程通讯有一定的不可预知性。服务器间通讯往往难以架设调试环境，并很容易把事情搅成一团糨糊。而且正确高效的管理多连接，对程序员来说也是一项挑战。

前些年，我也曾写过好几篇与之相关的设计。这几天在思考一个问题：如果我们要做一个底层通用模块，让后续开发更为方便。到底要解决怎样的需求。这个需求应该是单一且基础的，每个应用都需要的。

正如 TCP 协议解决了互联网上稳定可靠的点对点数据流通讯一样。游戏世界实际需要的是一个稳定可靠的在游戏系统内的点对点通讯需要。

我们可以在一条 TCP 连接之上做到这一点。一旦实现，可以给游戏服务的开发带来极大的方便。

在 C 语言中，函数定义是可以不写参数的。比如：

void foo();

这个函数定义表示了一个返回 void 的函数，参数未定。也就是说，它是个弱类型，诸如：

void foo(int);

void foo(void *);

这些类型都可以无害的转换成它。正如在 C 语言中，具体的指针类型如 int * ，char * 都可以转换为 void * 一样。

注1：如果要严格定义一个无参数的函数，应该写成 void foo(void);

注2：如果有部分参数固定，而其后的参数可变，则定义看起来是这样： void foo(int , ...); 这表示第一个参数为 int ，从第 2 个参数开始可变。

总这么人工检查也不是个事。所以我想写一个 svn 的钩子，在提交前检查。在仓库的 hooks/pre-commit.teml 加一行检查脚本应该就可以了。

我想用正则表达式匹配一下，可是想了想又觉得 UTF-8 和 GBK 的编码集有点交集，不太好做。btw, google 了一下，的确有人写过特定编码的正则表达式。

继续 google ，找到一篇跟我需求有点类似的文章UTF-8编码检测失败特例。看了正文，觉得不太靠谱，然后继续看回复，觉得这方法可行。

然后定睛一看，原来文章是孟岩写的，回复是我自己三年多前回复在他的 blog 上的。 -_-

现放在这里，接受大家的批评指正。勿转载。

这段时间的工作是把上次提到的 VFS 系统实现了。而写这篇 Blog 的促因是 twitter 上有同学想让我谈谈对 Linus 最近的一篇老生常谈的看法。哦，看似既然是语言之争。C 好，还是 C++ 好。但这次他平和了许多。Linus 惯有风格依旧，但少了些须三年前的争论 中的刻薄。

我想说，C 的三个特质(见引用文最后一段) 哪一点都不可忽略。Linus 这次强调的大约是第三点，也是 C++ 程序员们不屑一顾的一点。可对于多人协作构建的项目，这一点实在是太重要了。这并不是人人都聪明就能回避的问题。如果程序员们都足够睿智，反而更能意识到沟通之成本。其实即使是你一个人在做整个项目，从前的你和现在的你以及将来的你，同样有沟通（记忆）的成本。人不可能两次踏进同一条河流。