早期红白机的经典游戏容量出乎意料的小。
这个问题曾经在知乎上引起过热烈的讨论,B站、微信上都有相关的热门视频。相关资料我会整理到答案的末尾,以供参考。
经过一段时间的广泛讨论,这一问题逐渐变得更加清楚了。感谢Anjie的邀请,再将这个问题整理一遍做出回答,对一些有价值的信息做个总结 :)
首先,实际上初代《超级马力欧兄弟》只有40KB。
我们先别急着惊讶,先问一个问题:无论40KB还是400KB,它一定有一种基本的压缩方法,这个压缩方法与我们今天保存图片的方式肯定从根本上就有区别。
红白机的基本图像单元为“Tile瓦片”,每个瓦片为8x8像素大小。与现代游戏直接绘制像素的思路不同,红白机上的游戏必须先准备好一系列瓦片,再把瓦片拼在一起形成画面。
为什么要这么做呢?通过简单的数学运算可以知道,先做一些瓦片再拼接瓦片,内存占用量要远远低于直接绘制每一个像素。
例如:一张128*128像素的图片,每个像素可以选2^8=256种颜色,那么每个像素需要记录8bit=1Byte信息,共占用空间16KB。(128*128*1 Byte)
而如果换成8x8的瓦片去铺满图片,则只需要 16 * 16 = 256个瓦片就够了,如果总共只有256种不同样式的瓦片,那么只需要256B 即可表示这张图片。
简单来说:用重复出现的模式拼成一幅画面,可以极大压缩图片占用的空间。
但这里留下了一个问题:256种瓦片本身也要占用空间,瓦片本身如何存储?
FC虽然画质简陋,但色彩还是相当鲜艳的。在当时的技术条件下,FC理论上可以表示50多种颜色,一个像素的颜色可以用6bit表示。而一个瓦片有8x8 = 256个像素,那么就需要 8x8x6 bit = 48 Byte 来表示一个瓦片。
这么算起来就出问题了~~ 256种瓦片,每个瓦片 48 Byte,瓦片容量等于256*48 B = 16384 B。好家伙,什么都没干,光瓦片就存了16KB,显然太多了。
解决这一矛盾的核心,是另一个问题:FC如何保存颜色数据?
通过 @文礼 大神的回答可以知道(文礼 的回答),每个瓦片只能绑定一个调色板,而每个调色板只有4种颜色,所以每个瓦片的容量占用仅有 8x8x2bit = 16Byte,比上述估算的少4倍。
而且,调色板带来另一个有趣的功能,考虑下面几个图片:
外观完全一样有没有?
上图中不同的图片仅仅是颜色不同,并不需要创建新的瓦片,只需要给同一个瓦片替换不同的“调色板”即可。这样可以巧妙利用调色板,创建出不同皮肤的物体,而容量几乎没有增加。
现代音乐格式往往直接保存声道的波形,这种做法保真度高、通用性强,但很显然占用空间多,一首曲子的容量以兆字节计算。
而八位芯片时代的音频解决方案,关键是一颗专用芯片,例如FC用的理光2A03:
音频芯片可以产生合成音效,能提供的音色可以在一定程度上配置,但非常有限。听听FC游戏的音乐可以体会到常用的音色几乎一样。我觉得这个音频芯片最厉害的地方是可以同时播放几个音轨(但不能是和弦那种“同时”),《魂斗罗》、《沙罗曼蛇》、《忍者龙剑传》的殿堂级音乐,主要是靠多个音轨的交替配合实现的。
每个音符只要记录音色、频率和音高就足够了,音频芯片会识别出来。把音符按时间排列好就是“乐谱”了,可以简单理解为“简谱”。这种简谱需要的数据量十分有限,而且大部分游戏音乐都是循环播放,数据量更是小的可怜。
当时的芯片擅长产生的波形包括方波、三角波、正弦波等等,其中三角波用来做Bass效果很好。而《超级马力欧兄弟》里面的“鼓”是用“噪波”实现的,也是当年的常用做法。
FC的音频芯片还支持短时间的采样音乐,后期的《忍者龙剑传3》BGM里面的鼓声采用了8Bit采样声音, 效果超棒。
有趣的是,现在绝大多数人都忽略了程序代码本身所占用的空间。但在那个内存容量极其有限的年代,代码的体积不可小觑。
FC时代的游戏虽然逻辑不可谓不丰富,但确实整体代码不大。为什么呢?
因为FC时代的游戏,没有所谓的“引擎层”,FC的硬件本身就是一个非常简陋的游戏引擎。任天堂的主机完全是为游戏而设计的,瓦片、调色板、音乐、音效等基本功能已经预先考虑到了,使用特定的方式就能直接调用,这样一来就节约了大量底层代码。
程序员要仔细研究文档,在硬件框架下思考问题,比如如何显示图片、如何卷动屏幕等等;而且还要非常熟悉硬件底层和汇编,不要浪费代码空间。
一来二去,代码也能写的非常小。
为了极限压榨容量,当年的程序员和美术也动了不少脑筋,比如几个经典案例:
这些细节的优化,也对压缩大小起到了一定作用。但总的来说,并不是让容量变小的主力~~~
以上分5个部分,详细介绍了FC游戏容量小的原因,特别是背后的本质原理。
以上内容参考了很多内容,包括不限于wiki、知乎、B站等渠道。有错误的地方不吝赐教~~
参考资料:
还有其它很多参考,不好一一列举,向这些作者表示感谢。
首先,为什么是40KB?
因为FC在硬件上,CPU允许一次性映射ROM中32KB的数据(感谢指正,并非是读入内存而是映射,即分配一个可访问的地址),而PPU则是一次能用8KB。如果超过这个容量,也不是不可以,只是无法一次性将整个ROM中的数据映射到地址空间,而是需要动态切换,在需要的时候,将ROM中的特定数据映射(这叫做切换bank)。超级马里奥兄弟1代没有使用这样的技术,所以最大可用的容量就是32+8=40KB。
其他回答主要讲到了FC对于图像的处理,这其实是所有FC游戏(以及很多传统游戏机上的2D游戏)的处理方法。也就是说,这种压缩是通用的,并非超级马里奥兄弟独有。至于广为人知的“树丛和云使用的相同的图像”这一点,其实很有趣,因为它们的tile虽然确实一样,但使用了两个不同的meta-tile。
什么是meta-tile呢?
把4个8x8的tile组合起来,就是一个meta-tile。meta-tile的大小显然是16x16。用meta-tile的好处是,原本一个(比方说)32x32的图像只需要用4个meta-tile来描述,而原本需要用16个tile来描述。虽然我们需要额外的空间来存储meta-tile,但是meta-tile是可以公用的,不会占据额外的空间。
已经有人反编译出了可读的马里奥1代源代码(注意是可读的。简单地将FC的二进制数据反汇编成6502汇编码很容易,但那是不可读的)。从中可以看出,云和树丛使用的meta-tile不同,尽管它们的tile一致:
...... Palette0_MTiles: .db $24, $24, $24, $24 ;blank .db $27, $27, $27, $27 ;black metatile ;这里是树丛 .db $24, $24, $24, $35 ;bush left .db $36, $25, $37, $25 ;bush middle .db $24, $38, $24, $24 ;bush right .db $24, $30, $30, $26 ;mountain left .db $26, $26, $34, $26 ;mountain left bottom/middle center .db $24, $31, $24, $32 ;mountain middle top ...... Palette2_MTiles: ;这里是云,注意云有下半部分,树丛没有 .db $24, $24, $24, $35 ;cloud left .db $36, $25, $37, $25 ;cloud middle .db $24, $38, $24, $24 ;cloud right .db $24, $24, $39, $24 ;cloud bottom left .db $3a, $24, $3b, $24 ;cloud bottom middle .db $3c, $24, $24, $24 ;cloud bottom right .db $41, $26, $41, $26 ;water/lava top ......
至于为什么要分两个meta-tile,可能是因为需要使用不同调色板的原因。
这个回答不打算涉及更多的关于图像的方面,毕竟图像只有8KB(实际上还有几十个字节空余),而前面的程序代码有32KB,而且是一个字节也没有空余了(尽管中间还是有几个字节的多余代码)。而且,问题中提到了“32个关卡”,所以我打算主要说一下32个关卡对空间的占用。
32KB的代码当中,32个关卡占用了4647字节,约占总代码量的1/7。可能有人会很意外:32个内容丰富的关卡的数据,比游戏运行代码的数据量更少吗?事实上,马里奥1代的代码不算简单,光马里奥,就需要处理走、跑、蹲、转身、跳跃、游泳、顶砖、爬藤、发射火球、进水管(纵向和横向都有),还有与物体的互动,如踩怪、弹簧跳、与各种移动平台交互等。现代的游戏的这些细节都可以交给引擎来做,但FC时代并没有游戏引擎,所有的这些都需要自行处理。并且除了代码,还有音乐和文本,以及前面提到的meta-tile数据,都算在这32KB里了(尽管这些加起来也没有关卡数据多)。
怎样用4647字节描述出全部32个关卡(包括各种奖励区域在内)呢?我们以1-1举例。
马里奥1代的关卡,分为敌人和地形两部分,分开存储。1-1的敌人占用30字节,地形占用101字节(不含地下奖励区域,这个后面会提到)。
如果你玩《马里奥制造》,你可能会误以为马里奥1代的地图是一格一格存储的。但对于马里奥1代来说,连图像都要用tile、meta-tile、实际显示这样三级压缩,一格一格存储地图实在太过奢侈。
首先,我们发现整个地面都是2格高的,这意味着不需要把整个地形存储下来,只要存储“整个关卡都是2格高的地面”,就行了。马里奥1代设置了16种地形,这种2格高的地面就是其中一种,其他的还包括:没有地面(如1-3使用),下面2格高地面+天花板1格封死(如1-2、1-4使用)等等。16种地形,只占用半个字节:也就是说我们用半个字节就存储了整个1-1的地面。只是我们需要在地面上挖3个坑而已。
然后,我们关卡中的一个物体,其实只要2个字节:位置以及类型。
一个关卡这么长,怎么只用一个字节就能描述位置呢?我们注意到1代所有关卡都是1屏幕高的,而一个物体的大小是16x16,所以纵坐标只要16格就足够了(屏幕是240像素高,我们凑个整,用256像素)。而横向上,我们把每16格划分为一“页”。这样每一页都只有256个格子,刚好用1个字节就够了。
那么不同的页怎么办呢?我们可以在某个物体上标记一个“换页”。游戏读取到这个标记后,就表示在这以后的物体都是在下一页(或者下一页以后),不用在这一页加载这些物体了。这个标记只要1个bit就行了(只有“换页”和“不换页”两种),可以从物体类型的那个字节挤出来:毕竟马里奥1代不需要256种物体类型,去掉1比特后,剩下128种也足够了。
我们发现物体不会埋在地下,所以纵坐标有些位置是用不到的。这可以用来设置一些特殊物体:比如坑,它不需要纵坐标,我们就不需要浪费描述纵坐标的那半个字节,而那半个字节完全可以描述“坑的大小”。又比如,如果有一整页都没有物体,要怎么描述呢?我们也可以用一个特殊的“跳页”物体来描述。这个物体显然也不需要横坐标和纵坐标。特殊物体还有个好处:它可以不占用那128种物体的数量,因为它和普通物体是分开处理的。
而物体的类型,则还包括了物体的大小。比如关卡的中间部分一长排的横向砖,其实并不是很多个物体并排,而是一个“长度为8的横向砖块”。这样一来,128种物体还够用吗?不够。但没事,马里奥1代做了很多特殊处理,强行压缩到了128种不同的物体,比如:
还有各种各样节省关卡容量的特殊手段:
最后,这个关卡的最前面,还有两个字节,表示关卡的整体属性,比如:
关卡最后则是1个字节的结束标志。
敌人的设计也是类似的,这里就不详细讲了。除了固定放置的敌人,还有一种不停产生的敌人,比如2-3的飞鱼,5-3的炮弹等等。另外,水管里的食人花不需要专门设置:除了1-1,其他关卡每个水管里都有食人花。有时候没有食人花,是因为马里奥1代最多同时出现5个敌人(严格地说是除了马里奥以外的sprite),超出部分会被丢掉。
最后的最后,还有一点,就是关卡重用。比如奖励区域,很多关卡都会到相同的奖励区域(上述的1-1就有一个),这些区域其实也是重用的。还有一个更绝的关卡重用:1-2、2-2、4-2、7-2从地下或水下出来到地上,直到拉旗子的那一段,其实都是1-1的结尾。
有些关则是完全相同的,比如1-4和6-4,1-3和5-3等等,但是其中的敌人有所不同。但是没必要设置两套敌人,只要让一部分敌人在前面的那关不出现,在后面的那关出现就行了。马里奥1代有个分界线:5-3,所有这种相同的关卡中的敌人,都是区分在5-3之前出现,和在5-3之前不出现的。
总之,通过各种压缩手段,使马里奥1代的32个关卡的数据只占用了4647个字节。事实上游戏代码才是40KB中的大头。
首先,超级马里奥兄弟1(以下略做SMB1)的尺寸是40KB而不是64KB,32K的PRG(程序)和8K的CHR(图像)。
图像素材只有固定的几种“块”(Tile),地图可以进一步简化成表示了特定块组合(2x2)的二维数组,一格16x16像素。
1-1的尺寸只有212*13格,一格一个字节来算,也就是2756字节。但如果按照3k左右来算32个关卡容量肯定不够(光地图数据都有96KB了)。所以SMB1首先把对象做了抽象化,定义了一些“对象”,比如“砖块”、“管道”、“城堡”之类的,然后关卡数据仅保存这些“对象”的出现位置,一个对象占据2字节。连背景加敌人以及金币等数据,1-1的尺寸在131个字节,其他关卡基本也没有超过200个字节,这样一来32个关卡合计容量也就在7KB以内,外加几百个字节的字符和其他信息,剩下至少24KB可以用来存储程序代码。6502作为一个8位CPU,指令都不长,24KB可以作为代码来说是一个相当大的容量。
而FC的一个Tile(8x8像素)最多只能显示4种颜色,至于哪4种则可以自由选择(称作调色板),所以一个像素可以用2比特来表示,每8x8的图形占用16个字节。这个数据是不包含调色板信息的,调色板是程序动态指定的。虽说8KB的尺寸限制之下可以用的块只有512个,但是SMB1通过活用调色板也达到了多彩多样的图像。而且如上文所说,程序上把最基础的8x8像素的“块”抽象定义成了16x16像素的“块组合”,在每一关(也有可能是整个游戏)不超过128种块组合,并且每一关固定10种颜色组合成4种调色板,这样一个字节就可以代表一个块组合(2比特调色板+6比特块组合id),再进一步抽象定义“物件”,一个物件可以有多个块组合来构成。这样多层抽象的顶一下就可以大幅度节约内存,因为你的一个对象并不记录所有的块信息和他们的颜色。
于是,在这样的手法加持下,SMB1做到了40KB的限制下达到了极高的可玩性,提供了32个多彩多样的关卡。