[CK3 ] 唯主之意 開發日誌 #6：效能
原文網址：https://reurl.cc/OQml93
《普天之下》更新推出時，我們曾在《開發日誌 #187：效能與優化》中分享當時的效能優化成果。
當時我們也談到了一些對《十字軍之王 III》未來的期望與構想，
而現在，隨著《唯主之意》更新即將到來，這篇開發日誌正好可以讓我們盤點一下目前的進展。
大家好，又見面了，我是 Carl-Henrik，《十字軍之王 III》團隊的首席程式設計師。
在《普天之下》推出前後，我曾提到我們接下來打算加快載入畫面的速度，並改善其他幾套系統。
這正是本篇開發日誌要談的內容，此外也會介紹遊戲每日模擬效能目前的進展，以及遊玩過程中遊戲會占用多少記憶體。
本文發布時距離《唯主之意》正式推出還有幾週，而我們仍在努力進一步改善這些系統。
在這段期間任何事情都有可能發生，因此請先做好最終數據可能有所不同的心理準備，不過以下就是目前的實際狀況。
開門見山
如果你只想看摘要：
*模擬速度：我們的目標，是讓每日模擬效能與先前改善遊戲體驗的 1.19.0「Scribe」版本相當。
目前已經相當接近，我們預期最終也能落在差不多的水準。
*遊戲在啟動時需要預先載入的內容大幅減少。
以我們的低效能測試機為例，改為串流載入網格（meshes）與插圖，
而不是在啟動時一次全部載入後，進入主選單所需時間大幅縮短。
以我的電腦來說，從 84 秒降至 16 秒。
*在相同場景下，顯示記憶體的使用量也大幅降低，依你的材質品質設定而異，大約減少三分之一至一半。
*遊戲進行十年後，系統記憶體的使用量大約減少六分之一。
以下則是較完整的長篇版本。
效能測量
要掌握目前的效能，確認優化是否有效，就得有可靠的測量方式。
我們會讓遊戲運行一百年，計算模擬一天的平均耗時，藉此衡量模擬速度。
為了統一測試條件，每次都從 1066 年開始，至少運行到 1166 年。
有時也會讓遊戲跑上一整晚，觀察後期的表現，畢竟隨著遊戲推進，需要更新的內容也會越來越多。
每次測試的隨機種子不同，開發團隊也整天都在修改遊戲，因此測得的數據難免有所差異。
我們分析時也會把這些波動納入考量。
https://meee.com.tw/ry6KMLR
［「優化前」的效能分析畫面：目前正式版本從啟動到進入主選單，共耗時 84 秒］
每次測量每日模擬效能時，我們也會一併記錄啟動時間。
我們發現，如果你想早點進入遊戲開始玩，Linux 的表現可比 Windows 好得多！
模擬速度
那麼，遊戲裡的一天究竟要跑多久？
我們使用的基準測試機規格相當低，配備的是 2012 年的八核心 CPU 和 16 GB 記憶體。
即使到了遊戲後期，跑完一天也只需要不到一秒。
大多數日子的耗時都低於平均，只有少數日子會明顯拉長。
這些通常是有大事發生的日子，玩家感受到的會是突然頓一下，而不是遊戲一直跑得很慢。
隨著遊戲中的年代推進，運算量也會增加。
到了 1160 年代，模擬一天的平均耗時會是 1070 年代的一倍半多一點。
這些時間都花在哪裡？以一百年的測試來看，大致分配如下：
*AI 思考行動，占每日運算時間的四分之一多一點。
*平行執行的預更新階段，各系統會計算接下來要做哪些變更，約占四分之一。
*依序執行的更新階段，負責實際套用這些變更，約占五分之一。
*觸發事件，則占十分之一多一點。
《唯主之意》的目標，是讓每日模擬速度達到先前改善遊戲體驗的「Scribe」版水準。
寫下這篇文章時，我們已經相當接近這個目標，讓我有信心在這裡向大家說明。
不過，我們暫時不會公布具體數字，因為正式推出前的最後幾週，數字隨時都可能上上下下。
https://meee.com.tw/kg2WFmy
［一百年間，各類運算的每日平均耗時］
每天的運算依序分為預更新、更新及 AI 更新。
在預更新階段，角色與修正效果占了最大的比重，
這也不意外，畢竟你操控的、與你交手的都是這些角色！
至於 AI 更新，最耗時的是評估 角色互動，這也是本次開發過程中耗時增加最多的項目：
七月短短幾週內，我們加入了大量與教會有關的互動內容，而每新增一項互動，就代表每個角色每個月都得多考慮一件事。
這些互動本身就是新功能，當然不能刪掉，所以我們轉而設法減少每次評估所需的運算量。
設計與腳本團隊一直在處理這部分，也取得了不錯的成果。
能靠刪除程式碼來改善效能，感覺真是太棒了！
以資助大型工程為例，原本的程式會檢查，讓伯爵每隔幾個月才考慮一次是否出資。
這個用意是對的，問題在於，遊戲會先算完「這位統治者有沒有能力資助其中任何一項工程」，才檢查「這個月到底該不該考慮這件事」。
光是刪掉前面的資助能力檢查，整個流程的耗時就降到了原本的四分之一，而且這項改善很容易就能驗證。
一個問了八十萬次的問題
效能測試留下的詳細紀錄，讓我們能找出一些有趣的情況：
某些操作雖然執行得很快，次數卻多得驚人。
比較兩份只隔了幾天的測試紀錄時，我們發現角色管理系統明顯變慢了，卻看不出原因。
最後查出，問題出在一個檢查統治者能否保留某項領國法律的函式。
在「Scribe」版本中，這項檢查每個月大約執行一千五百次；到了新版本，卻變成每個月約八十五萬次。
函式本身並沒有問題，只是某次腳本修改把它移到了執行頻率高得多的位置。
光看修改內容很難察覺，因為程式碼看起來相當合理。
當我們把問題鎖定在某一次修改紀錄後，腳本團隊便有了明確線索，可以重新調整結構，讓這部分的耗時降到每日模擬總耗時的百分之幾。
光是這個例子，就足以證明持續測量的工夫沒有白費，不能等到最後才測：
兩天內發現問題，和兩個月後才發現，差別就在於，
過了兩個月，大家早已把這種狀況當成常態，也沒人記得它是怎麼來的了。
把問題問得更簡單
我們經常發現，程式為了做出一個判斷，進行了遠超過實際需要的運算。
最明顯的例子，是新教會內容中經常用到的一項檢查：某位統治者是否位於這個教區內？
為了回答這個問題，遊戲會先列出區內所有統治者，排序、刪除重複項目，
再把整理好的名單交回呼叫端，最後由呼叫端確認它要找的那位統治者是否在名單上。
整套流程完全正確，卻全是多此一舉。
改成直接判斷「這位統治者在不在這個教區內」，只回答是或否，運算成本便降到了原本的十分之一以下。
比較兩個信仰時，也出現了類似的情況。
遊戲原本會把兩個信仰的教義整理成表，再逐項查找差異；
改成只為其中一個信仰建表，再拿另一個信仰的教義逐項比對，就能完成同樣的工作，速度還快了約三分之一。
這兩種做法都沒有什麼巧妙之處，只是少做了一些事而已。
避免當機的代價
接下來這個例子，有趣的地方在於：這筆運算成本當初為什麼會存在？
遊戲中的物件會互相參照，例如角色會指向自己的領主，頭銜會指向持有者。
而遊戲當機的一個常見原因，就是沿著參照去存取一個已經被刪除的物件。
為了避免玩家的遊戲因此當機，每個物件都帶著一枚小小的識別戳記，我們稱之為「nullobject」。
要確認參照是否仍然有效，就得檢查這枚戳記是否完好。這項檢查的執行次數極其龐大。
原本的寫法，要求電腦先查出眼前是哪一類物件，才能進行檢查。
我們省去了這道間接查詢，檢查的內容和結果都一樣，只是不必先「問路」了。
光是這項改動，就在完整的一百年測試中省下了約 3% 的總運算時間。
這是本次開發中成效較大的單項優化之一，而且完全沒有改變遊戲的任何運作行為。
修好一處，卻付出另一種代價
前陣子，為了修復一個當機問題，我們把每個模擬刻（tick）清除角色臨時修正效果（modifiers）的工作，
從平行執行的部分移出，改由單一執行緒處理。
這是很合理的處理方式，也確實解決了當機。
但它也悄悄犧牲了約 4% 的整體效能：這項清理工作本身非常輕量，卻只能交給一條 CPU 執行緒完成。
這項工作無法平行執行的根本原因，在於它使用的記憶體配置器無法安全地讓多個執行緒同時呼叫。
我們修正了這個問題，並改為重複利用物件，省去反覆刪除與重建的步驟，讓清理工作能重新平行執行，也不再引發當機。這讓每日模擬中這部分的耗時縮短了將近一半。
這次的教訓是，修復當機後，也得檢查是否影響效能。畢竟這類修復通常有時間壓力，當下能解決問題的做法，未必就是最好的做法。
處理這部分時，我還發現角色記憶、宗族、好感度等幾處，都會從很長的清單中逐筆刪除大量項目，
而每刪除一筆，後面的所有項目就得往前挪一格。
改成一次掃過清單、統一刪除，只需要花一個下午。
這種小修改在圖表上看不出來，卻能從此省下這些多餘的運算。
看到哪裡，就載入哪裡
我之前說過會先從載入畫面著手，而這次效能改善的重頭戲，就是遊戲不再等所有東西都載入完畢，才讓你開始玩。
過去，遊戲啟動時會載入、建立所有 3D 模型，並傳送到顯示卡上，不管你接下來會不會看到它們。
現在，模型會等到第一次真正需要時才載入；只有在需要騰出空間，而且它已經有一陣子沒出現在畫面上時，才會被移出記憶體。
所以，各位唯我論者可以高興了：
我們現在確保遊戲能準確模擬這個世界正確的形上學原理，讓物體恆存性保證，東西只要離開視線，就不再存在（於記憶體中）。; )
這是本次更新中，對載入時間影響最大的一項改動。
在我們的低效能測試機上，串流載入讓進入主選單的時間縮短了約三分之二。
換個角度看，遊戲啟動時建立的材質數量，現在大約只有過去的三分之一，其餘的會留待之後真正需要時才建立，有些甚至從頭到尾都用不到。
https://meee.com.tw/B4YDtwW
［網格串流載入除錯工具：顯示目前載入了哪些模型，以及距離上次繪製經過了多久。此工具僅供遊戲內部版本使用。］
不過，串流載入圖像資源可能會讓物件突然冒出來，也就是視線移過去後，東西才晚一步出現。
我們從兩方面處理這個問題。
首先，只要顯示記憶體還有餘裕，模型就會繼續留在記憶體裡，不再像以前那樣，不管顯示卡還剩多少空間，時間一到就移除。
一般遊玩時，這部分的用量會穩定在遠低於現代顯示卡可容納的範圍，
也讓那些隨著畫面捲動、反覆進出視野的資源，不必每次都重新建立。
其次，在王座廳等場景，我們會確保資源都準備好了，才將畫面顯示出來。
插圖隨需載入
材質方面，我們也採取了相同做法，只是切入點不同。
《十字軍之王 III》有大量的二維美術資源，包括事件插圖、寶物圖示、人物肖像的細節遮罩。
過去，不管這些圖像有沒有出現過，都會在整個遊玩過程中常駐顯示記憶體。
插圖串流載入則會等到需要時才載入，並在停止顯示後不久將它們移除。
事件圖片只會在你閱讀事件時出現在畫面上，因此也只需要在這段時間留在記憶體裡。
https://meee.com.tw/9feg5Gn
［我們新增的顯示記憶體視覺化檢視工具，用來追查各項資源的用量］
光是以下兩個例子，就值得我們花這番工夫。
過去，所有寶物圖示都會載入顯示記憶體，並不是因為需要顯示，而是為了在缺少圖示時，把錯誤寫進紀錄。
其實，只要檢查檔案是否存在，就能回報完全相同的錯誤，而且幾乎不費什麼運算。
另一個例子是人物肖像的圖案遮罩，這些用來呈現服裝與紋章細節的原始美術資源，總量接近 1 GB，
現在也改為隨需串流載入，不再永久常駐記憶體。
顯示記憶體
這正是某些硬體配置下，許多難以查明原因的效能下降，甚至當機問題的根源。
資料片「普天之下」推出後，我們持續加入新的資源，而這些資源全都會在啟動時預先載入。
遊戲規模隨著每次更新擴大，內容自然也越來越多，
但預先載入就代表，不管這些內容有沒有出現在畫面上，顯示卡都得承擔這份負擔。
一旦超過某個臨界點，顯示記憶體不足以滿足遊戲需求，顯示卡就得在繪製每一幀時，透過匯流排來回搬運資料。
到了這個地步，效能就不是逐漸變差，而是直接跌落谷底。
在低階電腦上，幀率會因此掉到個位數，有時甚至會毫無預警地閃退回桌面。這根本沒辦法正常遊玩。
這正是兩套串流載入系統所解決的問題，也是它們比本篇日誌中任何單項優化都更重要的原因。
在相同場景下，比較啟用與停用這兩套系統的結果，顯示記憶體用量可減少三分之一至一半，
而且不論材質品質設定為何，都能維持這樣的減幅。
節省空間的關鍵，其實不在材質解析度，而在於有多少遊戲內容同時常駐記憶體。
不管選擇哪種品質設定，涉及的內容數量都差不多。
這也意味著，改善最明顯的，恰好就是最需要它的電腦：
顯示記憶體原本就有餘裕的機器受益有限，已經用盡空間的機器才會感受到最大的差別。
事實上，中等與低品質材質的顯示記憶體用量，似乎沒有什麼差別。歡迎大家試著調整圖形設定，告訴我們你的感受。
繪製目標
繪製目標（Render Targets）是顯示記憶體中預留給繪圖使用的空間，
例如靜態肖像或螢幕畫面的幀緩衝區。
除了串流載入之外，我們也能從這裡著手，減少顯示記憶體用量。
遊戲繪製一幀畫面時，會用到一組涵蓋全螢幕的緩衝區，分
別處理場景本身、環境光遮蔽，以及各種模糊與後製效果。
這些緩衝區原本全都採用高精度格式，每個像素儲存四個 16 位元浮點數。
在高解析度下再加上反鋸齒，光是這些暫存空間，就會占用相當可觀的顯示記憶體。
但其中大部分精度其實都沒用上。
地圖會先完成繪製，再調亮畫面，因此儲存的數值都落在可用範圍的較低半部。
換成容量只有一半、將精度集中在實際資料範圍的格式，就已經足夠。
把其中最大的緩衝區縮小一半，就能省下繪圖系統占用的不少記憶體，
而且不像串流載入，完全不會帶來物件延遲出現的問題。
這可不是改一行程式碼就能解決的事，接下來這段故事，很適合喝杯咖啡慢慢聊。
更換格式後，戰爭迷霧出了問題，偏偏在霧最暗的地方出現了塊狀瑕疵。
最直覺的解釋，是暗部的精度不足，但這個解釋其實是錯的，我們花了一番工夫才排除它。
真正的原因是，地圖上的雲影與雲層分成兩次繪製，卻作用在同一批像素上。
第一次繪製的結果，會先以較低精度寫入緩衝區，再讀回來作為第二次繪製的基礎。
採用高精度格式時，這樣來回存取並不成問題；
但換成較小的格式，就會經過兩次量化，而問題恰好出現在霧最暗的地方。
https://meee.com.tw/BF9do2K
［前後對照：降低記憶體用量後的地圖畫面］
解決方式是將兩次繪製合併，讓著色器內部以完整精度算出合成結果，最後只寫入一次。
這也省去了一次全螢幕繪製，因此運算成本還比原本略低一些。
另外，地表霧氣中還有一個早已存在的色帶問題，連高精度格式下也有，只是我們之前沒注意到。
我們在每幀畫面的最後處理階段加入極少量的抖色（dither），便修好了這個問題。
工作流程
偶爾會有人問我平常怎麼工作。
通常，更新內容不斷快速增加，我就跟著追蹤每日模擬耗時如何上升，其實沒什麼有趣的。
但越接近更新推出的日子，每天的工作就越緊湊。
先取得遊戲徹夜運行後的紀錄檔，這時遊戲裡可能已經過了六百到一千年。
這些紀錄能產出一百年的效能圖表，如果需要觀察更長期的趨勢，也能涵蓋更多年，幫助我找出哪些系統類別的表現與上次不同。
一套系統通常同時包含腳本與程式碼，所以下一步，就是弄清楚哪些改動可能影響了數字。
列出可疑項目後，就該找人逐一聊聊了：誰知道這項改動是不是有意為之？誰能提供更多資訊，幫我判斷接下來該從哪裡查起？
根據這些線索，我通常就能確定該到哪一段程式碼裡找答案。
光是掃一眼往往沒什麼用，因為一行程式碼背後就可能藏著相當複雜的運作。
不過，至少大部分內容我都熟悉，還是能先掌握基本情況。
如果能把問題範圍縮小到一項明確的操作，就可以在自己的電腦上針對它進行測量。
Very Sleepy 之類的外部取樣式效能分析器，通常能指出瓶頸所在，
但我也有一套遊戲內建的效能分析器，透過在程式中加入測量點來取得數據。
這些測量點會精確記錄函式的執行時間，加總後，我就能知道某段程式碼被呼叫了幾次，以及總共花了多少時間。
多數情況下，接著我就會去找設計師，說明自己的發現，而他們總是完全明白我在說什麼，就算我自己不明白也一樣。
極少數時候，我甚至還有機會親手改寫一點程式碼，讓它跑得更快！
系統記憶體
在 RAM 方面，以同一台電腦測量遊戲進行十年後的用量，相較於本次開發開始時，已經減少了約六分之一。
比例雖然不算驚人，卻也省下了超過 1 GB。
考慮到玩家可能一邊玩遊戲，一邊開著瀏覽器與聊天軟體，這就很有幫助；
對於記憶體僅達最低需求的電腦來說，更可能決定了它能否從容運行，還是得因為空間不足，開始與磁碟交換資料。
其中一項修正與動畫資料有關。
我們發現，同一份動作資料竟然被重複儲存了許多次。
過去，將動畫從一套骨架轉用到另一套骨架時，
產生的新副本會完整複製所有關鍵影格資料，儘管動作資料和儲存方式都完全相同。
現在則直接讀取原始資料，在取樣時才套用肢體比例的差異。
此外，不同骨架載入同一個動畫檔時，原本也會各自從磁碟讀取一次，導致記憶體裡出現多份一模一樣的副本。
動畫的中繼資料也有類似的重複儲存問題。
改善後，用量從 1,200 MB 降到約 12 MB，只剩原本的百分之一。
統計數據中還有一個有趣的現象：
一局遊戲進行到第五年左右，記憶體用量就會趨於平穩。
遊戲保留的資料幾乎都是啟動時就載入的，並不會隨著遊玩持續累積，
因此玩得久，也不會比剛開局多出多少記憶體負擔。
動畫資料與其他系統中，還有不少值得探索的改善空間，我們會在未來繼續研究。
啟動時間
只串流載入需要的內容，是啟動時間大幅縮短的主因，但並不是全部。
其餘的改善，大多來自找出遊戲原本不必做的工作。
其中影響最大的單一項目，甚至不是一套系統，而只是一個函式。
遊戲的在地化文字分散在一千多個檔案裡，過去會由單一執行緒逐一載入，其他 CPU 核心則閒在一旁。
在低效能測試機上，這是整份啟動效能分析中最耗時的單一項目，
占了你盯著載入畫面等待的不少時間。
改成平行讀取這些檔案，再依固定順序合併後，耗時就縮短到幾乎可以忽略不計。
遊戲過去還會連續計算兩次檔案檢查碼（checksum），等第一次算完，便丟掉結果，再算第二次。
這個問題已經修正，現在只計算一次，而且移到主選單出現後才執行。
因此，你能更早進入主選單，並在計算完成前就開始單人遊戲。
多人遊戲按鈕仍須等計算完畢才會開放，因為檢查碼是用來確認兩位玩家是否使用相同遊戲版本的依據。
https://meee.com.tw/Xy83kTy
［啟動時間效能分析前後對照：「Scribe」耗時 84 秒，《唯主之意》（By God Alone）耗時 16 秒］
有些大型目錄會被反覆掃描，只因為每次要查找的內容略有不同；
而啟動時也會逐一檢查全部九種在地化語言，儘管你實際上只會閱讀其中一種。
Vulkan 與 Windows
在同一台電腦上，Vulkan 繪圖引擎的啟動耗時約為 DirectX 11 的 1.8 倍，
結果原因竟然只是一行程式碼。
當某條執行緒將材質上傳到顯示卡時，它等待的是整個繪圖佇列清空，而不是自己的上傳工作完成。
於是，八條資源載入執行緒中的每一條，都得連其他七條的工作一起等完。
改成等待正確的工作後，兩種繪圖後端的表現便拉近了。
另一個發現是，同一台電腦使用 Linux 時，進入主選單的速度似乎總是 Windows 的兩倍。
檔案系統的程式碼並沒有明確差異，所以這就是那種一方單純比另一方表現更好的情況。
設定
我們會在設定中保留新的串流載入選項。
如果遇到意料之外的問題，仍然可以切回過去預先載入所有內容的方式。
不過，我們更希望能解決問題，讓所有人都用得上這套更快的新系統。
目前的成果
我們希望在遊戲持續擴大的同時，維持穩定的模擬速度，
並開始減輕五年開發累積下來的記憶體與載入時間負擔。
前者，在我們用來測量的電腦上，目前已接近「Scribe」版本的水準，預期最終也會落在相近的位置。
後者，遊戲所需的顯示記憶體已大幅減少，系統記憶體用量也明顯下降，
而低效能電腦進入主選單的時間，更是縮短到原本的一小部分
（高效能電腦也有改善，只是比較不容易察覺）。
這些工作還遠遠沒有結束！從我寫下這篇文章，到各位實際玩到更新之間，有些項目仍在持續調整。
角色互動的運算成本雖然已經下降，卻還沒回到夏季初的水準；
還有一大批動畫資料等著修改，而且我們已經知道該怎麼做。
至於其他部分，就是日常工作了：
只要遊戲還在開發，就會不斷有新的東西需要優化，這完全不是問題。
我還能繼續忙上一陣子！
真正的數字，要等正式推出後，由所有玩家親自測量。
不管結果是驚豔、出色，還是普普通通，我們都很期待聽到各位的回報。
盡情暢快地玩吧！
系統需求
我是技術主管「Divine」，偷偷插個話，簡單補充一下接下來幾次更新的系統需求。
上面 Carl-Henrik 提到了各種數字如何大幅下降，那麼，這對遊戲的最低硬體需求意味著什麼？
好消息是，儘管新資料片加入了這麼多內容與功能，我們仍會維持與先前版本相同的低硬體門檻。
前面介紹的各種厲害技術，正是讓十年前的硬體仍能遊玩現代遊戲的重要原因。
在《絲與銀》的開發中，我們也開始為遊戲與程式碼的未來做準備，以便更好地支援後續開發。
我們將改用較新的編譯工具組，讓程式碼能採用 C++20 標準。
為此，Linux 與 Mac 玩家的作業系統版本需求也必須提高。
今年稍晚《絲與銀》更新推出時，
遊戲將要求 Ubuntu 24.04 LTS（原為 Ubuntu 18.04 LTS）
與 macOS 15 Sequoia（原為 macOS Catalina）。
我們打算持續支援這些新版本數年，之後才會再考慮更新編譯工具鏈。
後記
這幾年，Studio Black 一直有舉辦名為 黑緞坊 的遊戲創作活動。
說起我與公司的淵源，我的 Paradox 生涯其實是從開發 Mega Drive 遊戲開始的，
那麼，還有什麼比動手製作《Mega Crusader Kings》更合適呢？
這可是效能與記憶體優化的終極挑戰！
我可以向各位報告：我已經開工了。
去年十二月，我花了幾天，從零開始用 68000 組合語言，
把《十字軍之王》「移植」到 Sega Mega Drive。
最離譜的是，它讀取的還真是 CK3 的資料。
有地頭銜檔案與省份地圖，會事先轉換成精簡的資料表，直接寫進卡匣；
主機開機時，再依據這些資料重建歐洲政治地圖。
總共有 59 個國家、1,028 個伯爵領，每種顏色都會對應到十六種可用色彩中最接近的一種，
而且你可以用十字方向鍵捲動地圖。
畫面上還有 HUD 介面框，以及一張望著你的哈羅德・戈德溫肖像。
https://meee.com.tw/H2EDw3m
［在模擬器中運行的《Mega Crusader Kings》。地圖使用的是真正的 CK3 資料］
(譯註：以防有人年輕到不知道....https://meee.com.tw/wosmfEr )
但它還稱不上遊戲。
沒有模擬、沒有文字、沒有聲音。
音效晶片在開機時就被關掉，之後再也沒開過。
而且，我還撞上了一道看過前面顯示記憶體章節的人都會很熟悉的難關：
Mega Drive 同時只能容納 1,536 個不同的圖塊，這張地圖卻需要大約六千個，結果歐洲畫到一半，就直接不畫了。
我在最後一次提交的修改紀錄中留下了一句話，全文如下：「得再省點顯示記憶體。」
技術上，所有國家與地區名稱都已經放在記憶體裡，隨時可以顯示；
程式運行時，也能把伯爵領從一個國家轉移給另一個國家，只是還沒有任何玩法。
看來，就算是 16 位元遊戲，花上大半個工作週也還是不夠
我不確定之後還有沒有時間繼續做這個專案，但很歡迎大家提出它實際上能做到哪些事情的建議！
我大約能使用 4 MB 的 ROM，也可以透過自訂卡匣，犧牲一部分 ROM 空間來換取 RAM。
主機有 64 KB 的 RAM 與 64 KB 的顯示記憶體。
目前 ROM 的大小是 104,024 位元組。
這跟設法讓一般低階 PC 全速運行《十字軍之王 III》，還真有點不一樣。
-----
Sent from JPTT on my Samsung SM-N950F.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.216.24.174 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Paradox/M.1788875926.A.611.html
推
09/09 01:50,
52分鐘前
, 1F
09/09 01:50, 1F
Paradox 近期熱門文章
PTT遊戲區 即時熱門文章
