為什麼魂鬥羅只有128KB卻可以實現那麼長的劇情?

大資料文摘發表於2020-04-20

為什麼魂鬥羅只有128KB卻可以實現那麼長的劇情?

大資料文摘授權轉載自知乎

作者:皮皮關


現代程式設計師A和1980年代遊戲程式設計師B的對話:

A:為什麼你用128KB能實現這麼多畫面、音樂、動畫?

B:128KB還不夠麼?其實為了表現力已經相當奢侈了,加了很多不重要的細節。

A:就說你們的音樂,這個音樂,我壓到最低位元速率的mp3,也得至少1MB吧。

B:你怎麼壓的?一首背景音樂怎麼可能超過1KB。

A:那你實現全屏卷軸,用了多少視訊記憶體?

B:一共就只有2KB視訊記憶體,多了也放不下啊。

A:……


我們對“資料量”無法直觀認識


除非是專家,一般人根本無法估算到底多大算大,多小算小。


一般人對“資料量”並沒什麼概念。一篇800字的作文有多少資料量?按照GBK編碼,約1.6KB,按照UTF-8編碼,則是2.4KB。


只寫了1個字的作文,按理來說1位元組~3位元組就夠了。但只寫1個字的word文件,有10956位元組【汗】。而由於硬碟格式化要求,再多佔用1332位元組【再汗】。


為什麼魂鬥羅只有128KB卻可以實現那麼長的劇情?

我就寫了一個字,真的什麼都沒幹


現實中常見的產品、流行的技術,實際上和時代背景密切相關。


當你抱著15寸筆記本還嫌小的時候,1990年代初的家庭,可是一家人圍著14~18寸的球面電視看的。把雪碧拿給古代人喝一口,估計他會齁得要死,必須喝點水壓壓驚。


當物質基礎變得十分豐富的時候,一定會產生無法避免的“浪費”,這種“浪費”會進一步改變人感受的閾值,對度量的估計都變得紊亂了。


FC時代的圖形技術


由於早期的記憶晶片(ROM)非常貴,而且大容量磁碟的技術也不成熟,所以暫且不論硬體計算能力,僅僅是想增加遊戲的總容量也非常困難。所以自然會使用符合當時水平的資料結構。


以紅白機FC為例,它的解析度為256x240。解析度不算低,但卻只有2KB視訊記憶體,而且還要實現全屏卷軸效果。所以在FC設計之初,從硬體上就提供了充分利用視訊記憶體的方法——使用Tile(瓦片)。


對每一個場景來說,使用若干數量的瓦片,場景用有限的瓦片拼接即可。這種“二級”表示方法能極大節約儲存量。具體一些原理講解可以看一些科普,比如這個:


為什麼魂鬥羅只有128KB卻可以實現那麼長的劇情?

B站指路:


音訊容量和程式碼容量


現代音樂格式往往直接儲存聲道的波形,這種做法保真度高、通用性強,但很顯然佔用空間多,一首曲子的容量以千位元組、兆位元組計算。

而八位晶片時代的音訊解決方案,關鍵是一顆專用晶片,例如FC用的理光2A03:


為什麼魂鬥羅只有128KB卻可以實現那麼長的劇情?

下:理光2A03


音訊晶片可以產生合成音效,能提供的音色可以在一定程度上配置,但非常有限。聽聽FC遊戲的音樂可以體會到常用的音色幾乎一樣。我覺得這個音訊晶片最厲害的地方是可以同時播放幾個音軌(但不能是和絃那種“同時”),《魂鬥羅》、《沙羅曼蛇》、《忍者龍劍傳》的殿堂級音樂,主要是靠多個音軌的交替配合實現的。

每個音符只要記錄音色、頻率和音高就足夠了,音訊晶片自然會識別出來。把音符按時間排列好就是“樂譜”了,可以簡單理解為“簡譜”。這種簡譜需要的資料量十分有限,而且大部分遊戲音樂都是迴圈播放,資料量更是小的可憐。

程式碼也是類似的。

FC時代的遊戲,沒有所謂的“引擎層”,或者說引擎層就是“硬體層”。任天堂的主機完全是為遊戲而設計的,瓦片、調色盤、音樂、音效等基本功能已經預先考慮到了,這樣一來就節約了大量底層程式碼。

程式設計師要仔細研究文件,在硬體框架下思考問題,比如如何顯示圖片、如何捲動螢幕等等;而且還要非常熟悉硬體底層和彙編,不要浪費程式碼空間。

一來二去,程式碼也能寫的非常小。

總的來說,128KB的遊戲大作,在30年前稀鬆平常,放到現在簡直就是黑科技。科技的劇烈變革帶來技術指標非線性的變化,讓我們的記憶和直覺徹底落伍 :)

知乎原文地址:



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31562039/viewspace-2687107/,如需轉載,請註明出處,否則將追究法律責任。

相關文章