→ sarzty: .kkrieger? 不過這款約96KB 07/31 19:08
→ gasbomb: 應該就是樓上說的那款了 當年是96kb遊戲比賽的冠軍 07/31 19:45
→ gasbomb: google "64k intro"可以找到很多很嚇人的東西 07/31 19:46
推 c8c8c8c8c8c8: 這96K太扯...... 07/31 23:42
推 holyhelm: 為什麼可以這麼猛啊..... 08/01 01:14
推 skyhawkptt: 聽說完全用組合語言去寫...XD 08/01 01:30
推 skyhawkptt: 再加上強力壓縮及演算法 08/01 01:34
→ playerlin: 但是作者當初說要做三個關卡，卻從未完成。 08/01 01:52
→ playerlin: 現在留下來的也只有引擎原始碼跟這個demo(還有官網上 08/01 01:53
→ playerlin: 其他的，但是就沒有任何關於這款的後續了) 08/01 01:53
→ playerlin: 作者的FAQ寫到並沒有壓縮，而是直接以製作模型和材質的 08/01 01:58
→ playerlin: 過程方式變成數據存在執行檔中，執行時再"製作"出來( 08/01 02:00
→ playerlin: 所以一開始的loading條就是將遊戲的所有資料生成出來) 08/01 02:01
→ playerlin: 因為只儲存最原始的"製作步驟"，所以能將容量壓得很低 08/01 02:01
→ playerlin: 簡單說就是有個模型材質聲音生成器在遊戲執行時開始製 08/01 02:04
→ playerlin: 作出來，遊戲程式中只儲存生成器需要的參數資料。 08/01 02:05
推 ailio: 其實現在新遊戲很多過場都用即時演算來省空間算是一樣概念 08/01 10:21
→ ailio: 不過以前的資源跟效能，這樣搞真的是很厲害 08/01 10:21
推 wyiwyi: 當時玩過 超卡XD 08/01 13:49
→ xiue: 現在的遊戲容量都不知道在大幾點的,還是有好遊戲沒錯,但根本 08/01 14:15
→ xiue: 不覺得這樣的內容需要10幾20GB去做. 08/01 14:16
→ bnn: 啊就一堆人要畫面要影音然後木耳低解析螢幕根本浪費空間XD 08/01 19:15
推 playerlin: 高解析度材質跟高品質音效，這兩個東西都是肥大保證。 08/01 23:48
→ playerlin: 即時算就是要用時間(載入長)換空間(容量小)。 08/01 23:49
→ playerlin: 但是如果要載入快一點(先不論優化問題)，需要演算的直 08/01 23:49
→ playerlin: 接就能使用(載入快些)但是容量很大很大(如BMP、WAV) 08/01 23:51
→ playerlin: 但是解析度越來越高，就算再好的演算法也是有極限的 08/01 23:51
→ playerlin: 你不可能希望4K解析度卻只要幾個MB就能搞定吧(光單格純 08/01 23:54
→ playerlin: 總像素就7、8百萬，全彩x3，32位色深x4，多肥阿) 08/01 23:55
→ playerlin: 最後還是都得靠演算法來降低容量，然後就是看演算法跟 08/01 23:57
→ playerlin: 程式本身優化來看能節省多少時間... 08/01 23:57
→ playerlin: 但是如果想要1080p以上甚至4K等級，又想容量小？那就 08/01 23:58
→ playerlin: 只能降低色彩數了。 08/01 23:58
→ playerlin: 不過聲音的話，就不一定了，因為使用者的發聲裝置品質 08/01 23:59
→ playerlin: 會影響，但一般來說，MP3那種規格的其實很多人就已經 08/02 00:00
→ playerlin: 聽不出差別，但也是有人聽得出來那差異。 08/02 00:01
→ playerlin: 而且又有如ogg這類的規格，聲音容量肥大的程度不會比畫 08/02 00:02
→ playerlin: 面品質大就是。除非你不追求高解析度，不然遊戲的容量 08/02 00:02
→ playerlin: 越來越大應該是正常的(除非以後有那種劃時代的格式可以 08/02 00:02
→ playerlin: 大幅減少超高解析度的容量) 08/02 00:02