まず、エンジンのテストケースとして簡単なゲームを計画することをお勧めします。基本的なゲームがあると、機能とAPIの開発が促進されます。明確な目標を持たずにエンジンを作成すると、プロジェクトのリスクが高まります。パフォーマンス上の理由から、nVidiaとATiを別々のターゲットとして扱う必要があることに同意しますが、どちらから始めないことをお勧めします。
私は個人的にUncharted:Drake's Fortune(PS3ゲーム)の物理エンジンを作成し、C ++でパスを作成し、それが機能したら、パスを作成してVMX用に最適化し、SPUに配置しました。時間の制約があるため、最初にやりたかったことのほんの一部を実行しました。その後、データステージを分割し、データ変換のパイプラインを作成するための反復を行いました。CPU、GPU、SPUのいずれであっても、重要なコードを実行する最新のプロセッサは、ほとんどの時間をキャッシュの待機に費やすため、これは重要です。データ構造に特別な注意を払い、それらをパイプライン化して、どの段階でも小さなワーキングセットのデータが得られるようにする必要があります。たとえば、最初にブロードフェーズを実行するので、シェイプは必要ありませんが、ワールドスペースバウンディングボックスが必要です。そこで、境界ボックスを別々の配列に分割し、別のパスでそれらをすべて一緒に計算します。最適な方法でそれらを書き出します。bbox計算への入力として、形状変換とそれらからのいくつかの境界が必要ですが、必ずしも形状全体ではありません。ブロードフェーズの後、シムアイランドを計算/更新すると同時に、実際にシェイプが必要なナローフェーズを実行します。など-私はこれを記事の写真で説明しました私が書いたゲーム物理学の真珠。
私が言おうとしているのは、次の点だと思います。
- 開発を推進する明確な目標があることを確認してください。フラッシュアウトされたデザインの非常に基本的なゲームは、ゲーム物理エンジンの場合に最適です。
- 製品が機能する前に最適化を試みないでください。最初に可能な限り最も単純で最速の方法でそれを書き、数学のすべてのバグを修正してください。後でCUDAに移植できるように設計しますが、画面上でボックスが回転する前にCUDAカーネルの作成を開始しないでください。
- C ++で最初のパスを記述したら、CPU用に最適化します。キャッシュを破棄しないように合理化し、呼び出しのスパゲッティがなく、各ステージのすべてのコードがローカライズされるようにコードを区分化します。これは、a)CUDAへのポートb)OpenCLへのポートc)コンソールへのポートd)適度に高速に実行するe)デバッグを可能にするのに役立ちます。
- 開発中は、明確な目標にその機能が必要ない場合を除いて、今考えたことをやりたいという誘惑に抵抗してください(#1を参照)。そのため、目標に向かって進み、実際のプロジェクトを完了できるようにするために、目標が必要です。 。気晴らしは通常、明確な目標なしにプロジェクトを殺します。
- 何らかの形で、ソフトウェア開発は反復的であることを忘れないでください。ラフインを行ってからそれを改良してもかまいません。革、すすぎ、繰り返し-それはプログラマーのマントラです:)
アドバイスをするのは簡単です。あなたが何かをしたいのなら、ただ行ってそれをしてください、そして私たちは座って批評します:)