Share via


消えたResolveBackBufferとResolveTexture2D

Game Studio 4.0ではResolveBackBuffer APIとResolveTexture2Dクラスが削除されました。

このAPIは基本的なRenderTarget2D(GPUによって描画された結果がテクスチャとなる)と同様のもので、多少の違いがあるだけでした。重複する機能を提供することが常に悪いこととは限りませんが、完全に同じ機能を提供するときには注意が必要です。

重複している機能を提供する場合、それらの機能を提供したと仮定して、フレームワークを使っている人たちからの「どっちを使ったら良いの?」という質問にどう答えるかが判断基準となります。もし「BよりもAを使うと良いよ。Bのことは忘れちゃってください」や「どっちを使っても緒だよ」と答えるようであれば、二つとも提供する必要はないということになります。

以下は、ResolveBackbufferとRenderTargetの二つを提供した場合のガイダンスです。

  • レンダーターゲットの方が自由度がある。ResolveBackBufferはキャプチャーしようとしているサイズとバッグバッファのサイズとフォーマットが一緒ではないといけない。
  • ResolveBackBufferは、RenderTargetを使う必要がなく、自分がコントロールできないコードが描画した最終画像をキャプチャーする時に便利。
  • メモリ使用量に大きな差はない
  • パフォーマンスはプラットフォームによって違う
      RenderTarget ResolveBackBuffer
    Windows 速い マルチサンプリングなしの場合は遅い。レンダーターゲットがマルチサンプリングを使用している場合は同じ速度。
    Xbox 360 速い レンダーターゲットと同じ速度
    Windows Phone 速い ポートレートモードの時には同じ速度。ランドスケープモード時には極端に遅くなる

結果として、パフォーマンスを気にするのであればレンダーターゲットを常に使うべきということになります。ResolveBackBufferは場合によって変わってきますが、レンダーターゲットを使うよりも速くなることはありません。

<余談>

パフォーマンス差を隠蔽するような互換性を提供することは非常に複雑な問題です。すべてのプラットフォームで同一のパフォーマンスを提供することは明らかに無理っ!(Windows PhoneはXbox 360よりも確実に遅いプラットフォーム)。また同等のパフォーマンス特性を提供することもできません(PC上でCPUがボトルネックなっているゲームを、他のPCで動作させるとGPUがボトルネックになったりする)。だからといって、パフォーマンス差を完全に無視するというわけではありません。例えば

アリスが「非線形四元張寸(Flobydryglap)アルゴリズムの実装方法」というチュートリアルを書いたとします。アリスはXbox 360開発者で、レンダーターゲットとResolveBackBufferの二つにパフォーマンス差がないことに気づいたので、たまたまResolveBackBufferを使うことに決めました。

このチュートリアルを見たボブは、Windows Phone上で使ってみることにしました。ですが、あまりのパフォーマンスの低さにがっかりしてしまいました。友人のチャーリーが見てみると、ボブがランドスケープモードを使っていることが原因だと気づきます。レンダーターゲットを使う方式に変更したところ、数倍の速度を得ることができました。

厳密にいえば、このコードは「動いた」訳ですが、パフォーマンス差が特定のプラットフォームに特化したコードとなってしまいました。

</余談>

 

では、パフォーマンスを気にする必要がない人たちにとってはどうでしょうか?パフォーマンス差を気にせずにバックバッファからデータを読み込みたいケースというのはあるのでしょうか?私たちは以下の二つのケースがあると考えました。

  • スクリーンショットを生成するとき
  • ユニットテストなどで、描画結果を確認するとき

両方ともGPUのテクスチャメモリではなく、バックバッファーのデータをCPUによってメインメモリにコピーします。そこで、私たちは以下の変更をすることにしました。

  • ResolveBackBufferとResolveTexture2Dを削除
  • GraphicsDevice.GetBackBufferData APIを新しく追加。これは以前のResolveBackBufferをしてからResolveTexture2D.GetDataを呼び出すのと同じ機能を提供します。

GetBackBufferDataはCPUによる読み込みをします。ですから、どのプラットフォームでも速度はでませんが、スクリーンショットやユニットテストをするのには便利なAPIです。このことによって、「余談」の中にあるようなプラットフォーム間でのパフォーマンス差に驚くような場面もなくなった訳です。

 

 

と、いうのが計画だったのですが、

最近になってから、D3Dランタイム、コンポジッター、そしてイメージスケーラーの関係でWindows Phone上ではGetBackBufferData(同様にResolveBackBufferも)を提供できないということに気づきました。

そんな訳なので、しぶしぶながらこの機能をReachプロファイルからGetBackBufferDataを外すことになりました。Game Studio 4.0としてはサポートしていますが、Windows、Xbox 360上のHiDefプロファイルのみでのサポートとなります。これはハードウェアではなく、ソフトウェアの問題なので将来のバージョンではReachプロファイルでも使用できる可能性があります。ですが、他に優先度の高い作業で忙殺されているので、4.0のリリース向けにはこの問題は解決できませんでした。

原文:

http://blogs.msdn.com/shawnhar/archive/2010/03/30/resolvebackbuffer-and-resolvetexture2d-in-xna-game-studio-4-0.aspx