從新建資料夾開始構建UtopiaEngine（2）

本篇序言

摸了兩個月的魚，又一次拾起了自己引擎的框架，開始完善引擎系統，如果非要用現實中的什麼東西比喻的話，那麼我們目前實現的框架連個腳手架都不是。把這專案這樣晾著顯然不符合本人的風格，而且要作為畢業設計的東西可不能矇混過關。所以現在成了既要準備研究生考試又要忙於設計框架並編碼的情況，生活已經充實到必須得抽空來寫blog了。

還有一件事，就是我們的引擎現在的構建步驟可能要與我曾經參考的Cherno大佬的不同了，其中一個原因是因為他的game engine系列還在更新，對程式碼的修改也相比剛開始有很大區別，目前榛子引擎架構只有大體上與曾經視訊中講述的一致，具體程式碼實現有許多部分已經不同了。這也給在下徒增了不少麻煩。當然，本人的引擎在後期也會變成這樣，可能你會在很長一段時間後才看到這個系列博文，而此時我釋出在GitHub和碼雲上的引擎原始碼或許已經完全不同（本系列博文在連載時並不會放出原始碼，所以如果你看的時候本系列還未更新結束，或許不用太擔心），這是不可避免的，不過文件的歸檔性至少比視訊要好。還有一個原因就是本人的英語聽力能力實在太過生草以及Cherno本人後期的語速實在太快，表示已經看不下去。如果對各位造成不便還請理解。

這段時間發現了一本比較好的書，是關於遊戲引擎的，是由企鵝的程東哲大佬寫的《遊戲引擎架構與實踐》（暫時忽略企鵝家那些遊戲爛到家的口碑，那些都是策劃的鍋，至少企鵝的技術人員還是很強的），本引擎在後期的記憶體分配以及資料結構容器等部分可能會參考本書上的實現，各位也可以買來看看。

好了，正文開始，精彩繼續。

1.應用程式介面

我們剛開始在引擎核心那裡架設了入口點，但當我們在應用程式（遊戲或編輯器）專案中寫入任何處理流程時我們會發現引擎核心是並不會執行的。這很好解釋，我們的引擎核心並不知道我們應用程式專案的存在，應用程式專案只是單向依賴引擎核心，並且更明顯的原因是我們無法將應用程式專案中的處理步驟寫入引擎核心的入口點的main函式裡。強制性通過include來引入沒人會知道發生什麼事，恐怕只有編譯器自己知道。

接下來就是解決方案，我們現在來建立一個應用程式介面，其實介面這個說法並不怎麼嚴謹，按照嚴格OOP規則，介面內是不允許有方法實現的，但C++在這方面並不怎麼“守規矩”以及我們的引擎核心有時也要實現其相關方法，但實在找不到個什麼別的說法，所以就先勉強湊合一下。那麼我們就先在引擎核心類內部宣告並定義一個應用程式介面BaseApplication類，宣告與定義如下：

// BaseApplication.h（宣告）

#pragma once

#include "Core.h"

namespace Utopia

{

    // 還記得我在上一篇文章中說過的核心規則麼？

    // 這裡為了將我們這個應用程式介面暴露在dll外面，我們可以對類宣告也這樣做

    // 在類名前加上已經定義好的ENGINE_API即可，條件編譯會保證呼叫正確，你可以用自己上次定義的巨集

    class ENGINE_API BaseApplication

    {

    public:

        BaseApplication();

        virtual ~BaseApplication();

        void ExcuteLoop();

        virtual void ExcuteCallback();

    private:

    };

}

// BaseApplication.cpp（定義）

#include "BaseApplication.h"

#include <iostream>

namespace Utopia

{

    BaseApplication :: BaseApplication() {

        // 建構函式定義，用來在這裡進行引擎核心相關的初始化步驟

        // 比如渲染框架的初始化，log系統的初始化等

        std::cout << "BaseApplication default constructor.\n";

    }

    BaseApplication :: ~BaseApplication() {

        // 解構函式的定義，用來釋放已經被引擎核心呼叫的相關資源

        std::cout << "BaseApplication default destructor.\n";

    }

    void BaseApplication :: ExcuteLoop()

    {

        while(true)

        {

            // 把渲染以及每幀訊息處理相關程式碼放在這裡

            // 鑑於目前並沒有開始渲染框架的構建，迴圈條件暫時以true代替，各位也可以隨便編寫一些條件測試一下

            // 但後續請記得刪掉

            this->ExcuteCallback();

        }

    }

    void BaseApplication :: ExcuteCallback(){}

}

當然，老規矩，類名和名稱空間名任君喜歡，但在後續呼叫中請記住它們的名字，以便呼叫。

這個時候呢，我們已經建立了引擎的應用程式介面類，接下來就是要在應用程式內建立應用程式介面類實現了，在我們的應用程式專案下新建一個.cpp檔案即可，因為應用程式介面實現類是沒有別的類會呼叫它的。宣告與定義如下：

// Application.cpp（宣告與定義）

#include "Engine.h"

#include <iostream>

class Application : public BaseApplication

{

public:

    Application();

    ~Application();

    void ExcuteCallback();

private:

};

Application :: Application()

{

    // 建構函式，用來初始化應用程式內的一些成員

    // 比如編輯器的UI框架，又或者是別的一些東西

    // 這裡UI框架有些特殊，這裡稍微劇透一下，本引擎打算使用的編輯器UI是著名的DearImGui

    // 但它的初始化過程必須在OpenGL相關API初始化併成功建立上下文之後，但這裡不用擔心，

    // 由於程式在執行時會首先執行介面類的初始化過程，完成後才執行本實現類的初始化過程。

    std::cout << "Application default constructor.\n";

}

Appication :: ~Application()

{

    // 解構函式，用來釋放資源

    std::cout << "Application default destructior.\n";

}

void Application :: ExcuteCallback()

{

    // 用來將應用程式中需要在渲染與訊息處理迴圈中處理的東西放在這裡

    // 想必各位應該已經發現了這個函式其實是介面類BaseApplicaiton的一個虛擬函式，

    // 因為只有這樣才可以讓介面類執行應用程式中的處理流程（虛擬函式可真是個好東西）

    std::cout << "Application ExcuteCallback() has called\n";

}

細心的同學此時應該發現問題了，你的下一句便是：永樂，這裡有點不對勁，即使已經聲明瞭應用程式介面，但引擎核心還是不知道應用程式中實現類的存在，那麼我們還是無法在入口點執行，如下：

// EntryPoint.h

int main(int argc, char** argv)

{

    BaseApplication* ba = new Application(); // 這裡即使支援里氏替換原則，但編譯器並不知道這個Application是誰

    ba->ExcuteLoop();

    delete ba;

    std :: cin.get();

    return 0;

}

這裡不用著急，我們可以利用一個特性（Mojang：方塊懸空不是bug，是特性！！！）：即宣告與定義可以在不同的檔案裡面。我們可以在BaseApplication的宣告檔案裡面新增這樣一個函式的宣告，也就是這樣：

namespace Utopia

{

    class ENGINE_API BaseApplication{ ··· };

    // 我們在這裡寫上宣告

    BaseApplication* ReturnAppInstance();

}

而我們會在Application.cpp裡面這樣去實現：

Utopia :: BaseApplication* Utopia :: ReturnAppInstance()

{

    return new Application();

}

這下我們就完成了一次“偷天換日”，我們將尋找實現的工作交給編譯器，接下來要做的就是接一杯摩卡坐在躺椅上慢慢享受緩慢的MSVC編譯過程……當然不是，距離成功執行我們還有些工作沒做，那麼接下來讓我們一起來看看。

首先，就是Engine.h中的問題，我們雖然成功建立了應用程式介面，但我們並沒有在Engine.h中包含應用程式介面的宣告檔案，以及我們並未包含引擎規則。所以我們會這樣做：

#pragma once

#include "Engine.h"

#include "Core.h"

#include "BaseApplication.h"

以上就是目前Engine.h的完全體。

接下來是處理入口點中的一些問題：既然我們的入口點才是真正的執行體，那麼我們便要定義如下執行體：

#include "Core.h"

#include "BaseApplication.h"

#include <iostream>

// 關於這裡為什麼要使用extern關鍵字：

// 編譯器可沒有IDE那麼聰明直接進行跳轉，由於編譯器並未在同名.cpp檔案內查詢到相關函式宣告

// 如果我們不做些什麼的話，那麼編譯器就將錯就錯認為我們並未建立定義了，所以這時使用extern關鍵字

// 用來告訴編譯器這個函式在別的地方已經定義過，讓它擴大搜尋範圍。

extern Utopia :: BaseApplication* Utopia :: ReturnAppInstance();

int main()

{

    BaseApplication* uBA = ReturnAppInstance();

    uBA->ExcuteLoop();

    delete uBA;

    std::cin.get();

    return 0;

}

這樣便萬無一失了，來按下f5鍵開始編譯。最後執行結果應該是如下幾句（前兩句列印完後其實是會不再列印的，原因是我為迴圈設的條件為true，這時為了顯示下面兩句（執行析構，強制性關閉並不會執行析構），可以考慮加入某些迴圈成立條件）：

BaseApplication default constructor.

Application default constructor.

Application default destructor.

BaseApplication default destructor.

不知大家發現沒有，BaseApplication的構造和析構流程將Application的執行流程“包裹”起來。這樣也便成功達到我們的目的：即先進行基礎框架的初始化，再完成更高階模組的初始化，釋放資源時正好相反。這樣就能防止像Imgui初始化和釋放資源時特殊情況了。

2. 日誌系統

還記得我在上一篇文章說的日誌系統麼？這次就來填掉這個坑。這個部分是幾乎所有應用程式都會有的一個子模組，比如CAD，模擬器（RPCS3，PPSSPP和PCX2等），以及你現在正在用的VS，各式各樣的控制檯程式等等……我們的引擎當然也不能少，至少在編輯器中我們是非常需要這個系統的，以及在遊戲製作中的除錯裡我們也有很大的需要。所以，接下來開始構建日誌系統，不過別擔心，這個系統很簡單，稍微一點點步驟就會完成。

2.1 spdlog

我們現在先在解決方案資料夾裡新建一個資料夾Vendor（小攤販？不過也差不多，後續我們引用的第三方庫多起來的時候是不是就應該叫做Supermarket了？），專門在這個資料夾裡放置各種第三方工具或程式碼。

我們的並不會自己從頭去寫一個日誌系統，我們將採用一個第三方程式碼庫：spdlog，這是一個呼叫非常簡單，使用容易上手並且極其強大的專門的日誌程式碼庫，它預設有三種提示型別：error，warning，information，分別對應不同的提示顏色，你可以增加型別並自定義顏色，而且你甚至可以不僅讓日誌輸出在控制檯上，你也可以讓它輸出在任何你想要的介面上，不過鑑於本人技術力太過生草以及本引擎的體量，使用預設的設定就足以完成我們的需求。

前往GitHub去下載spdlog的原始碼（連結我就不放了，在GitHub搜尋很容易就找到），記住，是下載原始碼，如果你的引擎專案添加了Git跟蹤，你可以直接用git module命令扒取下來，這裡不對這個命令做過多解釋。下好原始碼後就可以將原始碼檔案一股腦地全扔進Vendor資料夾裡面。接下來請開啟你的VS，我們要對我們引擎專案做些設定：

2.1.1 新建專案（模組）

注意，這裡的“專案”並不是指在引擎之外新建一個專案，而是VS解決方案中的“專案”，藉此機會說明一下對應關係，其實我們的引擎專案對應的是VS中的解決方案，而VS中的專案的概念對應的是我們引擎專案中引擎模組的概念。正好就在這裡進行嚴格規定，以後我會將VS的解決方案稱為解決方案或者引擎專案，VS的專案我們會稱為引擎模組，以此來避免概念混淆。

在本系列的第一篇文章發出後，有同學提出了反饋，說是新建專案用premake步驟還是比較麻煩，希望還是可以使用VS圖形化介面來建立，本人想了一下覺得也是比較可行的，一個原因便是多次引擎專案重新載入花的時間太長，尤其是在後期引擎模組增多了以後那更是緩慢，而且使用指令碼並不一定每次都會考慮周到將專案全部設定完畢，模組的依賴項太多時此缺點極其明顯，類似於“熱編譯”這種的還是有些吃不消。所以接下來所有的專案構建過程本人都會採用VS自帶的圖形化介面建立，除了特殊之處需要說明外，其他步驟不放圖。

首先在解決方案下新建一個新模組（VS選擇“增加新建專案”），由於這個模組是專門為日誌系統準備的，所以就起名叫做EngineLog即可，接下來在模組屬性中新增附加目錄，我們可以用VS提供的巨集定義來編寫附加目錄項。如果此時我的spdlog的路徑是：

D:/Project/UtopiaEngine/Vendor/spdlog

那麼我們可以來這麼寫：

$(SolutionDir)Vendor\spdlog\include

這裡$(SolutionDir)就是D:/Project/UtopiaEngine/路徑的巨集定義，這樣就會在由於因為某些原因更改引擎專案目錄的情況時不用擔心得一條條更改依賴路徑了。以下提供幾個常用巨集定義：

$(SolutionDir) // 解決方案路徑

$(ProjectName) // 專案（模組）名稱

$(Platform) // CPU平臺名稱，有x86，x64和arm三種

$(Configuration) // 專案屬性，即Debug，Release，Dist等

接下來設定模組生成的二進位制檔案為“動態連結庫（.dll）”，生成二進位制檔案的目錄以及obj檔案的目錄和引擎核心與應用程式同步即可。（切記一定要將各個模組最終生成的二進位制檔案（.lib .dll .exe）均放在同一個資料夾內，premake5中的複製命令也可以完成，具體做法請參考上一篇）

2.1.2 編寫

在繼續之前請為應用程式和引擎核心模組新增依賴項，即將我們的EngineLog作為它們的依賴項（即專案資源管理器中的依賴項以及模組屬性中的附加包含目錄均要新增），再然後為本模組新建一個資料夾src，程式碼檔案均放在這裡。完成此步驟之後，讓我們開始編寫相關程式碼。首先呢，我們需要和引擎核心一樣規定核心規則，新建一個頭檔案LogLibDefine.h用來規定條件編譯（當然不要忘記在模組屬性的前處理器定義裡面加上UTOPIA_LOG_DLLEXPORT哦）：

#pragma once

#ifdef UTOPIA_LOG_DLLEXPORT

	#define LOG_API _declspec(dllexport)

#else

	#define LOG_API _declspec(dllimport)

#endif

接下來就是建立相關類的宣告與定義了：

// EngineLog.h

#pragma once

#include <string>

#include <memory>

#include <spdlog\spdlog.h>

#include "LogLibDefine.h"

// 設定兩個巨集定義來指定我要使用的日誌輸出型別，分為引擎日誌和應用程式日誌兩部分

// 引擎日誌主要用在編輯器以及其他的開發環境中，應用程式日誌主要用在遊戲程式除錯或編輯器的相關資訊中。

#define UTOPIA_ENGINE_LOG 1

#define UTOPIA_APP_LOG 2

namespace Utopia

{

    class LOG_API EngineLog

    {

    public:

        // 關於這裡我為什麼全部使用靜態成員：

        // 由於日誌系統的程式碼可以說幾乎在引擎中的所有地方都會呼叫，如果使用非靜態成員，那每次呼叫都要在相應類中

        // 設定一個日誌類的成員物件，浪費了記憶體資源不說，可能還會造成不可必要的麻煩。

        // 其實關於這個還有一個更好的方法：將本模組轉為靜態庫（.lib），這樣便減少了模組呼叫之間的麻煩關係與限制。

        // 而且本模組並複雜，所以以靜態庫的形式在程式執行時就裝載進記憶體對效率的影響影響不算大

        // 具體方法具體選擇，大家可以嘗試用靜態庫包裝本模組。我目前在這裡先使用動態庫包裝。

        static void LogInit();

        // 對引數解釋一下：

        // 1. 型別是整型，用來存放我在上面的巨集定義的，程式會根據巨集定義的指定來選擇日誌輸出方，即是引擎還是應用程式

        // 2. 型別是字串，這很好懂啊，你想讓輸出什麼資訊，那就把它傳進這個字串裡就好

        static void ErrorLog(int _iLogType, string _sLogInfo);

        static void WarningLog(int _iLogType, string _sLogInfo);

        static void InfoLog(int _iLogType, string _sLogInfo);

    private:

        // 關於這裡我為什麼使用智慧指標：官方給的建議是這樣，誒嘿

        // 但其實真實原因也是因為智慧指標真的太香了，尤其是對於這種靜態成員來說，我可以完全不用關心何時進行釋放。

        static std::shared_ptr<spdlog::logger> s_CoreLogger;

        static std::shared_ptr<spdlog::logger> s_ClientLogger;

    };

}

// EngineLog.cpp

#include "EngineLog.h"

#include <spdlog\sinks\stdout_color_sinks.h>

namespace Utopia

{

    // 由於是靜態成員，所以需要在這裡實現一下

    std::shared_ptr<spdlog::logger> EngineLog::s_CoreLogger;

    std::shared_ptr<spdlog::logger> EngineLog::s_ClientLogger;

    // spdlog初始化步驟

    void EngineLog::LogInit()

	{

        // 這裡是對Log的格式進行設定，最終輸出結果是：

        // [xx:xx:xx]Utopia/APP：日誌訊息

        // 其他格式大家可以參考spdlog的官方文件自己去編寫一個格式

		spdlog::set_pattern("%^[%T] %n: %v%$");

		s_CoreLogger = spdlog::stdout_color_mt("Utopia");

		s_CoreLogger->set_level(spdlog::level::trace);

		s_ClientLogger = spdlog::stdout_color_mt("APP");

		s_ClientLogger->set_level(spdlog::level::trace);

	}

	void EngineLog::ErrorLog(int _iLogType, string _sLogInfo)

	{

		string s_logErrInfo = "Cannot find log type, please check your code. Origin information: ";

		switch (_iLogType)

		{

		case UTOPIA_ENGINE_LOG:

			s_CoreLogger.get()->error(_sLogInfo);

			break;

		case UTOPIA_APP_LOG:

			s_ClientLogger.get()->error(_sLogInfo);

			break;

		default:

			s_CoreLogger.get()->warn(s_logErrInfo + _sLogInfo);

			break;

		}

	}

	void EngineLog::WarningLog(int _iLogType, string _sLogInfo)

	{

		string s_logErrInfo = "Cannot find log type, please check your code. Origin information: ";

		switch (_iLogType)

		{

		case UTOPIA_ENGINE_LOG:

			s_CoreLogger.get()->warn(_sLogInfo);

			break;

		case UTOPIA_APP_LOG:

			s_ClientLogger.get()->warn(_sLogInfo);

			break;

		default:

			s_CoreLogger.get()->warn(s_logErrInfo + _sLogInfo);

			break;

		}

	}

	void EngineLog::InfoLog(int _iLogType, string _sLogInfo)

	{

		string s_logErrInfo = "Cannot find log type, please check your code. Origin information: ";

		switch (_iLogType)

		{

		case UTOPIA_ENGINE_LOG:

			s_CoreLogger.get()->info(_sLogInfo);

			break;

		case UTOPIA_APP_LOG:

			s_ClientLogger.get()->info(_sLogInfo);

			break;

		default:

			s_CoreLogger.get()->warn(s_logErrInfo + _sLogInfo);

			break;

		}

	}

 }

完成了以上工作後，我們便可以開始下面的一步。

2.2 建立關聯並部署進引擎

首先我們並不希望日誌系統相關初始化步驟在每個呼叫它的模組裡都執行一遍，那豈不是太麻煩了，瀕危記憶體保護協會會提出抗議的，所以我們會讓它在引擎核心老老實實地初始化後就不用再管其他的事情了。由於日誌系統並不是狀態機系統，所以也便不需要上下文的獲取與釋放，這樣就讓我們的行動更加靈活了。

老規矩，先為引擎核心建立相關模組依賴，兩個依賴建立完成後，我們還要為引擎核心也包含spdlog的路徑，在這些前置工作都做完後，我們便可以肆無忌憚地在引擎核心中呼叫其相關初始化方法，比如這樣：

BaseApplication :: BaseApplication() {

    std::cout << "BaseApplication default constructor.\n";

    EngineLog :: LogInit();

}

當我們想要呼叫的時候就不需要再次初始化便可直接在想要呼叫其方法的函式體裡呼叫。當然，別忘了為呼叫日誌系統的模組建立依賴以及附加包含目錄。執行效果的話大家可以參考上一篇那裡的截圖，那個就是我用了spdlog所建立的日誌系統

3. 本篇結語

你看，多簡單，就只有簡簡單單的兩步，我們就建立了一個引擎的框架，其實目前看來這才算是一個應用程式框架，當然，距離遊戲引擎框架還有一定的路要走，不過也不遠了。再更上個三四回吧，我們大概就可以出搭建一個既具有底層渲染框架，事件系統以及音效系統的較為完善的遊戲引擎框架。哦，做一個預告，下次更新我會開始搭建底層渲染框架以及部署我們引擎編輯器的UI底層。還請各位敬請期待。

本作品採用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行過許可