为 Atari ST 打造全动态视频编解码器 STV

STV: A full-motion video codec for the Atari ST

为 Atari ST 打造全动态视频编解码器 STV

我喜欢将 DOS 时代的游戏移植到 Atari ST 上。在移植 Command & Conquer 时,我发现 Westwood 的 VQA 视频格式无法直接在仅支持 16 色的 Atari ST 上运行。为了在 8 MHz 的 Motorola 68000 处理器上实现流畅播放,我开发了 STV 编解码器。它利用 8x8 的图块和动态 codebook,通过 movep 指令高效渲染。音频方面,我放弃了复杂的 ADPCM 解码,转而使用 Atari STE 的 DMA 硬件直接播放 PCM 数据。核心策略是保持播放器极简,将复杂的 YUV 处理、DCT 分析和 Simulated Annealing 调色板优化全部放在现代主机端的编码器中完成。

聪明的算法往往输给了那些针对硬件特性精心编写的汇编代码。
  1. gblargg

    我想看看示例片段编码后的大小。或者这仅仅是一个技术测试,用来验证它能播放什么,而不是试图优化视频大小?

  2. ColdStream

    一旦看到这张瓦片地图在实际运行中的效果,你就会意识到这个想法是多么天才又简单。你每帧只能更新 32 个瓦片,但只要运动量足够小且有剩余空间分配,就可以提前预加载即将显示的瓦片。

    非常希望看到类似的东西被移植到 Amiga、Mega Drive 和 Neo Geo 等类似的系统上。它们都是 68K 架构,都基于瓦片。

    另外,看到结尾的游戏画面,简直太棒了。我完全没想到在那样的系统上甚至有可能实现,但它确实做到了。

  3. esafak

    > 每个 8×8 的块被转换为一个短 DCT(离散余弦变换)特征向量;距离是在那里测量的,而不是在原始像素上。

    这是你的主意还是代理(agent)的主意?因为感觉这本质上就是在描述 JPEG(除了熵编码部分),却偏偏没提它的名字。JPEG 是 1992 年发布的——比 C+C 还早。这让我很想知道,为什么 Westwood 当时不直接用 JPEG 呢……

    有趣的事实:DCT 的发明者:https://en.wikipedia.org/wiki/Nasir_Ahmed_(engineer)

同日更多故事

2026-08-07