GameEngineArchitectureTalking_Chapter5

ゲームエンジンアーキテクチャを読んで討論会をした時のスライドです．
5章エンジンサポートシステムについて，自作する場合に比べてUnityを使用することでの制約について主に焦点を置いています．
何らかの役に立てば幸いです．

Transcript

1. GameEngine輪講 5章 エンジンサポートシステム AkiIro
2. 5.0 はじめに 書籍にない情報の提供を意識した方が有意義 →ところどころ寄り道を意識 とはいえ，テーマはあった方が一貫性はある →寄り道をする上で何かしらの軸は欲しい よって 既存の知っているゲームエンジン(Unity)を使った場合に どのような拘束があるかを考えつつ，進めようかと思います
3. エンジンサポートシステムとは エンジンのスタートアップ，シャットダウン エンジンおよびゲームのコンフィグレーション エンジンのメモリ管理 ファイルシステムへのアクセス，アセットに対するアクセス デバッグツール このあたりの機能の提供を行うシステムのこと
4. 既存のエンジン(Unity)で 言うところの何だろう?
5. ヒットしない上，怪しめの広告が多めです
6. 経験的には エンジンのコンフィグとして ProjectSettings等 ファイルシステムへのアクセスをラップし ているものとして Resources.Load メモリ管理をラップしているものとして Resources.Load SceneManager.LoadScene あたりがパッと思いつく 当然容易にはカスタムはできなそう
7. 本筋に戻ります
8. 5.1 サブシステム 起動と終了 ゲームエンジンは相互作用のあるサブシステムをたくさん持つ →特定の順序で起動する必要がある C++のグローバルかつStaticなオブジェクトのコンストラクタの順は予測不能 →独自に実装する必要がある
9. 5.1 サブシステム 起動と終了 解決案1 オンデマンドのコンストラクタ呼び出し 関数内で静的変数を宣言する．(例えばget関数の中) →その変数は関数が最初に呼び出されるときにコンストラクタが呼び出される
10. 5.1 サブシステム 起動と終了 解決案1 オンデマンドのコンストラクタ呼び出し static RenderManager& get() { static RenderManager sSingleton; return sSingleton; } デストラクタの順序がコントロールできない 遅延初期化になるため，最初の呼び出しがいつになるか明確にわからない 結局よくない実装
11. 5.1 サブシステム 起動と終了 解決案2 単純な実装 コンストラクタとデストラクタには何もさせず， スタートアップとシャットダウンの関数を明示的に定義する →力ずくの方法ではあるが，要求された順番で明示的に呼び出すことができる void startUp(){.....} void shutDown(){.....}
12. 5.1 サブシステム 起動と終了 解決案2 単純な実装 以下のメリットがある ・単純で簡単に実装できる ・明示的である ・簡単にデバッグして保守できる
13. 5.2 メモリ管理 動的メモリ割り当ては非常に低速である． →完全に避けるか，独自仕様のメモリ割り当てが望ましい メモリアクセスパターンによってパフォーマンスが大きく変わる →連続したブロックのメモリに位置することが望ましい
14. 5.2 メモリ管理 動的メモリ割り当ての最適化 動的メモリ割り当てを完全に避けられるゲームエンジンなどない 標準の関数(malloc()やfree())は汎用的に作られていて遅い →独自アロケータを用いる． ※アロケータとは... メモリの割り当てや解放を行うためのオブジェクト のこと 参考 http://ppp-lab.sakura.ne.jp/cpp/library/028.html
15. 5.2 メモリ管理 動的メモリ割り当ての最適化 その1 スタックベースのアロケータ 大規模な連続したメモリブロックを割り当てる →実装が簡単 メモリの割り当てと解放は常にLIFOのような感じ 確保したメモリの両端からこれを行うと 両端スタックアロケータになる →役割を分け，メモリ断片化を回避
16. 5.2 メモリ管理 動的メモリ割り当ての最適化 その2 プールアロケータ 割り当て要素の倍数となる大きなメモリブロックを確保する 割り当て = 空き要素リストから空き要素を返す 解放 = 空き要素リストに戻す 割り当ても開放もO(1)時間
17. 5.2 メモリ管理 一時的なメモリのバッファ 単一フレームアロケータ 全てのフレームの最初にバッファが消去されるスタックアロケータ 高速だが扱いが難しい(フレームを超えてポインタを保持してはいけない) 二重バッファアロケータ 次のフレームまではバッファを保持 アクティブバッファをスワップすることで，非同期処理を行っても使用中に突然上書きさ れない
18. Unityでのメモリ管理の自由度は?
19. ありました．ありがとうございます． 参考 http://sssslide.com/speakerdeck.com/cygames/unityniokerumemoriguan-li-1
20. Unityにおけるメモリ管理の制約 かいつまむと... メモリの管理が二種類存在 ・Mono管理 ・Unity管理 どちらも特定のAPIを叩くことで 参照されていないインスタンスを破棄する
21. Unityにおけるメモリ管理の制約 重要なのは，ざっくり言ってDestroyではメモリは解放されず， 参照を外してから特定のAPIを叩く必要がある点です 正直，思いのほか わりと面倒だとわかりました
22. 5.3 コンテナ コレクションともいう ・配列 ・動的配列 ・連結リスト ・スタック ・キュー....etc
23. 5.3 コンテナ 独自仕様のコンテナ 以下のメリットがある ・全体コントロールが可能 ・最適化の機会の確保 ・カスタマイズ可能 ・外部依存性の排除 ・並列データ構造のコントロール 独自仕様以外ではSTL,STLport,Boostが選択肢
24. Unity(C#)の場合は?
25. C#における独自コレクションクラス ICollectionインターフェースを実装したクラスを作ればいい 基本的にどのようなデータ構造でも作れそう 拘束があるとすれば単純に言語依存の速度? →実質的に有意な差にはならないと思われる
26. 5.3 コンテナ 連結リスト 非侵入的リスト リンクデータ構造が要素データ構造から分離 要素が複数のリストに同時に存在できるが，リンクオブジェクトを動的に割り当てる必要 がある 侵入的リスト リンクデータ構造と要素データ構造が同じクラス内 動的にリンクの割り当てをしなくてよいが，要素は複数のリストには存在できない
27. 5.4 文字列 基本 文字コード 何らかの規格化された文字の表し方(ex.U+0041ならA) 文字一覧を示すCharsetという意味で使われることもある 文字集合 同じ体系を持つ文字コードの集まり．文字セット(ex.Unicode) エンコーディング 文字と文字コードをマッピングする方式(UTF-8) 参考 http://d.hatena.ne.jp/cero-t/20110614/1308063484
28. 5.4 文字列 Unicode 基本の考え方は地球上で慣用となっているすべての言語からのあらゆる文字や記号を ，符号位置という一意の16進数のコードに割り当てることである ただし，最上位のUnicode位置は0x10FFFF つまり，21bit必要 16bit(4byte)で表せる範囲にある文字がBMP(それ以外はSMP) B->Basic，S->Supplementary
29. 5.4 文字列 Unicodeのエンコーディング UTF-32 最も単純，固定長 UTF-8 一部が2byte以上(可変長)，ANSIに上位互換性を持つ UTF-16 可変長，必要に応じて2つの連続した16bit値で表す UCS-2 固定長，UTF-16の基本多言語面のみ．表せない文字がある ※ANSI Shift-JISにMSが独自拡張を加えたもの
30. 5.4 文字列 charとwchar_t 標準C/C++ライブラリの文字列を処理する2つのデータ型 char UTF-8を含む，レガシーなANSIやマルチバイト文字セット用 wchar_t 単一の整数にある有効な符号位置をすべて表せる 　　　 コンパイラとシステムによって大きさが異なる
31. 5.4 文字列 Windows上のUnicode char ANSI文字列とレガシーなWindowsコードページの文字列用 wchar_t UTF-16でエンコードされたUnicode文字列専用 ただしUnicode文字列は一般的にはマルチバイトUTF-8でエンコードされる Windowsが特殊
32. Unityでの文字の扱いは?
33. Unityでの文字列 マニュアルによるとUnicodeをサポート スクリプトをはじめ，エンコーディングはUTF-16 この辺りはUnityからの制約を受ける →ややメモリに対して非効率 マニュアルにUnitronという記述があって何かと思って調べてみると， どうやらUnity3.3時代のエディタのことである模様 参考 https://docs.unity3d.com/jp/540/Manual/class-Font.html
34. C#における文字列 UTF-16を前提としており，charが2byte整数 stringは以下の特徴を持つ ・先頭に文字列長を4Bytes整数で記録 ・続けて、リトルエンディアンのUTF-16で符号化されたバイト列が並ぶ ・最後にnull文字
35. 5.5 コンフィグ オプションの実装選択肢 テキストファイル バイナリファイル レジストリ コマンドラインオプション 環境変数 オンラインユーザープロファイル このあたりはUnityを使ってもほぼ変わらない
36. まとめ エンジンサポートシステムは奥が深く，効率化には避けて通れない． Unityのような完成度の高いエンジンでは隠蔽されている． エンジンを低レベルから作ることで完全制御による効率化やカスタマイズ可能性を得ら れる． 特にメモリ管理はCやC++を使わないと勉強不足になる． 文字は意外と難しい．
37. ご清聴ありがとうございました．