ゲームエンジンアーキテクチャー読書メモ
とりあえず気になった部分をメモって、あとで詳しくみていく。
- イベント(メッセージ)全般
- データドリブン全般
- 2.1 Googleでコードリポジトリをセットアップする
- おぉ、自宅で使ってみよう
- 2.4 メモリリークの破壊と検出
- そういうツールあるのか。調べてみよう。
- 3.2 浮動小数点のエンディアン変換のワナ(type panning)
- 知りませんでした
- 3.3 エラーの捕捉と処理
- 議論の余地あり
- 4.4.5 LERP or SLERP
- ゲーム数学一般は他の本で分かるので、こういう記事を増やしてほしかった。LERP派
- 4.5.6. デュアルクォータニオン
- スキニング問題(肘など大きく曲げたとき)の解消しかしらん。もう忘れたし、他にも有用な例があるかもしれないので、リンク先みとく。
- 4.7 SSE m128
- m128だと、仮にVector4をm128に持たせたして、C言語で一般的には有利なアドレス渡しfunc(const Vector4& v)をやると、レジスタ渡しにならないので実は損という話を書いてほしかったけど、自分でも確かめよう。
- 4.8 乱数生成
- メルセンヌツイスターって、なんかライセンスの問題なかったっけ?
- 線形合同法で作った乱数のテストほう
- 5.1 サブシステムのスタートアップとシャットダウン
- 全般的にいいこと言ってる。ただもうちょっと具体的にstatic Class hogeと書くことの危険性について書いてほしかった。P202の初期化の順番なんかはさりげなく書かれているけど、参考になる。個人的には、ゲーム本体のプログラムでは、リードエンジニア以外singleton禁止とかでもいい気がする。
- 5.2.1 動的メモリ割り当ての最適化
- 実はmallocがなぜ遅いのかの理由を知らなかった。コードをみたかんじ、SDKが提供しているのと、そんなかわらん気がしたけど、記憶違いかな?。
- 「ユーザモードからカーネルモードへのコンテキストスイッチが発生し、リクエストを処理し、戻るためのコンテキストスイッチが発生する。」すいません。知りません。ゲーム機のOSでも、こんなことやってる?
- 5.2.1.1
- 断片化即死、両側からメモリ確保は見たことあるなぁ。悪くないと思う。
- 5.2.1.4 単一フレームと二重バッファ型メモリアロケータ
- 使ったことないなぁ。おもしろい。
- 5.3.2.1 プレインクリメントvsポストインクリメント
- ん・・・分からん。イテレータではプレインクリメント++pが有利とな。
- 5.3.4 独自仕様のコンテナクラスを作成
- 自分としてはSTLありでもいいが、メモリの確保先ヒープだけははっきり分かるような形にしたい。
- この記事では、「自前で作ったコンテナクラスは、標準よりデバッガで値を見づらいので、工夫が必要」ということが書いてない。EASTLよさげ。
- Boostを使いたい人は、どの機能を使いたいのか知りたい。
- 5.4 文字列
- String+CRCにするのは必須でしょう。開発版ではstringは残しておきたい。ただ、開発版でもゲームデータを保存したデータをロードするとき、Stringの部分がすでに失われてしまうので、ロードしたデータはCRC値だけなのでデバッグしづらい。ここらへんでよい工夫ないかなぁ。
- 6.2.1.1 アセットのリビジョン管理
- シンボリックリンクを使う方法はうまいなぁ。
- 6.2.2.4 リソースGUID
- GUIDはハッシュ値でもいいけど、名前かパス名はどこかに保存しておかないと、バグを探すのが大変(最近の問題w)
- 6.
- P278は当たり前そうだが、できていないところ多し。
- アンチャーテッドの場合、ゲームで使うファイルはどのように分けているのか?アーカイブファイルはどのぐらいの大きさなのか?
- といった部分を
- 場合によっては、まだ読み込んでいない小さいファイルA,B,Cをバラで読むより、A,B,C,D,Eと余計なデータまで含まれた1個のアーカイブを読み込んだほうが速い。そのへんはリソースエディタで設定できるのか?
- 最近はハードディスクもあるので、前よりは悩みが減っているのだが。
- チャンクにすると断片化しても問題ないけど、ゲーム中のアセットのリロード(ゲーム中にキャラデータを一部差し替えて確かめたいとか)がとてもしづらくなるのでは?
- 7.5.5 ブレークポイントの処理
- タイマーのプログラムを書いたことがないので、あまり気にしてなかった・・・
- 7.6 マルチプロセッサのゲームループ
- [20]を読んでみよう。
- 7.6.5 ジョブ
- タスクモデルのほうが、損な気がする。特に技術力がないと向かない。
- うまく振り分けるのが難しい。スリープ多くなりがち
- マルチスレッドの問題を避けるための準備が必要。スレッドの役割が多いので、スレッド間のやりとりは避けられない。となると、イベント駆動(メッセージ)にして、スレッドセーフにしないとだめ。ここでバグを埋め込む可能性がいくらでもある。仮にバグがなくなったとしても、基本的にはイベント駆動のほうがデバッグが難しく、面倒なことも多い。
- ジョブモデルであれば、計算時間がかかり、独立したような関数を任せればいいだけなので、楽。
- タスクモデルのほうが、損な気がする。特に技術力がないと向かない。
- 9.
- うちのスタジオの人は、読んでほしいなぁ。こういう基本的な機能が実は重要ということに気づいてない人が多いので。
- 9.2 デバッグ描画API
- ここらへんは、トリプルバッファにすると、難易度が意外と高くなるので注意!
- デバッグ用の機能をどこにおくかという部分は議論の余地がある
- ゲーム内に軽めの(アンチャーテッドと同じ)
- ゲーム内に本格コンソール(Capcomのエンジンとか)
- ゲーム外(ウィンドウズ)
- 10. 省略(他の本読めば分かるので)
- 11.4.3 ローカルクロックとグローバルクロックの比較
- 常にグローバルクロック派だから悩んだことはないなぁ。ローカルクロックかつ、プレイヤーとNPCが並列実行されているときにおこる問題?
- 11.4.4.1 アニメーションのリターゲッティング
- 前にちょこっとどっかのページでみたけど、P516に文献あり。SIGGRAPH 2008
- 11.4.6 メタチャンネル
- UVの変化や足跡やサウンドなどはすぐに思いつくけど、時間とともに変化するマテリアル・ライティングのパラメータをアニメーションにもたせるってやったことないなぁ。どういう応用があるんだろうか。