c++ - gamedev でのプログラミング (パフォーマンス関連)

Question

gamedevでいくつかのことがどのように機能するのか疑問に思っています:

1. 私は、パフォーマンスが実際に重要であることを知っています。そのため、管理された言語/プラットフォームを Java/.NET として使用する場所は、そのパフォーマンスのためだけにまだ (そして今後もないと思います) ありません。しかし...最近、SOのどこかで、ゲームを作成する人々がC++を主要言語として使用しているにもかかわらず、実際にはSTLまたはBoost(またはそれらの多く)を使用していないことを読みました。パフォーマンスと共通点があると思いますよね？私が間違っている場合は、それらのライブラリを避ける理由を教えてください (開発者の生活がずっと楽になると思います)。ライセンス（Boost）のせいですか？では、EA のバージョンの STL はどうですか? 他のスタジオも独自のバージョンを作成していますか?

2. ゲームプログラミングは実際にどの程度「メタルに近い」のか? より深く、機械に近づきますか？重要な内部ループに Assembly を使用することはありますか?それとも、実際に現在使用している抽象化レイヤーの最下層は C++ ですか? パフォーマンスが最も重要なことであるそのような製品では、プロファイリングは非常に一般的なタスクであると思いますが、一部のパーツを高速化するためにアセンブリを使用することを余儀なくされることがありますか、それとも優れた C++ で「十分」ですか?

編集：申し訳ありませんが、明確ではないかもしれませんが、ゲーム業界の経験を持つ人々からの回答に興味があります. 私は、ゲーム開発の商業的経験を持っていない人々によって与えられたいくつかの仮定には興味がありません. また、C#/Java で作成されたニッチなゲームの例にも興味がありません。ただし、FarCry2 よりも見栄えがよく (ほんの一例ですが、あなたのお気に入りのモダンで見栄えの良いゲーム名をここに示します)、完全に Java/.NET で記述され、FarCry2 と同様のパフォーマンスを備えた製品を知っている場合は、躊躇しないでください。この商品に言及してください！ありがとう。

Answer 1

1. 一部の考えに反して、STL は非常に最適化されており、悪いコードではありません。ほとんどのゲーム スタジオが使用しない理由はメモリです。独自のバージョンの STL コンテナーを作成する場合ほど、メモリの割り当てと割り当て解除を制御することはできません。これは、マネージ言語が好まれない理由でもあります。

独自のコンテナを作成すると、クロス プラットフォーム コードを記述し、メモリ トラッキングをより簡単に行うことができます。これは特に、PS3 などのコンソールで最高のパフォーマンスを引き出すためにハードウェアの詳細な知識が必要な場合に当てはまります。これは通常、最終的に、PPU、SPU、および RSX 間のメモリ フローを完全に制御する必要があることを意味します。

2. アセンブラは、数学ライブラリ関数などの非常に特殊な操作に対してのみ「必要」です (実際には必要ではありませんが役立つため、引用符で囲みます)。より一般的なのは、コードをベクトル化する SIMD 組み込み関数です。ただし、ほとんどのスタジオには非常に最適化されたレガシー コードがあり、これらの最適化は非常に低レベルであるため、ハードウェアの世代間で大幅に変更する必要があるコードではありません。コンソールでは、低レベルのコードを使用することがはるかに一般的です。

Answer 2

私は、パフォーマンスが実際に重要であることを知っています。そのため、管理された言語/プラットフォームをJava/.NETとして使用する場所はまだありません(今後もないと思います)。

いいえ、あなたはこれを知りません。あなたはそれを信じたいと思っています。なぜなら、あなたはゲーム開発を美化しており、高水準言語は高速ではないと考えているからです。.NET のパフォーマンスは、世の中に出回っているゲームの 90% で十分に優れています。そして、それは良くなるだけです。マネージド プラットフォームを遅くしなければならない固有の理由はありません。それらは JIT されているため、より高速になる可能性があります。実際には、それらのパフォーマンスは、適度に優れた C++ コードとほぼ同じである傾向があり、典型的なC++ コードよりもはるかに優れており、本当に優れた C++ コードよりもわずかに劣っています。とにかく、大規模なゲームのほとんどは複数の言語を使用しています。彼らは、Lua や Python などのスクリプト言語、または自家製のものを使用していますが、これらはすべて .NET よりも桁違いに低速です。

同様に、ゲームの大部分を .NET で作成できない理由はまったくありません。そして、パフォーマンスが非常に重要な 3 つの関数は、必要に応じて、後でネイティブ C++ に移植できます。

しかし...最近、SOのどこかで、ゲームを作成する人々がC++を主要言語として使用しているにもかかわらず、実際にはSTLまたはBoost(またはそれらの多く)を使用していないことを読みました。パフォーマンスと共通点があると思いますよね？私が間違っている場合は、それらのライブラリを避ける理由を教えてください

上記の有罪と同じ... ゲーム開発に関する迷信。「いやいや、他人のコードを使う余裕なんてありません！あまりにも非効率的です」。ゲーム開発は、プログラミングの実践と方法論の点で 80 年代にとどまっています。言い換えれば、他のゲーム開発者が何をしているかについてあまり心配する必要はありません。STL または Boost によってコードの記述が容易になる場合は、それを使用してください。次に、パフォーマンスの問題が発生した場合はプロファイルを作成し、必要に応じてその特定のライブラリ コンポーネントを独自のものに置き換えます。

しかし、ほとんどの STL は文字通りゼロ オーバーヘッドです。また、どのゲームのコードの 95%もパフォーマンス クリティカルではありません。ゲーム開発は、他のプログラミングと同じように扱ってください。コードのすべての行を完全に最適化する必要があり、通常のルールが適用されない魔法の土地として扱わないでください。

では、EA のバージョンの STL はどうですか? 他のスタジオも独自のバージョンを作成していますか?

私の知る限り、いいえ。EA はこれを内部使用のために部分的に作成しましたが、C++ コミュニティ全体へのインプットとしても作成しました。これは、彼ら (および多くのゲーム開発者) が標準の将来の改訂から見たいものの一例としてです (それは、規格委員会も）

Answer 3

私はその本をお勧めしC++ for game programmersます。STL、例外、RTTI などの C++ 機能のパフォーマンス コストについて詳しく説明しています。また、独自のメモリ マネージャーと、さまざまな一般的なパフォーマンスの最適化についても触れています。

新刊が出ているようですが、作者が違います。どうしたの？

Answer 4

約 1:

EA の STL バージョンは試していませんが、自分のゲーム開発経験から、STL がボトルネックになる場合があることを確認できます。これまでのところ、私は常に回避策を見つけることができました。

ブーストは非常に役立ちますが、パフォーマンスが重要なコードに役立つかどうかは、ブーストの特定の部分に大きく依存します。たとえば、Boost::filesystem は私にとって非常に便利でしたが、boost::signals はパフォーマンスが非常に低かったためほとんど使用できませんでした。そこで、代わりに FastDelegates を使用して独自のシグナリング ライブラリを実装しました。

約 2:

ほとんどの場合、通常の C++ コードで問題を解決できます。ゲームが実行され、プロファイラーでボトルネックを特定できたら、それらのコードの最適化を開始できます。その場合でも、適切に行えば、アセンブラー コードを記述する必要がない場合があります。

たとえば、カスタム ビルドの 2D ゲーム エンジンは、ハードウェア アクセラレーションなしで実行されます。私が開発したのは、3D ドライバーがまだ非常にバグが多く、ほとんどのカジュアル ゲーマーが古いグラフィック カード ドライバーを使用していたため、当時は純粋なパフォーマンスよりも互換性が重要でした。

それでも、私たちのゲームの最新ゲームである Gemsweeper では、8 ビットのアルファ マスクを使用した多くのアルファ ブレンディングを使用しており、ゲームは依然として 500 MHz の CPU で実行する必要があります。そのため、アルファ ブレンディングはパフォーマンスが重要な領域であることが判明しました。

これを最適化するために、私は VectorC コンパイラーを使用して、アセンブラー・コードを書かなくても MMX や SSE などを利用できるようにしました。しかし、同じコードでも 1 つの CPU では速く、別の CPU では遅くなることがあります (Intel と AMD など)。そのため、異なる最適化設定でアルファ ブレンディング コードを数回コンパイルしました。ゲームは実行時にベンチマークを実行して、ブリッティング メソッドごとに最速のブリッティング モジュールを見つけ、それ以降はそのモジュールを使用します。

結果を他のいくつかの 2D ブレンディング ライブラリと比較しました。そのうちの 1 つは純粋に手作業で最適化されたアセンブラーであると主張しており、異なる CPU で測定した場合、私のエンジンは平均してほぼ同じパフォーマンスでした。

結論: アセンブラを書き始める前に、最初に測定せずに最適化し、代替案を考えないでください。通常、これで十分な結果が得られ、多くの時間を節約できます。

Answer 5

'STL' (つまり、標準 C++ ライブラリ) と少量の Boost を使用します。ただし、その一部 (std::map、std::list、boost::shared_ptr) は、通常、過大なメモリ割り当てポリシーまたは貧弱なキャッシュ コヒーレンスのために回避または嫌われています。これらは通常、回避できます。カスタムアロケーターを使用していますが、代わりに、同じ問題に対して独自の利点を持つ他のアプローチがあります。

それが実際に金属にどれだけ近いかについては、それによって異なります. 私たちのプロジェクトでは、C++ が最低レベルです。このスタジオの別のプロジェクトでは、特に PC 以外のプラットフォームで、少し組み立てがあります。最近の特定のプロジェクトでは、CPU と同じように GPU によって制限される可能性が高いため、低レベルのコードを最適化する日が減り、シェーダーとアート アセットを最適化する日が増えています。

ただし、Java/.NET などは使用されていないと主張することには注意してください。すべての人が FarCry2 のパフォーマンスを必要としているわけではありません (これはかなり過剰な仕様です)。そのため、最適化のためだけに C++ を使用してマネージ言語で記述されたゲームがますます増えています。

Answer 6

ゲーム SDK を見れば、(ある程度) 自分で調べることができます。

ほとんどすべての id Tech 4 ゲーム (DooM III、Prey、Quake IV、ET:QW) には SDK があり、物理、スクリプト、AI、数学などのシステムが含まれています。使用される唯一の asm は特殊な数学コード用であり、それ以外はすべて純粋な C++ です。

Crytek には、Crysis SDK (SDK をインストールするにはゲームをインストールする必要があります) と Far Cry SDK があります。

Valve には、Steam を通じて Source ゲームを購入した人なら誰でも利用できる Source SDK があります。

見ればもっとたくさんあります。多くのコードは特にきれいでも柔軟でもありません (場合によっては高速でさえありません) が、理解するのが難しいテンプレート fu でいっぱいのモノリシック ライブラリとは対照的に、作成したコード内の調整は簡単だと思います。

Answer 7

ゲーム開発ではSTLが使われないのは事実です。特定の人々が常に急いで主張しているにもかかわらず、彼らは Java や C# などのマネージ言語をまったく使用していません。

X-Box Live Arcade のダウンロード可能な小さなゲームや Web ブラウザー ゲームなどについて話しているのではありません。AAA ゲームのハイエンド開発について話しています。

彼らはSTLを使用しません。ただし、STL によく似た独自のカスタム実装を使用しています。スマート配列、ハッシュ テーブル、スマート ポインターがあり、それらは STL ではありません。

コンソールには、PC とは大きく異なるいくつかのパフォーマンス特性があります。PC のみを対象とするゲーム プロジェクトでさえ、通常、過去にコンソール プロジェクトで使用されたコードベースを使用しています。基本的なテンプレート構造を希望どおりに機能させるために、多くの微調整が行われます。

ほとんどのゲーム スタジオは、他のプラットフォームに適応できるコードも必要としています。MS/Sony/Nintendo の実装にロックインすることは、ゲームを新しいプラットフォームに移植するときに、より多くの苦痛をもたらします。提供されているテンプレート ライブラリ (最初から STL である必要はありません) は、多くの場合、優れたものではありません。少なくとも、ハードウェア サイクルの早い段階で、スタジオが今後 5 年間使用し続けることを計画しているエンジンを解決している時点では、そのようになっています。

私が働いていたスタジオでは、サードパーティのコードを無視するかなりの程度の「ここで構築されていない」という態度を確かに見てきました。正当化される場合もあれば、そうでない場合もあります。基本的なデータ構造テンプレートの場合、通常はそうです。

2 番目の質問ですが、アセンブラは時々使用されます。ただし、大量の計算を非常に頻繁に行う必要がある孤立した状況でのみ。エンジン全体には、asm ブロックの小さいファイルが 2 つまたは 3 つ含まれている場合があります。

Answer 8

いいえ、あなたは大きく間違っています。.NET と Java はどちらも商用ゲームで使用されており、Windows でも (おそらくコンソールでも) 使用されています。

STL も広く使用されており、かなりの割合のアマチュア ゲーム開発者が STL を使用していることを知っています。

おそらく、STL を使用しない主な理由は慣性であり、そうでないサードパーティのライブラリ/エンジンを使用することです。

歴史的に、一部のプラットフォームでは、特に PS2 のような RAM に制限のあるものでは、適切な STL 実装が利用できなかったと思います。