プログラマ専用SNS ミクプラ

梨丸かじり さんが書きました:DirectX11まで出ているにもかかわらずDirectX9安定だったとは･･･

Fimbul さんが書きました:それぞれ、リリース版、デバッグ版、だと聞いたのですが、何が違うんでしょうか。

Fimbul さんが書きました:「D3DX」は拡張機能ライブラリだと聞いたので、「Direct3D eXtend」当りの略だと私は思ったのですが。

ISLe さんが書きました:デバッグ版は問題箇所の発見に役立つ代わりに実行速度が遅いです。

ISLe さんが書きました:公式の記述は無いみたいですがたぶんそうでしょうね。

Fimbul さんが書きました:普段はデバッグ版を用いて、リリースビルドの時にリリース版を用いるのが無難なのでしょうか。

ISLe さんが書きました:マイクロソフトの開発製品(無償配布のSDK含む)はライセンス上、デバッグ版ライブラリの配布が許可されていません。
なので、デバッグビルドした実行形式を他人に渡すこともできません。

Fimbul さんが書きました:

ISLe さんが書きました:マイクロソフトの開発製品(無償配布のSDK含む)はライセンス上、デバッグ版ライブラリの配布が許可されていません。
なので、デバッグビルドした実行形式を他人に渡すこともできません。

と言う事は、掲示板で質問等をする時にライブラリを一緒にアップ出来ないんですね・・・

Fimbul さんが書きました:3Dモデルの描画の話です。

１　モデルの描画をPeekMessageでメッセージ処理がない時に行う
２　モデルの描画をWM_TIMERやWM_PAINTで行う（PeekMessageでなくGetMessageを使う）

どちらがいいんでしょうか。

Fimbul さんが書きました:WM_PAINTは無効領域が生じたら発行されると聞きました。
ですが、DirectXではウィンドウを隠したりWM_TIMERでInvalidateRect等を呼び出さなくても発行されている気がします。
モデルやカメラ、ライトを操作したりするとWM_PAINTが発行されるのでしょうか。

ISLe さんが書きました:ウィンドウプロシージャでWM_PAINTに対してBeginPaint,EndPaintを呼ばずにリターンすると無効領域がクリアされないままなのでWM_PAINTがいつまでも発行され続けますけど。
WM_PAINTに対してBeginPaint,EndPaintを呼び出して戻り値0でリターンするか、ハンドリングしないでDefWindowProcを呼び出してそのまま戻り値とするかどちらかが必須です。
Direct3Dを使うプログラムなら後者ですね。背景ブラシもNULLにして。

Fimbul さんが書きました:背景ブラシもNULLにしましたが、これは何のためなんでしょうか。

Fimbul さんが書きました:また、ウィンドウを表示させて何もしなくてもなぜかWM_PAINTが発行されてました。
ウィンドウを表示した直後に無効領域が生じるか、WM_PAINTが発行されるようになっているのでしょうか。

ISLe さんが書きました:ウィンドウが最初に表示されるときにはもちろんクライアント領域が描画されなければならないので、最初はクライアント領域全体が無効領域です。
なのでクライアント領域が見えないからといってWM_PAINTを処理しないでおくとウィンドウを開いたときからずっと発行され続けることになります。

/*良く見る方法*/

//BeginScene

//モデルやカメラ、ライトの計算（移動とか）

//モデルの描画（DrawSubsetとか）

//EndScene

/*私が思った方法*/

//モデルやカメラ、ライトの計算（移動とか）

//モデルの描画（DrawSubsetとか）

//BeginScene

//EndScene

ISLe さんが書きました:実際にどのように動作するかはGPU側の実装によりますが、GPU側にとっては命令がバラバラに送られるより、まとめて送られたほうが最適化しやすく、BeginScene/EndSceneはひとまとまりであることを示すための目印となります。

ISLe さんが書きました:BeginScene～EndSceneのあいだにカメラやライトを変更すると最適化の邪魔になってパフォーマンスに少なからず悪影響を与えると思います。

Fimbul さんが書きました:ただ、マテリアルやテクスチャを変えたり、FVFで描画するためにライトを無効する処理はどうしても描画したいモデルの直前（BeginSceneとEndSceneの間）で行う必要があると思います。
これは、仕方がないのでしょうか。

Fimbul さんが書きました:なぜポイントスプライトの見かけの大きさが変わらないんでしょうか。

ISLe さんが書きました:もっと重要なのはEndSceneのあと、Presentでデバイス画面を更新するまでのあいだ上手にGPUのレンダリングと並行して処理を進めることです。
EndSceneの直後にPresentしたりするとレンダリングが完了するまで無駄に待つことになります。

ISLe さんが書きました:そういう仕様だからとしか言えないのですが…。
D3DRS_POINTSCALEENABLEをTRUEに設定すればカメラからの距離に応じたサイズに調整されるみたいですけど。

Fimbul さんが書きました:EndSceneの後、GPUがデータを受け取って描画を行い、バックバッファとフロントバッファを入れ替えるまでに、「GPUの描画処理時間以下の処理時間の処理」を行うと効率が良いと言う事でしょうか。

ISLe さんが書きました:trueにしてあるんですけどね・・・。
ポイントスプライトにテクスチャを貼ってビルボードの代わりに出来ないかと思ったのですが、「まあポイントスプライトはこういうものだ」と思って使うのは諦めます。

ISLe さんが書きました:GPUが働いている時間以下の処理でなければならない理由はないですね。
GPUとプログラムの処理のどちらが先に終わるかではなくて、互いに相手の処理が終わるのを待っている無駄な時間を少なくすることに意味があるので。

ISLe さんが書きました:ポイントスケール係数(D3DRS_POINTSCALE_A/D3DRS_POINTSCALE_B/D3DRS_POINTSCALE_C)を設定してないから大きさが変わらないとか。
どのみちポイントスプライトのサイズ計算は透視変換とは異なるのでビルボードの代わりにはならないですけどね。

Fimbul さんが書きました:GPUが描画を完了したらバッファを入れ替えて表示をしますよね。
描画が完了した時に、別の処理をしていてすぐにバッファを入れ替えられないと無駄な時間が発生しませんか。

ISLe さんが書きました:フレームレートを一定に保つため、レンダリングが完了してからバッファを入れ替えるまで時間が空きます。
そのあいだメインCPUを何もせず待たせるのはもったいないですよね。
フレーム落ちしなければどちらが後でもかまわないのですよ。

例えば背景のモブとか他のオブジェクトに影響与えないオブジェクトの内部処理を前のフレームから進めておいて、バッファを入れ替えたらすぐにシーンをプッシュ、レンダリングしている間にメインオブジェクトの内部処理を行いシーンをプッシュ…と交互に進めると並行処理を活用できます。

描画だけなら手前のオブジェクトから描画するほうが速かったりとかありますけど、並行処理を絡めると逆転することがいろいろあります。
負荷のバランスはゲームタイトルごとに、環境にも左右されるので試行錯誤です。