- 26 名前：ひげねこ ◆oxtErU/kVM mailto:sage [2008/03/26(水) 15:08:25 ID:xOARATeS]
- ガベコレ対策ですが、あえてトリック的な提案をします。
GCに関しては、技術的な情報ばかり先行してしまって、必要以上に警戒されすぎているという感があります。
GC発生絶対阻止と考えるよりも、逆にGC発生しても気にならないようにするという考えがあってもいいと思います。
例えば、GC発生時の遅延についてですがNyaRuRuさんの記事にあるように10万個のオブジェクトのチェックだけで
14ms掛かるとありますが、これが発生した場合でも、結論から言うとゲームのシミュレーション自体は問題なく動き続けます。
blogs.msdn.com/ito/archive/2007/03/08/2-update.aspx
この記事でいうところの、固定更新、処理落ち状態と同じで、GCが発生した次のフレームではUpdateは呼ばれるが
Drawはスキップされます。
次にGCの発生頻度はある程度プログラム側で制御できるということです。GC.Collectメソッドで好きな時にGC発生することができるので
後はメモリ確保による自動的に発生するGCの頻度を抑えることでかなりコントロールできます。
コントロールさえできれば、後はゲームデザイン的に気づかれない工夫をします。例えば強制スクロール形のシューティングだったら、
中ボス、ボス戦が開始する直前のイベントシーン開始時に敵キャラクタを見せるためのカメラのカットインとかが入るときに
その切り替わりを印象的にする為にカットインの瞬間に白で画面全体をフラッシュさせた後にフェードインさせるついでにGCをフラッシュした瞬間に
発生させたりといった隠蔽方法があります。
ゲームによっては画面の切り替え時のフェードイン・アウトの時なんかはGCするには最適な場所ですね。このフェードイン・アウトは
昔から時間の掛かる処理を隠すのに良く使われてた手法です。
通常、コードの最適化、アルゴリズムの最適化、そしてアーキテクチャの最適化の順に対費用効果が高まりますが、
ゲームの場合は、その更に上にゲームデザインの最適化というのがあるんですが、どうしてもプログラマ思考だとアーキテクチャの最適化までしか
考えず、煮詰まって企画の人と話したら数分で問題解決なんてことがあるんでゲームデザインの最適化はあなどれません。
|
 |
