帧间压缩的一点探讨

这里的文章都是云风偶然的想法, 没有去写码实现, 等我真正用程序实现了, 再归档在技术专题里. BTW, 发现光说不做的人真多, 当然也算我一个 ;-)

关于帧间压缩的问题最早专门考虑是源于某国内游戏公司的一位朋友的一封email, 提到老外的游戏多用这个方法减少数据量. 的确, Diablo 细腻的动作没有帧间压缩是不能控制在 8M 内存的机器上用的.(是这样吗? 有研究过 Diablo 的朋友给我说一下?) 漂亮的 ARPG 图量之巨没有搞过的朋友是难以想象的, 所以应该也必须这个技术. 而我为这想法而第一次写码是今年寒假在北京 8studio 那, 看到了好多杀气的图片是做实验的好材料, 就乘兴写了段程序试试最简单的帧间压缩,看看效果.

今天又一次阅读了 C&C 的 MIX 文件格式文档, 他们的帧间压缩无非也是压缩掉帧间不同的地方. 直接将两张图逐点 XOR 值绝对是个好方法. 这样会有很多的好处。体会一下就能明白 ^_^ 采用这样简单的 压缩, 即将一套动画链表样的串起来,会有些什么问题呢?

首先是速度上的损失, 如果是直接在屏幕Buffer 里改, 应该会更快, 但这需要在屏幕 Buffer 里坐标固定的小动画. 而且其中还会有许多的难点, 和不合理的地方. 否则, 每次生成一帧图, 就要多一次运算再画上去. 我想这个速度的损失都不太重要, 假设节省下内存使程序不频繁读 虚拟内存, 那么减少的硬盘访问时间主够抵消这个速度损失了, 何况帧间压缩的前提就是区别不大, 每次修改的部分不算多。

最主要的麻烦在于, 串起来的图片, 帧间依赖性太强 (若只用第一帧做关键帧效果又不好) 假设屏幕上有两个相同的 NPC 作着相同的动作, 但不是同步的, 我们也需要保留两个图链. 他们的图是不可以共享的. NPC 数量多到接近这组动作的帧数的时候, 内存占用反而增大了. 那么是不是说, 只有主角和特殊的 NPC 需要帧间压缩?

游戏中多用 RLE Sprite 加快处理速度和节省内存(比如风魂的 RLE Sprite 比普通的 Sprite 处理速度明显的快) 而帧间压缩的两个 RLE Sprite 合并挺费事的. 要么合并后我们就不 RLE 压缩了 要不就需要云风我再痛苦一次, 用 ASM 写个优化版本 ;-) Sigh, 有没有 ASM 高手帮我做这个事呢? 写到这里, 我已经决定在风魂里低层支持高速的帧间压缩结构. 不过要等我的文件打包部分写完才能开始了

云风 于1999.4.5