1

私は長蛇の列を書くつもりでしたが、ここでそれを要約します：

XNAを介してNESのグラフィカルなオールドスクールスタイルをエミュレートしようとしています。ただし、私のFPSは低速で、フレームあたり65Kピクセルを変更しようとしています。すべての65Kピクセルをループして任意の色に設定すると、64FPSになります。どの色をどこに配置するかを調べるために作成したコードで、1FPSを取得します。

オブジェクト指向のコードが原因だと思います。

現在、私は物事を約6つのクラスに分けており、ゲッター/セッターがいます。少なくともフレームごとに360Kのゲッターを呼び出していると思いますが、これはかなりのオーバーヘッドだと思います。各クラスには、カスタム列挙、int、Color、またはVector2Dバイトを含む/および-または1Dまたは2D配列が含まれます。

すべてのクラスを1つにまとめて、各配列のコンテンツに直接アクセスした場合はどうなりますか？コードは混乱しているように見え、オブジェクト指向コーディングの概念を捨てますが、速度ははるかに速いかもしれません。

配列内のデータを取得/設定しようとするとブロック単位で実行されるため、アクセス違反についても心配していません。たとえば、配列へのすべての書き込みは、配列からデータにアクセスする前に行われます。

キャストに関しては、カスタム列挙、int、Color、およびVector2D、バイトを使用していると述べました。 .net Framework、XNA、XBox、C＃で最も速く使用およびアクセスできるデータ型はどれですか？絶え間ないキャストがここでのスローダウンの原因かもしれないと思います。

また、数学を使用してデータを配置するインデックスを決定する代わりに、事前に計算されたルックアップテーブルを使用したので、フレームごとの定数の乗算、加算、減算、除算を使用する必要はありません。:)

4

4 に答える 4

4

XNA開発者であれば、読む価値のあるGDC2008のすばらしいプレゼンテーションがあります。これは、 XNAフレームワークのパフォーマンスの理解と呼ばれます。

現在のアーキテクチャでは、明確な答えを出すのに十分なほど十分に説明されていませんが、タイトなループで不要な「作業」をやりすぎている可能性があります。推測しなければならない場合は、現在のメソッドがキャッシュをスラッシングしていることをお勧めします。データレイアウトを修正する必要があります。

理想的なケースでは、可能な限り小さい値型（クラスではなく構造体）の素晴らしい大きな配列と、データを線形に押し込む非常にインライン化されたループが必要です。

（余談ですが、高速について：整数および浮動小数点の計算は非常に高速です-一般に、ルックアップテーブルを使用しないでください。関数呼び出しは非常に高速です-大きな構造体を渡すときにコピーする方が重要です。 JITは、単純なゲッターとセッターをインライン化します。ただし、ブリッターのように、非常にタイトなループで他のものをインライン化するためにJITに依存するべきではありません。）

ただし、最適化されていても、現在のアーキテクチャは最悪です。あなたがしていることは、現代のGPUがどのように機能するかに直面して飛んでいきます。スプライトをGPUにロードし、シーンを合成させる必要があります。

スプライトをピクセルレベルで操作する場合（たとえば、前述のようにパレットの交換）、ピクセルシェーダーを使用する必要があります。360（およびPC）のCPUは高速ですが、このようなことをしているときはGPUがはるかに高速です！

Sprite Effects XNAサンプルは、始めるのに適した場所です。

于 2010-06-11T02:49:09.330 に答える
4

コードのプロファイルを作成して、速度低下がどこにあるかを判断しましたか？アプリケーションを書き直す前に、少なくともどの部分を書き直す必要があるかを知っておく必要があります。

アクセサーとデータ変換のオーバーヘッドは取るに足らないものだと強く思います。アルゴリズムが不要な作業を行ったり、キャッシュできる値を再計算したり、オブジェクトの設計を爆破することなく対処できるその他のことを行っている可能性がはるかに高くなります。

于 2010-06-10T21:13:56.873 に答える
1

ピクセルごとに色などを指定していますか？もしそうなら、あなたは本当にアーキテクチャについてもう少し考えるべきだと思います。物事をスピードアップするスプライトの使用を開始します。

編集

さて、あなたの解決策は、異なる色のいくつかのスプライト（数ピクセルのスプライト）をロードし、それらを再利用できると思います。スプライトはすでにメモリにロードされているため、各ピクセルに異なる色を割り当てるよりも、同じスプライトを指す方が高速です。

于 2010-06-10T21:12:54.160 に答える
0

他のパフォーマンスの問題と同様に、推測するのではなく、アプリケーションのプロファイルを作成してボトルネックを特定する必要があります。ゲッターとセッターがあなたの問題の根本にあるのではないかと私は真剣に疑っています。コンパイラは、ほとんどの場合、これらの種類の関数をインライン化します。私はあなたが数学に対して何を持っているかも興味があります。たとえば、2つの整数を乗算することは、コンピューターが実行できる最速のことの1つです。

于 2010-06-10T21:14:56.083 に答える