基本的なスプライトバッチを使用するパーティクルシステムがあります。このシステムでは、0までの減少するアルファ値に基づいてパーティクルが作成および破棄されます。
システムのパフォーマンスはPCではかなり悪く、xboxでは非常に悪く、画面に約100個の粒子があり、かなりのfpsが遅くなります。パフォーマンスを改善する方法について読んだことがありますが、実装する方法についてのヒントはありますか？たとえば、kill（）ではなくパーティクルを再利用するための最良の方法は何ですか？各粒子の画像サイズに違いはありますか？各パーティクルを回転させない場合、これは役に立ちますか？
私はこれらの提案のそれぞれをいじってみましたが、大きな改善はありません-誰かアドバイスはありますか-CPUベースではなくGPUに行く価値がありますか？
私が覚えていることから、パーティクルを破棄して作成すると、パフォーマンスが大幅に低下します。パーティクルを再利用することをお勧めします。
画像が大幅に大きくない限り、画像のサイズや回転によってパフォーマンスが大幅に低下するかどうかはわかりません。
死んだ粒子をアクティブな粒子の最後に交換する配列があるため、アクティブな粒子のみを処理します。
例えば：
MAXパーティクルの配列を作成します。 パーティクルグラブが必要な場合particle_array[count]; インクリメントカウント。 パーティクルが死んだら、カウントをデクリメントし、パーティクルをparticle_array[count]と交換します。 カウントパーティクルのみを更新します。
お役に立てれば。
私は亜音速の答えに完全に同意しますが、それを拡張したいと思いました。
毎回新しいパーティクルを作成し、古いパーティクルを破棄（または手放す）すると、大量のゴミが発生します。特にXboxでのC＃のガベージ回避のマントラ（コンパクトフレームワークのガベージ処理が不十分なため）はnew、更新/描画ループでクラスタイプを使用しないことです。常にプールに事前作成します。Shawn Hの説明： http： //blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-paths-to-garbage-collector-nirvana.aspx。
考慮すべきもう1つのことは、複数のテクスチャを使用すると、複数の描画呼び出しが原因でスプライトバッチの速度が低下する可能性があることです。複数のパーティクルテクスチャを1つにマージして、ソースの長方形SpriteBatch.Drawパラメータを使用してみてください。