從新建檔案夾開始構建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 國際許可協議進行過許可

標籤：其他

上一篇：Unity周記: 2020.07.05-07.11

下一篇：Unity3D 第一人稱控制器