4

C# でタイルベースのマップ エディターを作成するときは、X 軸と Y 軸を反復処理し、Graphics.DrawImage() を呼び出して、タイルセット ビットマップからマップ ビットマップに 1 つのタイルを配置する傾向があります。このプロセスは完了するまでに数秒かかるため、新しいマップをロードするときやタイルセットを変更するときに一度だけ実行します。それ以降の編集は、編集されたタイルのみの比較的高速なブリットです。

さて、今日は早めに腰を下ろして、自分の選択肢について考えました。Graphics.DrawImage() は、ソースの原点の指定を可能にする 3 つ (他は DrawImageUnscaled と DrawImageUnscaledAndCropped(?)) のうちの 1 つだけです。DrawImageUnscaled() ははるかに高速でしたが、常にソース ビットマップの左上からブリットされていました。

QuickBasic PSET とビデオ メモリの POKE の速度、または VB6 の PSet と WinAPI の SetPixel の速度とは対照的に、単純な Get/SetPixel ループは、DrawImageUnscaled 呼び出しと同じくらい高速でしたが、DrawImageだけが行うクロッピングを行いました。

今のところはこれで十分ですが、画像を直接操作するような方法でさらに高速化できるのではないかと考えていました。おそらくLockBitsの何か、私がほとんど知らない機能ですか？

4

2 に答える 2

1

ソフトウェアブリッティングは深刻なボトルネックのようです。このようなタスクのために、ハードウェアアクセラレーションによる描画を検討することを真剣に提案します。

于 2009-06-12T19:04:41.810 に答える
1

単純な Get/SetPixel ループは、DrawImageUnscaled 呼び出しと同じくらい高速でした

それなら、あなたは間違いなく何か間違ったことをしています。GetPixelandSetPixelメソッドにはかなりのオーバーヘッドがあり、どのメソッドを使用しても100DrawImage倍高速になるはずです (タイルが 2x2 ピクセルのように非常に小さい場合を除きます)。

その名前に反して、DrawImageUnscaled メソッドはサイズ変更なしでは描画されません。代わりに、画像の PPI 設定を使用して、同じ測定値にスケーリングします。つまり、設定が 100 PPI のビットマップがあり、その上に設定が 50 PPI のビットマップを描画すると、2 倍のサイズにサイズ変更されます。

サイズを変更せずに画像を描画している場合は、Graphicsオブジェクトの品質設定を変更して速度を微調整できます。たとえば、InterpolationModeプロパティをNearestNeighborに設定して、補間を行わないようにすることができます。

ビットマップ上に描画する代わりに、ビットマップのピクセル データを直接使用LockBitsしUnlockBitsてアクセスすることもできます。

于 2009-06-12T19:30:41.153 に答える