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