編譯筆記

『壹』 編譯器筆記6-詞法分析-有窮自動機

有窮自動機(Finite Automata，FA)由兩位神經物理學MeCuloch和Pitts於1948年首先提出，是對 一類處理系統建立的數學模型。這類系統具有一系列離散的輸入輸出信息和有窮數目的內部狀態（狀態：概括了對過去輸入信息處理的狀況）。

系統只需要根據當前所處的狀態 和 當前面臨的輸入信息就可以決定系統的後繼行為。每當系統處理了當前的輸入後，系統的內部 狀態也將發生改變。

電梯控制裝置

輸入：顧客的乘梯需求（所要到達的層號）
狀態：電梯所處的層數+

電梯控制裝置並不需要記住先前全部的服務要
求，只需要知道電梯當前所處的狀態以及還沒
有滿足的所有服務請求。

輸入帶 (input tape) ：用來存放輸入符號串。

讀頭 (head) ：從左向右逐個讀取輸入符號，不能修改（只讀）、不能往返移動。

有窮控制器 ( finite control ) ：具有有窮個狀態數，根據當前的
狀態和當前輸入符號控制轉入 下一狀態。

確定的FA (Deterministic finite automata, DFA)
非確定的FA (Nondeterministic finite automata, NFA)

M = (S，Σ，δ，s0，F)

例：一個DFA

M = (S，Σ ，δ，s0，F)

M = (S，Σ，δ，s0，F)

例：一個NFA
M = (S，Σ，δ，s0，F)

對任何非確定的有窮自動機N，存在定義同一語言的確定的有窮自動機D。對任何確定的有窮自動機D，存在定義同一語言的非確定的有窮自動機N。

DFA和NFA可以識別相同的語言

M = (S，Σ，δ，s0，F)

從正則表達式到NFA相對直接到DFA比較簡單,再從NFA轉到DFA。

例 r=(a|b)* abb 對應的NFA

與NFA等價的DFA的每個狀態都是NFA狀態的一個子集

move(T,a)獲得的是一個狀態集合U，ε-closure（move(T,a)）即為ε-closure(U)對應上表的第二個操作。所以理解上述函數關鍵是理解closure(T),該操作其實就是求得一個狀態集合只通過ε轉換得到的另外一個集合。

『貳』 UE4學習筆記（1）：UE源碼下載編譯+安卓打包

註：該筆記以UE4.27.2在windows平台為例，vs版本為2019

1.關聯github和Epic賬戶

要在github上獲取UE4源碼需要先關聯賬戶，否則找不到源碼，網頁404

按照官網提供流程即可完成 GitHub上的虛幻引擎 - Unreal Engine

記得確認郵件，否則還是404（當初就是忘記了，卡了好一會兒）

2.下載UE4源碼

在 Releases · EpicGames/UnrealEngine (github.com)中選擇自己需要的版本（我使用的是4.27.2），這步很簡單，但需要注意的是還需要將Commit.gitdeps.xml文件也一並下載，用於替換同名文件（有些版本則沒有這樣的文件），不替換的話後續會報錯（之後步驟中會提到）

解壓後目錄如下：

3.執行bat文件

（1）點擊運行setup.bat，沒有替換Commit.gitdeps.xml文件可能會出現如下問題：

（2）點擊運行GenerateProjectFiles.bat，此過程可能會出現如下問題：

未找到框架 .NETFramework Version=v4.6.2

只需要在VS Installer中選中安裝就行：

完成後會生成UE4.sln文件

4.生成

VS打開UE4.sln，開始生成：

但是生成過程中我出現了這樣的問題：

UE4 fatal error C1076: 編譯器限制: 達到內部堆限制

error C3859: 超過了 PCH 的虛擬內存范圍問題解決

我出現這樣問題的原因是我的C盤空間不夠大（分區的時候給的比較少），託管系統設置在C盤，導致無法分配足夠的虛擬內存，設置為空間足夠的盤即可。

步驟：電腦->屬性->高級系統設置->高級->性能設置->高級->更改

OK，成功編譯完成

5.安卓打包

該過程有官方文檔，並且比較繁瑣，直接給出鏈接：

設置虛幻的Android SDK和NDK | 虛幻引擎文檔 (unrealengine.com)

UE部署到Android以及雜症的解決 - 知乎 (hu.com)

我就提一下自己遇到的問題，在UE4中進行安卓打包的時候遇到了這樣的問題：

原因在於SetupAndroid.bat中，SDK Platform的版本選擇是32，而在UE項目設置->平台 - Android SDK中的SDK API Levle默認選擇latest。但是我安裝AS的時候默認給我安裝了最新的Android API 34（此時latest指向的是34版本），導致沖突。解決方法是UE項目設置中手動設置指定版本，或者在AS中卸載高於32版本的Android API。

OK，打包成功！！！

6.打開游戲

但是，是的，還有但是（都最後一步了，還有問題OVO！！！），在手機上下載安裝，打開後是這樣的：

原來是因為打包除了生成apk文件還生成了obb，至於Google Play Store Key應該就是一個密鑰了。

解決方法是在UE項目設置->Android中勾選「將游戲數據打包至.apk中」，我們可以看到對這個勾選項的解釋：

行，勾選後重新打包，成功運行：

『叄』 OsgEarth學習筆記-新01，從源碼編譯osgEarth

從源碼編譯 osgEarth 的學習筆記

學習路徑及環境准備

學習路徑選定為 osgEarth，以期找到項目工作的突破點。本機環境為 Windows11 64bit，使用 VS 2019 社區版進行開發。由於涉及到OSG第三方依賴，需安裝 VC 2017 x64 的編譯環境。後續的預編譯或源碼編譯操作均基於 VC2017 版本。

環境搭建步驟

首先，安裝 VC2017 編譯環境，並下載 Cmake 工具。

其次，從 GitHub 下載 osgEarth 源代碼（當前為 3.4 版本）及 OpenSceneGraph（當前為 3.6.5 版本），確保遵循官網對依賴項的要求：OSG 3.6 及以上、GDAL 2.4 及以上、CURL、GEOS 3.2 及以上（可選）。對於 GDAL，考慮到版本兼容性，選擇 2.4 版本以避免後續問題。

獨立下載 GDAL 及其依賴（CURL 和 GEOS）至 gdal 目錄下，並確保正確安裝。

對於 Libzip 和 zlib，下載較新版本的源碼並編譯為庫。使用第三方庫解決方案以解決與 VS2019+Cmake 的兼容問題。

構建流程

針對 OpenSceneGraph，創建 build 目錄並在 Cmake 中指定源碼路徑與編譯選項。關鍵配置包括 OSG_GL_CONTEXT_VERSION 3.3，以適應 OpenGL 版本要求。

在 osgEarth 的 build 目錄下，通過 Cmake-Gui 配置源碼路徑與關鍵選項（如 Curl、openthreads）。注意配置 GDAL、osg，並確保 Zip 插件使用較新版的 libzip 庫。手動下載 Lerc 源碼並解壓至指定目錄。Sqlite3 與 gdal 包共用。生成、配置並編譯項目。

驗證編譯結果

將編譯生成的 dll 等文件放置在指定目錄下。通過命令行進入 bin 目錄，執行 osgearth_viewer.exe 命令，載入測試文件，確認 osgEarth 正常運行。

總結

從源碼編譯 osgEarth 的全過程耗時約 8 小時，雖有挑戰，但最終成功驗證了編譯結果。此學習筆記旨在記錄整個編譯流程，提供參考與後續優化建議。祝大家在開發道路上越走越遠。