雜記：為了運(yùn)行游戲，base文件夾下需要包含Doom3 的資源。由于我的機(jī)器上沒(méi)有cd驅(qū)動(dòng)器，所以我下載了Steam版本。似乎id Software也做了同樣的事，在Visual Studio的項(xiàng)目設(shè)置里仍然包含了這樣的字符"+set fs_basepath C:\Program Files (x86)\Steam\steamapps\common\doom 3" !

架構(gòu)

    解決方案（solution）中項(xiàng)目的劃分反映了整個(gè)引擎的架構(gòu)

    下面以更可視化的方式來(lái)概括這個(gè)架構(gòu)

    Doom3的大部分代碼在2004年10月的時(shí)候可以通過(guò)發(fā)布的Doom3 SDK中看到，但是SDK里沒(méi)有Doom3執(zhí)行文件部分代碼。在SDK中可以構(gòu)建idLib部分和gamex86部分，核心引擎部分那時(shí)仍然是閉源的。

注意：在游戲模塊(gamex86)，每一個(gè)類(lèi)都是從idClass繼承的，這樣引擎可以執(zhí)行內(nèi)部RTTI，并且也可以通過(guò)類(lèi)名字來(lái)實(shí)例化類(lèi)。

雜記：你仔細(xì)觀察上面的架構(gòu)圖，可能會(huì)發(fā)現(xiàn)有一些基本框架（例如FileSystem）只在Doom3.exe中。這里就會(huì)有一個(gè)問(wèn)題，就是當(dāng)gamex86也要加載資源的時(shí)候。

問(wèn)：那么gamex86是如何處理的呢？

答：這些子系統(tǒng)是從Doom3.exe中動(dòng)態(tài)加載到gamex86.dll中的，這也是指示箭頭出現(xiàn)的原因。

    如果我們使用PE explorer等工具查看gamex86.dll，我們會(huì)看到gamex86.dll導(dǎo)出了一個(gè)函數(shù)：GetGameAPI:  

這是同Quake2加載renderer和game 動(dòng)態(tài)庫(kù)方式一模一樣：當(dāng)Doom3啟動(dòng)gamex86.dll的時(shí)候，會(huì)交換對(duì)象的指針

• 通過(guò)LoadLibrary將dll加載到進(jìn)程的內(nèi)存空間中
• 通過(guò)GetProcAddress獲取GetGameAPI在gamex86.dll中的地址
• 調(diào)用GetGameAPI

gameExport_t * GetGameAPI_t( gameImport_t *import );

    在最后完成“握手”時(shí)，Doom3.exe有一個(gè)指針指向idGame對(duì)象，gamex86.dll有一個(gè)指針指向gameImport_t對(duì)象，這個(gè)對(duì)象包含了gamex86.dll中沒(méi)有的子系統(tǒng)，比如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;

注意：一個(gè)好消息是，id tech4的開(kāi)發(fā)者在Doom3 SDK 文檔頁(yè)很好的描述了各個(gè)子系統(tǒng)。

 

C… ++ ?!

• 在id Software歷史上這是第一次用C++代碼代替了C。關(guān)于此事我問(wèn)了卡馬克：

"

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年的時(shí)候有評(píng)論：

"
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

"

• 代碼中使用了大量抽象和多態(tài)。但是一個(gè)漂亮的技巧可以避免某些對(duì)象因虛函數(shù)表而帶來(lái)的性能問(wèn)題。
• 所有的資源都使用可讀性很好的文本方式存儲(chǔ)。沒(méi)有太多的二進(jìn)制內(nèi)容。代碼中廣泛地使用了Lexer/Parser的組合。
• 模板被用在低層實(shí)用類(lèi)中（idLib），但是從不會(huì)在高層代碼中出現(xiàn)，不會(huì)像Google的V8代碼那樣刺瞎你的眼。
• 在代碼注釋方面，它是id Software的代碼中第二好的，最好的是Doom iPhone代碼，可能因?yàn)樗菵oom3是更近的一段時(shí)間編寫(xiě)的。
• 看一下編碼約定也是很有趣的事情，在這里。

主循環(huán)概覽

    這里是主循環(huán)展開(kāi)后的代碼：（更詳細(xì)的在這里）

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() // 開(kāi)啟異步線程

    {                      // 異步線程展開(kāi)（譯注：異步線程中并沒(méi)有找到類(lèi)似的代碼）

        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引擎的標(biāo)準(zhǔn)主循環(huán)，除了Sys_StartAsyncThread函數(shù)表明Doom3是多線程的，這個(gè)線程的目的是為了處理時(shí)間敏感的功能，引擎不希望這部分被幀率限制住。

• 聲音處理
• 用戶輸入處理

雜記：id Tech4的高層對(duì)象都是抽象類(lèi)，這將會(huì)使程序在運(yùn)行時(shí)從虛函數(shù)表中查找虛函數(shù)地址而導(dǎo)致性能問(wèn)題。但是這里有一個(gè)“技巧”來(lái)避免這個(gè)問(wèn)題。所有的對(duì)象被以靜態(tài)的方式實(shí)例化，如下：

        idCommonLocal    commonLocal;                 // Implementation

        idCommon *       common = &commonLocal;       // Interface manipulated in the code

這樣編譯器在編譯時(shí)就可以決定被調(diào)用的函數(shù)，從而不用去查找虛函數(shù)表。這實(shí)際上是一個(gè)雙贏，since the pointer does not have to be dereferenced at runtime either since its address is known at compile time. 

雜記：已經(jīng)讀過(guò)6、7款id Software引擎的我發(fā)現(xiàn)，有一些函數(shù)名從doom1開(kāi)始就一直沒(méi)有改變過(guò)：負(fù)責(zé)處理鼠標(biāo)和游戲桿輸入的函數(shù)仍然叫IN_frame()

 

渲染器

    Doom3中最令人興奮的當(dāng)然是渲染器部分。這里有太多的內(nèi)容，所以我將這部分的筆記分到另一篇文章里了。在這里
    如果你對(duì)（場(chǎng)景）預(yù)處理和入口系統(tǒng)（portal system）很感興趣，可以看這里。

新的標(biāo)準(zhǔn)

    新的標(biāo)準(zhǔn)可以概括為一個(gè)詞：Unification

    前一代引擎在渲染所有元素的時(shí)候，使用的是不同的方式，經(jīng)常要花費(fèi)很長(zhǎng)時(shí)間的預(yù)處理。Quake2中的基于光能傳遞的lightmap，在設(shè)計(jì)者能看到最終的效果前需要等很長(zhǎng)時(shí)間。

物理引擎

（譯注：原文這里沒(méi)有內(nèi)容，大概還沒(méi)寫(xiě)好）

腳本和虛擬機(jī)

（譯注：原文這里沒(méi)有內(nèi)容，大概還沒(méi)寫(xiě)好）

地圖加載

    我記憶中，加載所消耗的時(shí)間很長(zhǎng)，我一直想知道在加載場(chǎng)景的時(shí)候，程序背后都做了些什么。

結(jié)語(yǔ)

    It was not always easy to focus...

    But overall it was very educationnal to read most of it.