C/C++程式設計

  BitMask是使用bit來表達True或false的概念，它可以使用一個int來表達多組的功能是否啟用。 先讓我們來看下圖： 若我們想要依照PlayerLevel跟Speed來進行排序的話，一般不知道這個技巧的人可能會使用二個int來處理這件事。在使用了BitMask之後我們就可以藉由將第一跟第三個bit設為1來表達這件事。在一般的C++中我們常常在enum的設定中就直接將該bit位移，如下面的code: https://gist.github.com/dorgonman/5c45efee5766a481c4db0d2f059eeed2     但在UE4中的Bitmask沒辦法使用跟上面一樣的做法，由於enum class被限制成只能使用uint8，因此在UE4中是直接將enum中的值當成位移數，如下面的code: https://gist.github.com/dorgonman/2fcb2068fdd4d044ebba7f8e5e299870 其中 int32 bitFlag = static_cast<int32>((1 << (int32)EHorizonPlayerSortType::Level) | (1 << (INT32)EHorizonPlayerSortType::Speed)); 就是模擬Blueprint中選擇要啟用哪個enum的C++實作。

本文章使用引擎版本：4.11 當我們將png或其他格式的圖檔放到Content這個folder下面，我們會發現引擎會自動把它轉成uassets的格式，之後我們就可以在editor中很方便的對它進行各種操作。但是，我們到底該怎麼樣用C++把這個檔案動態的讀進來？官方文件對這方面的文件實在是少的可憐，不過沒關係，原始碼就是我們最好的文件，深入引擎源碼閱讀之後，還是可以找到相關的方法。 簡單來說，引擎中所有的asset分為被控管(managed)以及沒被控管(unmanaged)二種： 被控管(managed)的asset副檔名為.uasset、.umap，會出現在editor的content browser中，我們可以直接在editor中對它進行各種操作，這些檔案包UMG、blueprint、material或匯進來的圖檔……等等。另外一些則是沒被控管(unmanaged)的檔案，如png、json……等等其他不是經過引擎處理所產生的檔案。 被控管(managed)跟沒被控管(unmanaged)的檔案其實都是可以動態的用C++讀進引擎裡面的，只是不同的是它們所要求的檔案路徑不同。前者要求的是LongPackageName，而後者要求的是實際的檔案路徑。 被控管檔案(managed)的讀取方法 讀取的方法目前我所知的有二種。 第一種是先在constructor中先拿到Class，然後再NewObject，下面的範例展示如果把一個做好的UMG讀進來： https://gist.github.com/dorgonman/b669fbc6382e938dc4262d80cb46b56e 其中CreateWidget只是對NewObject做一些檢查跟Widget相關的設定，最終還是會呼叫UUserWidget* NewWidget = NewObject<UUserWidget>(Outer, UserWidgetClass);。widget->AddToViewport()這個方法可以讓這個UMG顯示在營幕上。 只是這個方法有個缺點，就是所有需要用到的uasset都必須要先在constructor中先把其class讀進來。若是在其他地方呼叫ConstructorHelpers::FClassFinder的話則會馬上噴出一個錯誤：UE_CLOG(!ThreadContext.IsInConstructor, LogUObjectGlobals, Fatal, TEXT(“FObjectFinders can’t be used outside of constructors to find %s”), ObjectToFind); 因此要做到真正的動態讀取的話，我們可以使用第二種方法：FStringAssetReference。以下的code試著去讀取UMG、umap、flipbook跟UTexture2D：   https://gist.github.com/dorgonman/700b83f04da2ca8865745d9430759e6e 我們可以看到FPackageName::LongPackageNameToFilename，從範例中應該大概可以看出來這個方法的用途是什麼。它把我們餵入的package path轉換成檔案路徑。 餵入PackageFileNamePath:  /Game/UMG/NewWidgetBlueprint 轉成FileNamePath: ../../../../../../Users/dorgon/Documents/Unreal Projects/MyProject/Content/UMG/NewWidgetBlueprint.uasset 上述的方法雖然我們可以發現在editor模式下可以運行的很好，但是在打包出來的版本卻發現會無法讀入UMG或blueprint這二個asset。這是因為在cooked … Continued

2023 6月 Update：剛剛試4.27，現在只要在ProjectSetting把Allow Window Resize拿掉就行了 引擎版本：4.9，以下內容已經有點舊，僅供參考 最近在看各別解析度對應的方法，發現unreal engine 4裡面已經有DPI Scale來很好處理這一塊了。但其實這個機制其實也並不完美，因為玩家能夠亂拉視窗的大小，隨便亂拉的結果則會有些UI會跑到看不見，尤其是當視窗大小被拉成不是預期的狀態時，整個UI會變成很奇怪，這對於一個好的遊戲體驗是沒辦法接受的。 在我的預期上調整短邊應該要能夠scale位置，而調整長邊去scale大小。但這個DPI Scale機制最終其實也只能選擇直的或橫的來做處理。雖然有一個custom可以實作自己的類別，看起來似乎有那麼一點戲可以做到想做的效果，但實在有點麻煩，而且實作出來應該也只是對值的customize而已，而不是根據動作(上面說的位置、大小)，所以我開始在尋找禁止玩家去亂拉window大小的方法，最終目標是只在遊戲中提供幾個按鈕讓玩家選擇可用的解析度大小。這種做法也比較符合一般遊戲使用的機制，不用去煩惱那幾近無限的解析度適配的問題，只要我們提供的選項的aspect ratio是一致的，然後再根據我們的選項去把那個DPI Scale curve拉好，基本上就不會有什麼大問題。 為了這個問題我研究了好幾天，發現在void FWindowsWindow::Initialize這個function下面雖然有傳入一個FGenericWindowDefinition definition來指定這個視窗的樣式，但該參數並沒有開放給引擎的使用者進行調整，因為它在更上一層的FSlateApplication::MakeWindow被宣告成local的變數再傳進來的。那麼到底該怎麼去調整這視窗的樣式呢？ 看來引擎並沒有一個generic的api來做這件事，因此我們能做的就是針對各個平台拿出NativeWindow再進行對應的實作，以下的程式碼可以達成這件事： 在遊戲跑起來之後呼叫一次這個方法之後，總算能讓玩家不能去亂拉window的大小啦。 當然在其他平台，如mac或linux，則必須要再survey相關的實作才行(如果有需要的話)。