點選上方 「 Linux開源社群 」，選擇「 設為星標 」
優質文章，及時送達
作者：皮皮關 原文連結：https://www.zhihu.com/question/50076174/answer/1101330430
經常看到有同學在抱怨現在的遊戲、APP占用非常大的空間，基本都是 10G 起步。
這讓 我想 到小時候玩過的一款遊戲 魂鬥羅 ，為什麽它只有 128KB 卻可以實作那麽長的劇情呢？
這篇文章將會給大家講講這裏面的奧秘~
# 正文
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（瓦片）。
對每一個場景來說，使用若幹數量的瓦片，場景用有限的瓦片拼接即可。這種「二級」表示方法能極大節約儲存量。
具體一些原理講解可以看一些科普，比如這個：
https://www.bilibili.com/video/BV19J411e763
# 音訊容量和程式碼容量
現代音樂格式往往直接保存聲道的波形，這種做法保真度高、通用性強，但很顯然占用空間多，一首曲子的容量以千字節、兆字節計算。微信搜尋公眾號：架構師指南，回復：架構師 領取資料 。
而八位芯片時代的音訊解決方案，關鍵是一顆專用芯片，例如 FC 用的理光 2A03：
我覺得這個音訊芯片最厲害的地方是可以同時播放幾個音軌（但不能是和弦那種「同時」），【魂鬥羅】、【沙羅曼蛇】、【忍者龍劍傳】的殿堂級音樂，主要是靠多個音軌的交替配合實作的。
每個音符只要記錄音色、頻率和音高就足夠了，音訊芯片自然會辨識出來。把音符按時間排列好就是「樂譜」了，可以簡單理解為「簡譜」。
這種簡譜需要的數據量十分有限，而且大部份遊戲音樂都是迴圈播放，數據量更是小的可憐。
# 程式碼也是類似的
FC 時代的遊戲，沒有所謂的「引擎層」，或者說引擎層就是「硬體層」。任天堂的主機完全是為遊戲而設計的，瓦片、調色盤、音樂、音效等基本功能已經預先考慮到了，這樣一來就節約了大量底層程式碼。
程式設計師要仔細研究文件，在硬體框架下思考問題，比如如何顯示圖片、如何卷動螢幕等等；而且還要非常熟悉硬體底層和組譯，不要浪費程式碼空間。
一來二去，程式碼也能寫的非常小。
總的來說，128KB 的遊戲大作，在 30 年前稀松平常，放到現在簡直就是黑科技。
-End-
讀到這裏說明你喜歡本公眾號的文章，歡迎 置頂（標星）本公眾號 Linux技術迷，這樣就可以第一時間獲取推播了~
在本公眾號，後台回復：Linux，領取2T學習資料 ！
推薦閱讀
1.
2.
3.
4.
