原文位址：https://tzy1997.com/articles/contra128/
今天跟大家分享一下為什麼魂鬥羅隻有 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 位元組。我就寫了一個字，真的什麼都沒幹。
現實中常見的産品、流行的技術，實際上和時代背景密切相關。
當你抱着 15 寸筆記本還嫌小的時候，1990 年代初的家庭，可是一家人圍着 14~18 寸的球面電視看的。把雪碧拿給古代人喝一口，估計他會齁得要死，必須喝點水壓壓驚。
當物質基礎變得十分豐富的時候，一定會産生無法避免的“浪費”，這種“浪費”會進一步改變人感受的門檻值，對度量的估計都變得紊亂了。
FC時代的圖形技術
由于早期的記憶晶片（ROM）非常貴，而且大容量磁盤的技術也不成熟，是以暫且不論硬體計算能力，僅僅是想增加遊戲的總容量也非常困難。是以自然會使用符合當時水準的資料結構。
以紅白機 FC 為例，它的分辨率為 256x240。分辨率不算低，但卻隻有 2KB 顯存，而且還要實作全屏卷軸效果。是以在 FC 設計之初，從硬體上就提供了充分利用顯存的方法——使用 Tile（瓦片)。
對每一個場景來說，使用若幹數量的瓦片，場景用有限的瓦片拼接即可。這種“二級”表示方法能極大節約存儲量。
具體一些原理講解可以看一些科普，比如這個：【萌新圖形學】TileMap瓦片地圖簡介，以及它的優化原理_哔哩哔哩_bilibili
音頻容量和代碼容量
現代音樂格式往往直接儲存聲道的波形，這種做法保真度高、通用性強，但很顯然占用空間多，一首曲子的容量以千位元組、兆位元組計算。
而八位晶片時代的音頻解決方案，關鍵是一顆專用晶片，例如 FC 用的理光 2A03：
音頻晶片可以産生合成音效，能提供的音色可以在一定程度上配置，但非常有限。聽聽 FC 遊戲的音樂可以體會到常用的音色幾乎一樣。
我覺得這個音頻晶片最厲害的地方是可以同時播放幾個音軌（但不能是和弦那種“同時”），《魂鬥羅》、《沙羅曼蛇》、《忍者龍劍傳》的殿堂級音樂，主要是靠多個音軌的交替配合實作的。
每個音符隻要記錄音色、頻率和音高就足夠了，音頻晶片自然會識别出來。把音符按時間排列好就是“樂譜”了，可以簡單了解為“簡譜”。
這種簡譜需要的資料量十分有限，而且大部分遊戲音樂都是循環播放，資料量更是小的可憐。
代碼也是類似的。
FC 時代的遊戲，沒有所謂的“引擎層”，或者說引擎層就是“硬體層”。任天堂的主機完全是為遊戲而設計的，瓦片、調色闆、音樂、音效等基本功能已經預先考慮到了，這樣一來就節約了大量底層代碼。