前段時間看到國外一博客上的幾篇Doom3代碼分析的文章，感覺分析得不錯，就自己翻譯了一下，以下是譯文，有不太理解地方就直接貼了原文。大部分是按自己的理解翻譯的，可能有些地方譯的并不精確。有喜歡的朋友可以在這里看原文：http://fabiensanglard.net/doom3/，這里歡迎各種討論。
Within hours the GitHub repository was forked more than 400 times，大家在不同的平臺上編譯并且查看游戲的內部實現機制。我也馬上開始了Mac版本代碼的學習。
這份代碼在清晰度和注釋方面，是繼id Software發布Doom iPhone代碼后，最好的一份代碼。我建議每一個愛好者都去讀一讀，并研習這份代碼的實現。
拿到這份具有開創性的引擎代碼是一件很令人興奮的事情。早在2004年Doom3發行時，它確立了實時3D圖形和音頻的新標準。它首次使技術上允許美術創作人員像好萊塢模式那樣去表達自己的想法。盡管8年過去了，首次在Delta Labs 4遇見HellKnight的情景仍然很震撼:
從TTimo發布的原始代碼很容易在Visual Studio 2010上編譯。不幸的是，不能用Visual Studio 2010 Express版編譯，因為Doom3代碼中使用了MFC，而Express版沒有。
我喜歡在Mac系統下用XCode瀏覽代碼。相比于Visual Studio，它在搜索速度和變量的高亮方面都給我很享受的體驗。我想用XCode來編譯程序，但是項目設置有一些問題。不過很容易通過幾個簡單的步驟修復好。這里有一個github已包含了所有的修改。
完成 雜記：為了運行游戲，base文件夾下需要包含Doom3 的資源。由于我的機器上沒有cd驅動器，所以我下載了Steam版本。似乎id Software也做了同樣的事，在Visual Studio的項目設置里仍然包含了這樣的字符"+set fs_basepath C:\Program Files (x86)\Steam\steamapps\common\doom 3" !
架構
解決方案（solution）中項目的劃分反映了整個引擎的架構
下面以更可視化的方式來概括這個架構
Doom3的大部分代碼在2004年10月的時候可以通過發布的Doom3 SDK中看到，但是SDK里沒有Doom3執行文件部分代碼。在SDK中可以構建idLib部分和gamex86部分，核心引擎部分那時仍然是閉源的。
注意：在游戲模塊(gamex86)，每一個類都是從idClass繼承的，這樣引擎可以執行內部RTTI，并且也可以通過類名字來實例化類。
雜記：你仔細觀察上面的架構圖，可能會發現有一些基本框架（例如FileSystem）只在Doom3.exe中。這里就會有一個問題，就是當gamex86也要加載資源的時候。
問：那么gamex86是如何處理的呢？
答：這些子系統是從Doom3.exe中動態加載到gamex86.dll中的，這也是指示箭頭出現的原因。
如果我們使用PE explorer等工具查看gamex86.dll，我們會看到gamex86.dll導出了一個函數：GetGameAPI: 
這是同Quake2加載renderer和game 動態庫方式一模一樣：當Doom3啟動gamex86.dll的時候，會交換對象的指針
- 通過LoadLibrary將dll加載到進程的內存空間中
- 通過GetProcAddress獲取GetGameAPI在gamex86.dll中的地址
- 調用GetGameAPI
gameExport_t * GetGameAPI_t( gameImport_t *import );
在最后完成“握手”時，Doom3.exe有一個指針指向idGame對象，gamex86.dll有一個指針指向gameImport_t對象，這個對象包含了gamex86.dll中沒有的子系統，比如idFileSystem。
typedef struct {
int version; // API version
idSys * sys; // non-portable system services
idCommon * common; // common
idCmdSystem * cmdSystem; // console command system
idCVarSystem * cvarSystem; // console variable system
idFileSystem * fileSystem; // file system
idNetworkSystem * networkSystem; // network system
idRenderSystem * renderSystem; // render system
idSoundSystem * soundSystem; // sound system
idRenderModelManager * renderModelManager; // render model manager
idUserInterfaceManager * uiManager; // user interface manager
idDeclManager * declManager; // declaration manager
idAASFileManager * AASFileManager; // AAS file manager
idCollisionModelManager * collisionModelManager; // collision model manager
} gameImport_t;
typedef struct {
int version; // API version
idGame * game; // interface to run the game
idGameEdit * gameEdit; // interface for in-game editing
} gameExport_t;
注意：一個好消息是，id tech4的開發者在Doom3 SDK 文檔頁很好的描述了各個子系統。
C… ++ ?!
- 在id Software歷史上這是第一次用C++代碼代替了C。關于此事我問了卡馬克：
"
Hello John,
I wonder what motivated to move the team to C++ for idtech4.
Fab
"
"
There was a sense of inevitability to it at that point, but only about half the programmers really had C++ background in the beginning. I had C and Objective-C background, and I sort of "slid into C++" by just looking at the code that the C++ guys were writing. In hindsight, I wish I had budgeted the time to thoroughly research and explore the language before just starting to use it.
You may still be able to tell that the renderer code was largely developed in C, then sort of skinned into C++.
Today, I do firmly believe that C++ is the right language for large, multi-developer projects with critical performance requirements, and Tech 5 is a lot better off for the Doom 3 experience.
John Carmack
"
他也在2004年的時候有評論：
"
Is C++ a better language for developing games than C? Today, most games are developed in C++, and I know that Doom 3 was developed in C++. Having worked with both C and C++ for quite a while, do you think C++ is really a better language for developing games?
"
"
Yes, it is. I'm not a fan of the more complex features of C++, but grouping things into classes is a Good Thing.
John Carmack
"
- 代碼中使用了大量抽象和多態。但是一個漂亮的技巧可以避免某些對象因虛函數表而帶來的性能問題。
- 所有的資源都使用可讀性很好的文本方式存儲。沒有太多的二進制內容。代碼中廣泛地使用了Lexer/Parser的組合。
- 模板被用在低層實用類中（idLib），但是從不會在高層代碼中出現，不會像Google的V8代碼那樣刺瞎你的眼。
- 在代碼注釋方面，它是id Software的代碼中第二好的，最好的是Doom iPhone代碼，可能因為它比Doom3是更近的一段時間編寫的。
- 看一下編碼約定也是很有趣的事情，在這里。
主循環概覽
這里是主循環展開后的代碼：（更詳細的在這里）
idCommonLocal commonLocal; // OS Specialized object
idCommon * common = &commonLocal; // Interface pointer (since Init is OS dependent it is an abstract method
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
Sys_SetPhysicalWorkMemory( 192 << 20, 1024 << 20 ); //Min = 201,326,592 Max = 1,073,741,824
Sys_GetCurrentMemoryStatus( exeLaunchMemoryStats );
Sys_CreateConsole();
SetErrorMode( SEM_FAILCRITICALERRORS );
for ( int i = 0; i < MAX_CRITICAL_SECTIONS; i++ ) {
InitializeCriticalSection( &win32.criticalSections[i] );
}
Sys_Milliseconds();
common->Init( 0, NULL, lpCmdLine ); // Assess how much VRAM is available (not done via OpenGL but OS call)
Sys_StartAsyncThread() // 開啟異步線程
{ // 異步線程展開（譯注：異步線程中并沒有找到類似的代碼）
while ( 1 )
{
usleep( 16666 ); // Run at 60Hz
common->Async(); // Do the job
Sys_TriggerEvent( TRIGGER_EVENT_ONE ); // Unlock other thread waiting for inputs
pthread_testcancel(); // Check if we have been cancelled by the main thread (on shutdown).
}
}
Sys_ShowConsole
while ( 1 )
{
Win_Frame();
common->Frame();
}
}
這是id Software引擎的標準主循環，除了Sys_StartAsyncThread函數表明Doom3是多線程的，這個線程的目的是為了處理時間敏感的功能，引擎不希望這部分被幀率限制住。
雜記：id Tech4的高層對象都是抽象類，這將會使程序在運行時從虛函數表中查找虛函數地址而導致性能問題。但是這里有一個“技巧”來避免這個問題。所有的對象被以靜態的方式實例化，如下：
idCommonLocal commonLocal; // Implementation
idCommon * common = &commonLocal; // Interface manipulated in the code
這樣編譯器在編譯時就可以決定被調用的函數，從而不用去查找虛函數表。這實際上是一個雙贏，since the pointer does not have to be dereferenced at runtime either since its address is known at compile time.
雜記：已經讀過6、7款id Software引擎的我發現，有一些函數名從doom1開始就一直沒有改變過：負責處理鼠標和游戲桿輸入的函數仍然叫IN_frame()
渲染器
Doom3中最令人興奮的當然是渲染器部分。這里有太多的內容，所以我將這部分的筆記分到另一篇文章里了。在這里
如果你對（場景）預處理和入口系統（portal system）很感興趣，可以看這里。
新的標準
新的標準可以概括為一個詞：Unification
前一代引擎在渲染所有元素的時候，使用的是不同的方式，經常要花費很長時間的預處理。Quake2中的基于光能傳遞的lightmap，在設計者能看到最終的效果前需要等很長時間。
物理引擎
（譯注：原文這里沒有內容，大概還沒寫好）
腳本和虛擬機
（譯注：原文這里沒有內容，大概還沒寫好）
地圖加載
我記憶中，加載所消耗的時間很長，我一直想知道在加載場景的時候，程序背后都做了些什么。
結語
It was not always easy to focus...
But overall it was very educationnal to read most of it.
