一台1993年的世嘉Mega-CD,CPU主频12.5MHz,画面只有16种颜色,每秒能从光驱吃进150KiB数据。刨去16位16kHz的PCM音乐占用,留给每一帧画面的预算,只剩不到8KiB——大概是一张纯文本邮件的大小。就这点数据,《Silpheed》做出了让整个游戏媒体圈以为主机在实时算3D的过场动画。

开发者Fabien Sanglard花了两周把这套视频格式逆向了一遍。更值得说的是他的做法:全程没写一行代码,靠自己搭的AI框架跑完整个逆向流程,下个月准备开源。技术揭秘和方法论示范,这次是一件事的两面。

tile拼图,不是视频压缩

Mega-CD没有帧缓冲,画面靠768个8x8像素的tile拼出32x28的网格,再通过tilemap把tile摆到屏幕上。这套机制原本是为了省内存画背景,《Silpheed》的编码团队反过来把它当成了压缩格式用。

每一帧都自包含,不依赖前后帧做差分压缩,这在今天看是笨办法,但换来的是解码逻辑极简。真正的省钱手段藏在tile复用里:一帧896个tile实例中,456个只是重复引用15种纯色tile。这一步直接省下一半带宽。

剩下的440个非纯色tile里,再挑出234个只用两种颜色的,交给Mega-CD ASIC一个冷门功能——“Font bit”硬件位图展开。本来是给日文假名渲染准备的,《Silpheed》拿来把2色tile压成1bit位图加调色板索引,ASIC硬件直接展开成4bit像素,又省下超过三分之一的数据,CPU也不用逐位掩码写入。最后只剩206个tile老老实实存原始数据。

tilemap本身也没放过:768个tile位置,用一张768bit的位图标记“自动递增”还是“读取新编号”,把原本960字节的表压到652字节左右。

一帧896个tile,怎么省下来的 纯色tile复用 456 ASIC双色硬件生成 234 原始存储 raw tile 206 三类相加 = 896个tile实例 / 单帧 tilemap压缩:960字节 → 约652字节 单帧总预算:约8KiB(已扣除音乐带宽)

美术风格是压缩策略,不是审美偏好

大多数Mega-CD的FMV游戏走的是相反路子:硬把一段真实影像塞进小窗口,再靠有损压缩和抖动硬撑,结果画面惨不忍睹,《Night Trap》就是常被拿出来鞭尸的例子。Game Arts的做法是倒过来:先摸清硬件能给多少带宽,再让美术风格去适配这个上限——平涂多边形、无高洛德着色、16色封顶、极少抖动。

  • 结论.限制越死,美术风格的选择空间越窄,《Silpheed》证明窄到极致也能做出说服力,前提是美术团队要有本事把16色用出层次。

游戏内的激光和爆炸效果不是纯色,是靠调色板末尾4个颜色每帧轮转实现的多色错觉,代价是玩法画面只剩12色可用——过场动画反而因为不需要这个特效,能用满16色。这种“为了一个视觉效果牺牲三分之一调色板”的取舍,今天看依然狠。


口碑没有原文说的那么一致

“持续到今天的好评”这个说法值得拆开看。当年EGM四位编辑打出的分数是9、7、7、7,普遍认可背景画面震撼,但明确批评Boss设计平庸、武器系统单薄——这是一款背景比玩法更抢戏的射击游戏,不是全票满堂彩。ACE给出接近满分的评价,GamePro把它评为年度CD游戏亚军,英国世嘉在媒体宣传上也确实卖力。褒贬集中在同一件事上:视觉够格,游戏性普通。

同年Super Nintendo上的《Star Fox》靠Super FX芯片做出真正的实时多边形3D,EGM平均分接近8.75。两款游戏常被放在一起比,但技术路线完全不是一回事:《Star Fox》的多边形是主机实时算出来的,《Silpheed》的“3D”是离线预渲染画面被拆进tile系统里播放。当年宣传里出现过“50万多边形”这类说法,对照Sanglard的逆向结果,指的显然是预渲染素材的复杂度,不是Mega-CD实时算力——DieHard GameFan等杂志发售前的造势,把这层区别模糊掉了,也为后来部分玩家“货不对板”的情绪埋了雷。

视觉震撼和实时3D,从来不是一回事,只是当年没人拆开算。

零代码逆向,是另一半新闻

Sanglard这次逆向的成果本身很扎实——tile复用比例、ASIC硬件解码、tilemap压缩率,每个数字都能在帧图里对上。但他反复强调的是过程:两周,不写代码,靠自研AI框架完成从格式猜测到验证的全部工作,下月开源。

  • 提醒.这套方法论目前只有一个样本案例,能不能复制到更复杂、文档更少的老游戏格式上,还得看开源后的框架能不能扛住别人的验证。

对复古游戏保护和逆向工程社区来说,这比《Silpheed》本身的历史地位更值得盯——如果这条路真能走通,大量濒临失传的老硬件格式,可能不再需要一个人埋头啃汇编几个月。