從新建檔案夾開始構建UtopiaEngine（1）-有解無憂

序言

在苦等了半年多之后，我終于開始了向往已久的實時NPR游戲引擎專案——Utopia Engine，這半年多一直為了構建這個引擎在做很多準備：多執行緒、元件、腳本引擎、立即渲染GUI……統統吃了一遍（就差匯編沒學了，話說這學期要開這門課來著，結果老師都已經翹課四周了(╯‵□′)╯︵┻━┻），于是，等不及的我開始了Utopia Engine的構建專案（匯編的知識就一邊做一邊學吧）要趕在畢設前做完這個引擎作業量還是有些大的，當然，畢竟游戲引擎脫離不了計算機圖形，所以，本博客里的計算機圖形學相關內容也不會停止更新，敬請期待！

撰寫此文的目的也很簡單：就是為了做一個記錄，在以后的構建程序中防止出現錯誤而無法找到曾經埋下的隱患，并且同時也是學習相關技術的一個筆記，當然，我會盡量把這個系列寫的通俗易懂，可以讓看到這個博客同時也想要構建自己的游戲引擎的各位遵循著本系列做出自己的游戲引擎，是個有點偏向于教程的開發日志，但是并不是所謂的“0基礎速成班”，至少各位是要有較為足夠的C++語言開發經驗以及計算機圖形學的基礎知識，如果兩者都沒有，那么各位在啃本人寫的這些文章時恐怕就要有些費勁了，

1.專案設計

雖然說我對這個引擎渲染目標的定位是實時NPR（也就是實時非真實渲染），但其實效果更偏向于NPR里的“Toon Shading”，即卡通渲染，畢竟也是被新海誠導演制作的電影系列所驚艷到，所以希望通過實時渲染將這“雖然很假，但假的漂亮”的畫面表現出來，不過目前由于本人的技術能力太過于生草以至于如果直接進行NPR的渲染實作不知道會做出什么屑作來，并且目前現存的成功NPR技術實體也并不是完全在引擎層面上去實作的，因為美術風格可是破壞渲染統一性的最大原因，著名的如萬代南夢宮的《究極風暴》以及《罪惡裝備X》幾乎都是從貼圖層面去實作真實的“假”細節（這可累壞了不少美工和TA），所以本人目前并不打算在Utopia Engine上實作實時NPR渲染，著重實作目前較為流行的PBR（基于物理渲染）技術，也就是真實渲染領域，要求不高，只要能通過本引擎做出一個可以跑的中小體量的3D游戲即可，這也就是目前本階段的目標，接下來的事情就交給以后的我吧（拜托了，另一個我！）

2.初始化作業

2.1 專案構建

首先，宣告一下，我這里的作業環境是微軟的Visual Studio 2017 Community（以后均簡稱VS2017），使用的圖形api如果不出意外的話應該就是OpenGL，WinSDK是 10.0.17763.0，不過，由于WinSDK所造成的編譯失敗或者是其他除錯中的問題并不常見，所以這里可以忽略，

那么接下來開始構建專案，如何在VS2017里創建一個完整的C++空專案與解決方案并且為它創建本地與遠程git代碼庫就不用我過多贅述了，相信看到這里的大家都明白，不過我們接下來并不會在專案里創建我們的第一個代碼檔案并且開始莽代碼，因為VS2017自動創建的生成目錄、中間目錄、專案目錄檔案結構并不怎么符合我們的需求，只要記住專案名即可，

接下來要介紹一位熟悉的陌生人：premake工具，說它熟悉是因為想必各位都應該聽說過CMake，這個premake和CMake的作用一樣，都是用來做跨平臺專案構建的工具，說它陌生是因為這個名字是真的陌生（至少我周圍圈子的同學都沒聽過），使用這個工具的一個最主要原因是它不用在外網下載MinGW（￣へ￣），而且體量極小，一個Lua腳本就可以完成所有配置并且生成你想要的平臺版本，缺點就是沒有GUI，你得面對CMD無盡的黑暗（這里強力推薦微軟的Windows Terminal，有了它你甚至可以將你的CMD裝扮成初號機的顯示屏），不過操作很簡單，而且官方超詳細的Wiki也足以彌補這些缺陷，

如果你沒有premake工具的話，請前往premake的GitHub專案主頁下載對應作業系統的release壓縮包，解壓后你會得到一個premake5.exe可執行檔案，將這個檔案放入你的解決方案根目錄里，接下來再在你的根目錄里新建一個Lua腳本檔案（檔案后綴名是 “.lua”，檔案名必須為premake5），在里面敲入如下Lua腳本代碼：

workspace "UtopiaEngine"        -- 解決方案名稱（填入你自己的引擎解決方案名稱）
 architecture "x64"             -- 對應運行平臺，如果你想兼容更老的32位系統，請再加x86選項

 configurations {               -- 配置型別：Debug，Release，Dist
  "Debug",
  "Release",
  "Dist"
 }

-- 全域變數：描述輸出檔案路徑，因為無論是中間目錄還是輸出目錄都有一部分相同的，所以將它們提取出來
-- 和VS2017一樣，路徑定義都可以用特殊格式轉義符來表示，具體轉義符表示意義請參閱premake工具的GitHub wiki，里面有詳細解釋，這里不過多說明
outputdir = "%{cfg.buildcfg}-%{cfg.system}-%{cfg.architecture}"

project "UtopiaEngine"          -- 引擎專案名,不要說你連專案和解決方案的區別都不知道哦
 location "UtopiaEngine"        -- 源檔案所在目錄名，這里建議和專案名保持一致
 kind "SharedLib"               -- 專案生成型別，這里選擇SharedLib，在Windows平臺上就是dll檔案
 language "C++"                 -- 專案使用語言型別

 targetdir ("bin/" .. outputdir .. "/%{prj.name}")      -- 專案成品輸出目錄，Lua中使用“..”作為字串與變數之間的連接符
 objdir ("bin-int/" .. outputdir .. "/%{prj.name}")     -- 專案中間目錄

 files {                        -- 專案包含的檔案型別，假如說你希望使用VS自帶的.def檔案代替__declspec(dllexport),那么請加上.def的宣告
  "%{prj.name}/src/**.h",
  "%{prj.name}/src/**.cpp"
 }

 includedirs {                  -- 專案使用的第三方庫的include目錄，spdlog會在后面說明
  "%{prj.name}/vendor/spdlog/include"
 }

 filter "system:windows"        -- Lua里的條件判斷陳述句，開始和中止邊界以縮進為準，這里的意思是若目標系統為Windows則執行下列操作
  cppdialect "C++17"            -- 專案所遵循的語言標準
  staticruntime "On"            -- 靜態運行時
  systemversion "10.0.17763.0"  -- 系統版本號，也就是WinSDK的版本號，如果不知道你自己的，可以填latest
  
  defines {                     -- 專案的全域宏定義，后面會解釋兩個宏定義的意義
   "UTOPIA_PLATFORM_WINDOWS",
   "UTOPIA_BUILD_DLL",
  }

  postbuildcommands {           -- 需要premake在生成專案時執行的命令
   ("{COPY} %{cfg.buildtarget.relpath} ../bin/" .. outputdir .. "/Sandbox")
  }

 filter "configurations:Debug"  -- debug配置相關設定，下同
  defines "UTOPIA_DEBUG"
  symbols "On"

 filter "configurations:Release"
  defines "UTOPIA_RELEASE"
  optimize "On"

 filter "configurations:Dist"
  defines "UTOPIA_DIST"
  optimize "On"


project "Sandbox"               -- 接下來是引擎編輯器的專案配置，名字什么都可以，大致與Utopia Engine專案配置一致
 location "Sandbox"
 kind "ConsoleApp"
 language "C++"

 targetdir ("bin/" .. outputdir .. "/%{prj.name}")
 objdir ("bin-int/" .. outputdir .. "/%{prj.name}")

 files {
  "%{prj.name}/src/**.h",
  "%{prj.name}/src/**.cpp"
 }

 includedirs {
  "UtopiaEngine/vendor/spdlog/include",
  "UtopiaEngine/src/UtopiaEngine"
 }

 links {
  "UtopiaEngine"
 }

 filter "system:windows"
  cppdialect "C++17"
  staticruntime "On"
  systemversion "latest"
  
  defines {
   "UTOPIA_PLATFORM_WINDOWS"
  }

 filter "configurations:Debug"
  defines "UTOPIA_DEBUG"
  symbols "On"

 filter "configurations:Release"
  defines "UTOPIA_RELEASE"
  optimize "On"

 filter "configurations:Dist"
  defines "UTOPIA_DIST"
  optimize "On"

接下來呼叫cmd命令列鍵入“premake5.exe vs2017”命令，其中如果你使用的IDE是VS2019，那么就填“vs2019”即可，回車后運行，運行結果如下：
（圖1）

運行結果

在繼續之前先解釋幾個事情：

關于為什么將引擎編輯器和引擎核心分離出來，這一點相信大家如果使用虛幻4引擎寫過專案的話應該是深有體會的：自己專案的解決方案里通常在自己的專案之外也會包含一個名為UE4的專案（話說才發現Utopia Engine縮寫竟然和虛幻一樣），而這個專案就是引擎核心，是獨立掛載于你的專案上的（ps：貌似UE4編輯器的代碼就在核心里面，是要通過手動呼叫方法來略過生成編輯器的），再直白一點說就是你肯定不希望你的游戲里還塞著一個編輯器，占用存盤空間不說，也會消耗一定的計算資源，所以分離開是很有必要的，
Lua腳本中的postbuildcommands選項的解釋：
{COPY} %{cfg.buildtarget.relpath}：copy命令，如果是使用VS2017默認的生成目錄，那么引擎核心dll檔案是與編輯器可執行程式分開存盤在兩個不同的目錄里，如果要是進行debug（尤其是針對引擎核心的debug），那么必須在每次debug之前先編譯，然后手動將dll檔案放入編輯器的生成目錄里，麻煩，所以使用copy命令指示系統在每次生成完dll檔案后會自動復制一份放在編輯器的生成目錄里，
目前我只寫了關于Windows平臺的命令腳本，為的是讓專案的目錄結構符合開發習慣并且減少無謂的作業量，所以這個premake腳本檔案我并沒有寫MacOS以及Linux的生成命令，而且目前完全沒有必要去在這兩個平臺上去除錯代碼（人窮，買不起Mac），如果各位有需要，可以去premake的專案主頁看看官方檔案，

2.2 隱藏程式入口點

在引擎專案構建之前，我并沒有想好究竟該為這個引擎配置一個怎樣的腳本引擎，于是，我目前的想法是使用純C++作為引擎的游戲開發腳本語言（與其說腳本倒不如說直接上原始碼，誒嘿！），就和UE4一樣，不過，既然如此，就會很考驗設計模式的基礎了，即面向介面，因為游戲開發者可不想因為閱讀你的原始碼而浪費大量的時間成本，而我們能做的就是盡量為他們提供通俗易懂并且功能實在的介面讓他們去呼叫，

既然各位可以看到這里并且信得過我，那么我也相信各位已經有了一些圖形API的呼叫基礎（再不濟你也應該拿Java的awt做過小游戲吧），我們知道，一般圖形程式無非就是由三個部分組成：即初始化、渲染回圈以及釋放資源，這三個部分我們可以將它封裝在一個名為Application的類里（這里只是打個比方），然后用三個方法將這三個部分依次描述，再然后在main里面進行呼叫，這是目前最基礎的做法，或許有人會說：“啊呀，你這不符合單一職責原則”，那你也可以封裝成三個類，每個類只負責一個部分，但是游戲開發者（尤其是個人開發者）才不管你什么亂七八糟的“七大原則、二十多種模式”的條條框框，他們只想專注于游戲的實作，這時候如果讓他們去自己實作main函式，恐怕就沒人在再用你的引擎了（我就是這么過來的），所以我們得隱藏程式入口點，

廢話說了那么多，開始干正事，在你引擎的編輯器專案里新建一個cpp檔案，在引擎核心里新建兩個h檔案，為了名稱好記，暫且就叫做Engine.h(引擎頭檔案)、EntryPoint.h（入口點頭檔案）以及Application.cpp（編輯器源檔案），當然，名稱只是打個比方，你可以按照你自己喜歡的名稱來，但是你得記住相應的名稱的檔案作用是什么，畢竟我們還會在以后再用到它們，我們會在這三個檔案中分別寫入如下內容：

EnntryPoint.h


int main(int argc, char** argv)
{
    // 這里是引擎初始化代碼

    // 這里是引擎渲染回圈代碼

    // 這里是引擎運行結束前釋放資源并且terminate的代碼

    std::cout<<"Utah Teapot";
    return 0;

}

Engine.h


#include <iostream>
#include "EntryPoint.h"

Application.cpp


#include <Engine.h>

運行結果如下：（其實只要看第一行即可，因為下面是我后來加的log系統，如果是你的專案，應該會成功輸出第一行的文字，log系統在之后的文章中我會講到）
（圖2）

運行結果

看起來貌似很簡單，對沒錯，就這幾行代碼，我們完成了最重要的一步：入口隱藏，我們將入口隱藏在了引擎核心dll檔案里，使得游戲開發人員不必將過多的精力放在main的實作上，這樣看起來便有點樣子了，不是么？

2.3 確定引擎內核規則

其實我也不知道該怎么稱呼，總之就是想要將我們以后在引擎內核定義的物件、靜態方法、函式等一系列的東西呼叫在游戲邏輯中的時候，可不止是一句簡簡單單的#include就可以解決問題，畢竟引擎內核是一串二進制代碼構成的dll檔案，即元件，微軟專門為元件提供了兩個陳述句：dllimport以及dllexport，呼叫方法如下：

// 假如說我在dll里的某個頭檔案里定義了這么一個函式，并且是對外提供呼叫的
__declspec(dllexport) void DllFunc()
{
    // Blablablablablablabla...
}

// 如果我要在另一個依賴此dll的專案里使用它，那么我必須在這個專案里宣告
__declspec(dllexport) void DllFunc();

但是它太麻煩了，試想，如果每一個對外開放的函式都這么寫，冗余的代碼量增加不說，關鍵是在面對跨平臺構建專案時，XCode可不認你的dllimport和dllexport，畢竟蘋果的MacOS有著自己的一套SharedLib體系，這時候再去一個個改又會增加無謂的作業量，所以我們要通過某些手段來降低移植難度，

還記得在命令腳本里出現的兩句全域宏定義嗎：UTOPIA_PLATFORM_WINDOWS 以及 UTOPIA_BUILD_DLL ，接下來就是使用這些宏定義的時候了，我們可以為引擎核心創造一個專門用來進行SharedLib生成指令的頭檔案（檔案名“Core.h”），代碼如下：


#pragma once
#ifdef UTOPIA_PLATFORM_WINDOWS                          // 平臺識別宏
    #ifdef UTOPIA_BUILD_DLL                             // 判斷是否是Dll內定義
        #define ENGINE_API __declspec(dllexport)        // 如果是，則dllexport
    #else                                               
        #define ENGINE_API __declspec(dllimport)        // 否則，dllimport
    #endif                                              
#else
    #error engine is only build on windows at now!      //錯誤資訊
#endif

先解釋幾個問題：

我只是定義了適用于Windows平臺的宏定義，其他平臺大家可以根據編譯器的要求來設定不同的分支，
全域宏定義以及其他的宏定義的名稱任君所愛，但是在定義完后請一定要記牢，以后還有用，

接下來讓它被包含在Engine.h中，那么，在你的游戲專案中只要引入Engine.h并且在我們的以后書寫中為類和函式定義前加上你所定義的 ENGINE_API，那么在游戲專案加載編譯時，編譯器會自動根據宏定義去判斷究竟是使用import還是export而不用你在源檔案中進行宣告，

3.結束語

其實本引擎的結構在很大程度上與油管大佬Cherno的榛子引擎相像，因為我就是看著Cherno大佬的課程一步步來的，但是YouTube的聽譯字幕質量著實不咋樣，導致我看的時候甚至一天只能看兩個教學視頻，B站也有好心的UP主搬運過來但由于是全英文的所以也勸退了不少人，我記得在虛幻引擎的官方Q&A里面有這樣一句話：“代碼是有著作權的，但知識是無價的”，所以，如果說你的閱讀能力不錯，那可以跟著我一塊來學習，我替你把該踩的雷先踩過，這樣你也就輕松多了，對我來說也是在積攢開發知識的程序，何樂而不為？但是也不要抱太大希望哦，說不定哪天就斷更了，誒嘿！o(￣▽￣)ブ

當然了，因為完成時間倉促以及本人技術力太過生草，肯定文中還有許許多多的問題，歡迎各位大佬們指正（如果只是想無腦噴的話，請出門左拐WB），以上，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/270776.html

標籤：其他

上一篇：unity渲染篇：烘焙模型貼圖

下一篇：Serverless Wordpress 系列建站教程(一)