引言：當(dāng)“萬物皆可運行 DOOM”遇到極致創(chuàng)意

在技術(shù)圈，“萬物皆可運行 DOOM”是一個廣為流傳的梗，從計算器到數(shù)碼相機(jī)，無數(shù)設(shè)備都被大神們成功移植了這款經(jīng)典游戲。但如果這個問題變得更瘋狂一些：如果游戲的墻壁是真實的電路板銅線，敵人是芯片封裝，會是怎樣一番景象？

答案就是 KiDoom 項目。它將 1993 年的經(jīng)典游戲《毀滅戰(zhàn)士》（DOOM）渲染在了一個專業(yè)的 PCB編輯器 KiCad 中。這個項目背后充滿了巧妙的技術(shù)構(gòu)思和令人驚訝的實現(xiàn)細(xì)節(jié)，下文將為你揭示其中最有趣的五個事實。

-----------------------------------------------------------------------------

1. 核心理念：一場“無人問津”卻極致優(yōu)雅的技術(shù)炫技

KiDoom 并非為了解決任何實際問題，它的誕生源于一個純粹的好奇心和技術(shù)探索精神：“如果 DOOM 的墻壁是真實的 PCB 走線會怎樣？” 項目的創(chuàng)建者旨在回答一個根本沒人問過的問題，這本身就充滿了一種極客式的浪漫。

What if DOOM's walls were actual PCB traces? What if enemies were QFP-64 chips and health packs were SOT-23 transistors? KiDoom answers these questions nobody asked...

這種看似“無用”的創(chuàng)造，恰恰是技術(shù)社區(qū)創(chuàng)新精神和幽默感的最佳體現(xiàn)。它證明了最純粹的樂趣往往來自于探索技術(shù)的邊界，而非僅僅滿足實用需求。

2. 技術(shù)突破：從每秒 0.15 幀到可玩的關(guān)鍵轉(zhuǎn)變

項目最初的構(gòu)想是使用 PCB 焊盤來逐個像素地渲染游戲畫面，但這個思路很快被證明是行不通的。

• 每幀像素數(shù): 320 x 200 = 64,000 個
• 渲染時間: 64,000 個焊盤 × 每焊盤 0.1 毫秒 = 每幀 6.4 秒
• 最終幀率: 0.15 FPS (完全不可玩)

真正的突破在于一個“頓悟時刻”：開發(fā)者意識到 DOOM 引擎內(nèi)部本身就是以矢量（線段）而非像素來計算可見幾何體的，它將這些數(shù)據(jù)存儲在drawsegs[]和vissprites[]等內(nèi)部數(shù)組中。而 PCB 的銅走線恰好也是矢量數(shù)據(jù)。這個發(fā)現(xiàn)徹底改變了實現(xiàn)路徑，其渲染效率比像素掃描方案快了 200 到 500 倍。

• 每幀線段數(shù): 約 100-300 條
• 渲染時間: 約 200 條走線 × 每走線 0.1 毫秒 = 每幀 20 毫秒 (+ 刷新開銷)
• 最終幀率: 10-25 FPS (足夠進(jìn)行基本游戲)

這個從像素到矢量的思維轉(zhuǎn)變，是整個項目得以從一個不可能的想法，變成一個可玩的技術(shù)演示的基石。

3. 最具創(chuàng)意的設(shè)計：用芯片封裝的復(fù)雜性來代表游戲角色

KiDoom 項目中最為精妙的設(shè)計，在于它建立了一套實體映射系統(tǒng)：游戲中的不同實體（敵人、道具等）被渲染為不同復(fù)雜度的真實 PCB 元件封裝。

這種設(shè)計的巧妙之處在于，它創(chuàng)造了一種“任何 PCB 設(shè)計師都能直觀理解的視覺層級”。一個強(qiáng)大的霰彈槍手是一個復(fù)雜的 64 引腳芯片，而一個簡單的醫(yī)療包只是一個 3 引腳的晶體管。為了實現(xiàn)這個映射超過 150 種不同游戲?qū)嶓w的系統(tǒng)，開發(fā)者必須深入 DOOM 的 C 語言源代碼進(jìn)行修改。挑戰(zhàn)在于，游戲原生的vissprite_t渲染結(jié)構(gòu)體中并不包含實體的類型信息。解決方案是直接對引擎進(jìn)行“外科手術(shù)”：通過修改r_defs.h文件為vissprite_t結(jié)構(gòu)體增加一個mobjtype字段，并在r_things.c文件的R_ProjectSprite()函數(shù)中捕獲thing->type，從而在渲染每一幀時都能精確知道每個實體的具體身份。

4. 架構(gòu)解密：它并非在 KiCad內(nèi)部運行 DOOM

一個常見的誤解是 KiDoom 讓 DOOM 運行在了 KiCad 內(nèi)部，但事實并非如此。在這個項目中，KiCad 只是作為“顯示器”或“渲染器”。真正的 DOOM 游戲引擎是作為一個獨立的 C 語言進(jìn)程在后臺運行的。

項目采用了一種“三模式渲染”架構(gòu)，同時運行三個并行的可視化窗口：

• SDL 窗口: 真正玩游戲的地方，顯示完整的 DOOM 畫面。
• Python 線框窗口: 用于調(diào)試，顯示從游戲中提取出的矢量線條。
• KiCad PCB 窗口: 項目的主角，顯示由銅走線構(gòu)成的墻壁和由元件封裝構(gòu)成的實體。

每一幀的數(shù)據(jù)都遵循一個清晰的流程：從 C 語言的 DOOM 引擎drawsegs[]和vissprites[]數(shù)組中提取幾何數(shù)據(jù)，通過 Unix 套接字序列化為 JSON 格式，再由 Python 腳本接收并解析，最終更新到 KiCad 的畫布上。這種清晰的架構(gòu)劃分，展現(xiàn)了項目并非一個簡單的腳本，而是一個經(jīng)過深思熟慮的復(fù)雜系統(tǒng)。而整個系統(tǒng)的性能瓶頸，也清晰地指向了 KiCad 的 Python API 調(diào)用pcbnew.Refresh()，這一步會消耗 30-50 毫秒，是幀率的主要限制因素。

5. 最終觀感：復(fù)古街機(jī)風(fēng)與現(xiàn)代工程工具的奇妙融合

KiDoom 的最終畫面既不像現(xiàn)代游戲的精細(xì)像素，也沒有復(fù)雜的紋理，而是一種獨特的線框風(fēng)格，仿佛是復(fù)古街機(jī)游戲與現(xiàn)代工程軟件的結(jié)合體。

Think "1982 vector arcade game meets 1993 FPS meets 2025 PCB editor."

畫面的關(guān)鍵視覺元素包括：

• 墻壁: 藍(lán)色（B.Cu 底層銅）的銅走線框。
• 實體: 真實的 PCB 元件封裝。
• 遠(yuǎn)近提示: 近處的走線更粗，遠(yuǎn)處的更細(xì)，以此實現(xiàn)深度暗示。
• 天花板/地板: 并非逐扇區(qū)渲染，而是由簡單的全屏漸變色代表。

KiDoom 將經(jīng)典游戲、復(fù)古的矢量圖形美學(xué)和專業(yè)的工程軟件這三個看似無關(guān)的元素，成功地融合成了一種前所未有的、令人著迷的視覺體驗。

-----------------------------------------------------------------------------

結(jié)論：在限制中誕生的極致創(chuàng)意

KiDoom 不僅是一個成功的技術(shù)演示，更是一個關(guān)于創(chuàng)造力、問題解決和技術(shù)熱情的精彩故事。它向我們展示了，即使是使用最意想不到的工具，只要有足夠的巧思，也能創(chuàng)造出令人驚嘆的作品。

Is it practical? No. Is it efficient? Barely. Is it the correct use of a professional PCB design tool? Absolutely not. But it works.

這個項目留給我們的思考是：在你的專業(yè)領(lǐng)域，是否存在一些看似“不務(wù)正業(yè)”卻能激發(fā)無限創(chuàng)意的瘋狂想法？或者，下一個能運行 DOOM 的，會是什么意想不到的東西？

項目主頁：

https://www.mikeayles.com/#kidoom