百科问答小站 logo
百科问答小站 font logo



为什么有32个关卡的游戏《超级马里奥兄弟》只要40KB? 第1页

  

user avatar   levelpp_edu 网友的相关建议: 
      

早期红白机的经典游戏容量出乎意料的小。

这个问题曾经在知乎上引起过热烈的讨论,B站、微信上都有相关的热门视频。相关资料我会整理到答案的末尾,以供参考。

经过一段时间的广泛讨论,这一问题逐渐变得更加清楚了。感谢Anjie的邀请,再将这个问题整理一遍做出回答,对一些有价值的信息做个总结 :)

1、核心压缩方法——Tile(瓦片)

首先,实际上初代《超级马力欧兄弟》只有40KB。

我们先别急着惊讶,先问一个问题:无论40KB还是400KB,它一定有一种基本的压缩方法,这个压缩方法与我们今天保存图片的方式肯定从根本上就有区别。

红白机的基本图像单元为“Tile瓦片”,每个瓦片为8x8像素大小。与现代游戏直接绘制像素的思路不同,红白机上的游戏必须先准备好一系列瓦片,再把瓦片拼在一起形成画面。

为什么要这么做呢?通过简单的数学运算可以知道,先做一些瓦片再拼接瓦片,内存占用量要远远低于直接绘制每一个像素。

例如:一张128*128像素的图片,每个像素可以选2^8=256种颜色,那么每个像素需要记录8bit=1Byte信息,共占用空间16KB。(128*128*1 Byte)

而如果换成8x8的瓦片去铺满图片,则只需要 16 * 16 = 256个瓦片就够了,如果总共只有256种不同样式的瓦片,那么只需要256B 即可表示这张图片。

简单来说:用重复出现的模式拼成一幅画面,可以极大压缩图片占用的空间

但这里留下了一个问题:256种瓦片本身也要占用空间,瓦片本身如何存储?

2、FC如何保存色彩数据

FC虽然画质简陋,但色彩还是相当鲜艳的。在当时的技术条件下,FC理论上可以表示50多种颜色,一个像素的颜色可以用6bit表示。而一个瓦片有8x8 = 256个像素,那么就需要 8x8x6 bit = 48 Byte 来表示一个瓦片。

这么算起来就出问题了~~ 256种瓦片,每个瓦片 48 Byte,瓦片容量等于256*48 B = 16384 B。好家伙,什么都没干,光瓦片就存了16KB,显然太多了。

解决这一矛盾的核心,是另一个问题:FC如何保存颜色数据?

通过 @文礼 大神的回答可以知道(文礼 的回答),每个瓦片只能绑定一个调色板,而每个调色板只有4种颜色,所以每个瓦片的容量占用仅有 8x8x2bit = 16Byte,比上述估算的少4倍

而且,调色板带来另一个有趣的功能,考虑下面几个图片:

外观完全一样有没有?

上图中不同的图片仅仅是颜色不同,并不需要创建新的瓦片,只需要给同一个瓦片替换不同的“调色板”即可。这样可以巧妙利用调色板,创建出不同皮肤的物体,而容量几乎没有增加。

3、FC如何保存音乐数据

现代音乐格式往往直接保存声道的波形,这种做法保真度高、通用性强,但很显然占用空间多,一首曲子的容量以兆字节计算。

而八位芯片时代的音频解决方案,关键是一颗专用芯片,例如FC用的理光2A03:

音频芯片可以产生合成音效,能提供的音色可以在一定程度上配置,但非常有限。听听FC游戏的音乐可以体会到常用的音色几乎一样。我觉得这个音频芯片最厉害的地方是可以同时播放几个音轨(但不能是和弦那种“同时”),《魂斗罗》、《沙罗曼蛇》、《忍者龙剑传》的殿堂级音乐,主要是靠多个音轨的交替配合实现的。

每个音符只要记录音色、频率和音高就足够了,音频芯片会识别出来。把音符按时间排列好就是“乐谱”了,可以简单理解为“简谱”。这种简谱需要的数据量十分有限,而且大部分游戏音乐都是循环播放,数据量更是小的可怜。

当时的芯片擅长产生的波形包括方波、三角波、正弦波等等,其中三角波用来做Bass效果很好。而《超级马力欧兄弟》里面的“鼓”是用“噪波”实现的,也是当年的常用做法。

FC的音频芯片还支持短时间的采样音乐,后期的《忍者龙剑传3》BGM里面的鼓声采用了8Bit采样声音, 效果超棒。

4、FC的程序代码容量

有趣的是,现在绝大多数人都忽略了程序代码本身所占用的空间。但在那个内存容量极其有限的年代,代码的体积不可小觑。

FC时代的游戏虽然逻辑不可谓不丰富,但确实整体代码不大。为什么呢?

因为FC时代的游戏,没有所谓的“引擎层”,FC的硬件本身就是一个非常简陋的游戏引擎。任天堂的主机完全是为游戏而设计的,瓦片、调色板、音乐、音效等基本功能已经预先考虑到了,使用特定的方式就能直接调用,这样一来就节约了大量底层代码。

程序员要仔细研究文档,在硬件框架下思考问题,比如如何显示图片、如何卷动屏幕等等;而且还要非常熟悉硬件底层和汇编,不要浪费代码空间。

一来二去,代码也能写的非常小。

5、其它优化机制

为了极限压榨容量,当年的程序员和美术也动了不少脑筋,比如几个经典案例:

这些细节的优化,也对压缩大小起到了一定作用。但总的来说,并不是让容量变小的主力~~~

总结

以上分5个部分,详细介绍了FC游戏容量小的原因,特别是背后的本质原理。

以上内容参考了很多内容,包括不限于wiki、知乎、B站等渠道。有错误的地方不吝赐教~~

参考资料:

  1. 知乎问题:为什么魂斗罗只有128KB却可以实现那么长的剧情?
  2. B站:【差评君】为什么有32个关卡的超级马里奥兄弟只要40KB?_哔哩哔哩 (゜-゜)つロ 干杯~-bilibili
  3. wiki:en.wikipedia.org/wiki/S.

还有其它很多参考,不好一一列举,向这些作者表示感谢。


user avatar   kseptuple 网友的相关建议: 
      

首先,为什么是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种不同的物体,比如:

  • 炮台和蘑菇平台,其实是同一种物体,只是在不同风格的关卡中显示不同而已。
  • 地面和地下场景可以顶碎的砖块,在水下会变成不可顶碎的紫色珊瑚,它们也是同一种物体。
  • 有些地方有一长排的?砖块,但这种砖块是特殊物体,不能设定它的纵坐标。它只能在2种特定的纵坐标出现。作为特殊物体,它不占用128种物体的数量。
  • 水管只有“可进入”和“不可进入”两种,最高高度是8,所以水管物体只有16种。至于水管会通向哪里,则不是和物体存储在一起,而是和敌人的数据存储在一起的:游戏读取了目标位置后,所有水管和藤蔓都会把你传送到那个目标位置,直到游戏读取下一个目标位置或者进入下一关为止。(这也是马里奥1代速通当中,4-2进水管却到了爬藤蔓到达的跳关区域的原理。)
  • 很多不需要纵坐标的物体也是特殊物体。如库巴的桥、斧头、旗杆、城堡等等。

还有各种各样节省关卡容量的特殊手段:

  • 1-1后半段出现了2个4格高的台阶,这种台阶也是特殊物体,不是用4个物体拼起来的。旗杆前的8格台阶+右侧多一列的组合也是一整个特殊物体。
  • 1-2有大量复杂的砖块,但是他们并非是很多砖块物体拼接而成的,而是不停地在16个地形之间切换。
  • 1-1一开头有个“砖-蘑菇砖-砖-金币砖-砖”的设计,这里不是5个物体,而是一个5格长的横向砖,叠上2个?砖,总共3个物体。

最后,这个关卡的最前面,还有两个字节,表示关卡的整体属性,比如:

  • 关卡一开始,是16种地形中的哪一种?(就是上面提到的半个字节)
  • 关卡是什么类型的?(地面,地下,水下,城堡)
  • 关卡有多少时间?(400、300、200)
  • 关卡的背景是什么?(1-1是山丘和树丛,1-3是天空,而1-2的地下部分则什么都没有)
  • 关卡是什么风格的?(比如第5世界其实是下雪的世界,第3世界是黑夜等等。还有上面提到的,关卡中到底是炮台还是蘑菇平台?)

关卡最后则是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中的大头。


user avatar   pig_10 网友的相关建议: 
      

首先,超级马里奥兄弟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个多彩多样的关卡。




  

相关话题

  为什么很多中国人玩不起正版游戏? 
  如何评价明日方舟水月二创与原神可莉18+图事件? 
  云游戏什么时候会成为主流? 
  腾讯在游戏方面真的是一家毫无情怀的公司吗? 
  为什么在科幻动漫和科幻游戏中上阵战斗的都是十几岁的孩子而不是更有经验的军队士兵呢? 
  怎样评价"游戏退化"的观点? 
  《精灵宝可梦》中先有雷电球还是先有精灵球? 
  如何评价戒色吧频繁举报各类资源的行为? 
  当算力发展到一定程度,游戏是否可以突破“多边形”的框架,进而模拟粒子,从而达到复刻现实的程度? 
  《隐形守护者》里有哪些细思极恐的地方? 

前一个讨论
如何看待 Clearlove 宣布复出后的首个赛季一次未能登场?他复出的意义是什么?
下一个讨论
女朋友经常抱怨我和我爸妈穷怎么办?老拿我和别人比得我一无是处,我怎么控制自己不发火吵架呢?





© 2024-11-08 - tinynew.org. All Rights Reserved.
© 2024-11-08 - tinynew.org. 保留所有权利