8088 Domination 技术复盘：在初代 IBM PC 上播放全动态视频

……如果你怀疑上面视频的真实性，可以下载这个作品，在你自己的老式硬件上运行，以此作为证据。

我想先为这篇文字中过去时（即我在设计阶段的思考过程）和现在时（在描述如何实现某些目标时）的来回切换提前道歉。

几十年来，我一直对桌面数字视频着迷。从 1990 年代初的第一批 Video For Windows 工具开始，使用早期的采集硬件（比如 Media Vision Pro Movie Spectrum，它可以直接采集为 MSV1/CRAM 格式），我一直在摆弄桌面视频及其可能性。

当然，从 1990 年代初开始，我也一直对 demo 着迷，当你如此热爱两件事时，你就会想办法把它们揉在一起。我的许多 demoscene 作品都以某种方式把视频作为一部分或全部。Grind（1993）是一个 modplayer，显示跳舞的春假女孩，完美地踩在音乐节拍上；Explicit（1996）的结尾部分有跳舞的夜店人群嵌在立方体中，也同样完美地踩着音乐节拍；当然还有 8088 Corruption（2004），它在 1981 年的 IBM PC 上显示 FMV，也曾让我短暂地出过一阵名。

8088 Corruption 被人记住，不是因为它惊人的视频质量，而是因为它对「在如此受限的平台上显示 FMV」这一问题的新颖解法。那个解法是使用 40×25 文本模式，因为这是唯一一种视频内存占用量小到可以在每一帧完全改写、又不会产生干扰性伪影或让系统过载的模式。

我在 2007 年做过一个演讲，详细解释了 8088 Corruption，在演讲中我解释说，用 CGA 图形模式显示 FMV 是不可能的。这是因为 CGA 图形模式使用的视频内存是 8088 Corruption 所处理的 8 倍。即使做一个简单的计算，假设 24fps 的视频，也能看出每秒需要更新的数据量（24fps * 16KB = 384KB/s）超出了 IBM PC 的能力：CGA RAM 只能以 240KB/s 的速度被改写，而那个年代的大多数硬盘大约以 90KB/s 运行。当时确实感觉不可能，所以我就这么说了。

然后我把这个问题想了 7 年。

过去几年里，在思考这个「不可能」的问题时，我有了几个领悟。最基本的领悟是：要显示令人信服的 FMV，并不总是需要改变屏幕上的每一个像素。如果只有画面的一部分在动，比如传统动画，或者「大头播报」式的新闻节目，屏幕上并不是每个像素都在变化。但即使一帧里所有像素都在变，它们可能也只是变化了一点点……而如果变化真的那么小，我们就算作弊、干脆不改它们，观众可能也注意不到。所以，我们需要放弃「每一帧都必须改变整个屏幕」的想法。只要画面内容合适，我们只改变屏幕内存的一部分也能蒙混过关，看起来就像我们改变了整个屏幕。

左图：黑白=差异，灰色=未变。右图：只应用变化后用户看到的样子

另一个领悟来自重新评估系统上可用的带宽到底是什么。之前，我把「40×25 文本模式的 2K RAM」当作屏幕上可改变内容的限制。但「改变 2K 数据」并不是真正的限制；真正的限制是「不超过改变 2K 所需的时间」。换句话说，真正的限制是每帧更新屏幕内存不超过特定的时间配额，无论你改了多少屏幕内存。

这引出了关于磁盘 I/O 的类似想法。在 Corruption 中，我把磁盘带宽当作一系列固定长度的读取，频率等于我需要产生的帧率。结果，Corruption 使用固定长度的视频+音频包，这样（帧率 * 包大小）就保证小于可用磁盘带宽。但没有理由坚持这一点；真正的限制是磁盘 I/O 本身，只要不超过硬件能提供的量，我就可以在给定时间段内读取任意数量的磁盘数据。这引出了另一个领悟：视频+音频包可以是变长的。

这些想法以及其他想法的结合，促成了一个系统的设计，它能够满足最初「图形模式下的 FMV」的要求，这意味着我们需要一个系统能够：

因为 IBM PC 不够快，无法实时做出这些决定（也没有足够的带宽），所有这些约束都需要在编码阶段处理，那时我们几乎有无限的时间。这也意味着这些约束中的大部分（如果不是全部）其实只是数据管理问题，我稍后会讲到。但在我们写下哪怕一行代码之前，我们需要先退一步，看看如何把 24 位彩色图像转换成在 CGA 卡上看起来不会完全惨不忍睹的东西。

快速介绍一下 CGA：CGA 是 IBM PC 的第一个彩色图形标准，包含 16KB 内存用于保存屏幕内容。那块内存可以呈现为几种不同的图形模式，它们看起来不同，但实际上底层都一样：80 个「字节列」宽、200 行。那 80 个字节列可以被切成几种不同的方式：

让我们看看这些在实际中是什么样子。这里有一只漂亮的蜂鸟：