使ってゲーム・アプリ開発してる方、気軽に参加してください!※DXライブラリではなく、DirectXを直接いじってる方を対象にしています。※興味を持った方は誰でも参加していただいて構いません。つの質問につき、一つのスレッドを作成して下さい。・個人の判断でスレ立てるまでもないなーと思った質問に関しては、「スレ立てるまでもない質問」のスレッドに投稿をお願い致します。何か迷ったら私の方まで気兼ねなくメッセージをお送り下さい。9年前こちらのスレッドにはスレッドを立てるほどでもないと思った、単純な質問を投稿して下さい。その判断は個人に任せます。SDKの最新バージョンって何ですか?など。多く使われていますかね。http://ameblo.jp/mratassyu/手提鞄屋魚有店(てさげかばんやうおありてん)レスがついていないものを優先して、レスしています。時々、見当外れなレスをします。9年前ネットに公開されてる情報は、DirectX9が多いですね。書いておけばよいのではないでしょうか?ビデオカードの違いによる、細かなエラーを避けるには、事前のビデオカードの性能を調べておいて、それぞれのビデオカードの性能に応じた処理をさせるしかないのではないでしょうか?恐らくDirect9で開発していれば、最近のPCであればほぼ問題なく動くとは思いますけどねぇ。さん自分の「最後に!」って日記のコメントを見て頂ければ解ると思いますが、なんとOSがVista以降のPCでも動作しない方が多くて・・・。DirectX9で開発したんですけどね。ビデオカードの問題ではないと思いますが、もしからしたら自分のプログラムに問題があるかも知れませんが・・・。DirectX11まで出ているにもかかわらずDirectX9安定だったとは・・・10,11はVista以降でしか動きませんから、完全移行するとまだ60%以上いると言われるXPユーザーを切り捨てることになります。(デバッグ版)この二つについて。この組合せのライブラリは、バージョンを問わずありますよね。それぞれ、リリース版、デバッグ版、だと聞いたのですが、何が違うんでしょうか。前から気になっていた事でDirectXの「D3D」はDirect3Dの略だと思うんですが、「D3DX」は何の略なのでしょうか。eXtend」当りの略だと私は思ったのですが。それぞれ、リリース版、デバッグ版、だと聞いたのですが、何が違うんでしょうか。一般的な話になりますが、デバッグ版にはソースコードデバッグ用のシンボルが含まれていたり、診断用のトレースメッセージを出力するコードが含まれていたり、実行コードの最適化が行われていなかったりします。デバッグ版は問題箇所の発見に役立つ代わりに実行速度が遅いです。eXtend」当りの略だと私は思ったのですが。公式の記述は無いみたいですがたぶんそうでしょうね。ヘッダファイルにもD3DXとしか書かれてませんね...。デバッグ版は問題箇所の発見に役立つ代わりに実行速度が遅いです。普段はデバッグ版を用いて、リリースビルドの時にリリース版を用いるのが無難なのでしょうか。公式の記述は無いみたいですがたぶんそうでしょうね。公式にも無いんですね。普段はデバッグ版を用いて、リリースビルドの時にリリース版を用いるのが無難なのでしょうか。無難という言葉の意図が分からないですが。マイクロソフトの開発製品(無償配布のSDK含む)はライセンス上、デバッグ版ライブラリの配布が許可されていません。デバッグビルドした実行形式を他人に渡すこともできません。開発中は、デバッグ版でバグの原因究明して、リリース版でテストプレイします。配布するのはリリース版です。いうふうに使い分けるのが一般的だと思います。マイクロソフトの開発製品(無償配布のSDK含む)はライセンス上、デバッグ版ライブラリの配布が許可されていません。デバッグビルドした実行形式を他人に渡すこともできません。マイクロソフトの開発製品(無償配布のSDK含む)はライセンス上、デバッグ版ライブラリの配布が許可されていません。デバッグビルドした実行形式を他人に渡すこともできません。本当はそうなんですよね。SDK丸ごとなら再配布が許可されているものはありますけど、開発環境は相手側で用意してもらうことになります。8年前ISLeさん返信ありがとうございました。違う質問をさせてください。3Dモデルの描画の話です。モデルの描画をWM_TIMERやWM_PAINTで行う(PeekMessageでなくGetMessageを使う)どちらがいいんでしょうか。[追記]WM_PAINTは無効領域が生じたら発行されると聞きました。DirectXではウィンドウを隠したりWM_TIMERでInvalidateRect等を呼び出さなくても発行されている気がします。モデルやカメラ、ライトを操作したりするとWM_PAINTが発行されるのでしょうか。3Dモデルの描画の話です。モデルの描画をWM_TIMERやWM_PAINTで行う(PeekMessageでなくGetMessageを使う)どちらがいいんでしょうか。3Dモデル描画とか関係なしに、精度の高いタイミング(正確なフレームレートとか)を得たいなら前者ですね。精度が悪くても負荷を低くしたいならウィンドウメッセージを使うのもありだと思います。WM_PAINTは無効領域が生じたら発行されると聞きました。DirectXではウィンドウを隠したりWM_TIMERでInvalidateRect等を呼び出さなくても発行されている気がします。モデルやカメラ、ライトを操作したりするとWM_PAINTが発行されるのでしょうか。断言はできませんが、Direct3DのAPIで無効領域が発生することはないと思います。ウィンドウプロシージャでWM_PAINTに対してBeginPaint,EndPaintを呼ばずにリターンすると無効領域がクリアされないままなのでWM_PAINTがいつまでも発行され続けますけど。WM_PAINTに対してBeginPaint,EndPaintを呼び出して戻り値0でリターンするか、ハンドリングしないでDefWindowProcを呼び出してそのまま戻り値とするかどちらかが必須です。Direct3Dを使うプログラムなら後者ですね。背景ブラシもNULLにして。ウィンドウプロシージャでWM_PAINTに対してBeginPaint,EndPaintを呼ばずにリターンすると無効領域がクリアされないままなのでWM_PAINTがいつまでも発行され続けますけど。WM_PAINTに対してBeginPaint,EndPaintを呼び出して戻り値0でリターンするか、ハンドリングしないでDefWindowProcを呼び出してそのまま戻り値とするかどちらかが必須です。Direct3Dを使うプログラムなら後者ですね。背景ブラシもNULLにして。処理を渡したら無事にWM_PAINTは発行されなくなりました。背景ブラシもNULLにしましたが、これは何のためなんでしょうか。ウィンドウを表示させて何もしなくてもなぜかWM_PAINTが発行されてました。ウィンドウを表示した直後に無効領域が生じるか、WM_PAINTが発行されるようになっているのでしょうか。背景ブラシもNULLにしましたが、これは何のためなんでしょうか。Direct3Dを使って描画する場合はハメコミ合成状態なので、ウィンドウのクライアント領域は隠れています。GDIでクライアント領域に描画するのは無駄です。WM_PAINTのハンドラでBeginPaintを呼ぶと、WM_ERASEBKGNDがSENDされて背景ブラシでクライアント領域が塗り潰されます。ウィンドウの背景ブラシをNULLにすると(デフォルトの)塗り潰しが行われないので無駄を減らせるというわけです。ちなみにWM_ERASEBKGNDをハンドリングして戻り値1でウィンドウプロシージャを抜けるようにすれば背景を好きなように描画できます。ウィンドウを表示させて何もしなくてもなぜかWM_PAINTが発行されてました。ウィンドウを表示した直後に無効領域が生じるか、WM_PAINTが発行されるようになっているのでしょうか。ウィンドウアプリではWM_PAINTをハンドリングしてクライアント領域に対する描画を行います。ウィンドウが最初に表示されるときにはもちろんクライアント領域が描画されなければならないので、最初はクライアント領域全体が無効領域です。クライアント領域が見えないからといってWM_PAINTを処理しないでおくとウィンドウを開いたときからずっと発行され続けることになります。ウィンドウが最初に表示されるときにはもちろんクライアント領域が描画されなければならないので、最初はクライアント領域全体が無効領域です。クライアント領域が見えないからといってWM_PAINTを処理しないでおくとウィンドウを開いたときからずっと発行され続けることになります。いうことだったんですね。新しい質問をさせてください。BeginSceneとEndSceneについてです。この二つは描画開始宣言と描画終了宣言であり、この間で描画を行わなければならないと良く聞きます。BeginSceneとEndSceneの間は他のスレッドを停止させて描画に専念しているので、BeginSceneとEndSceneの間で処理に時間がかかる事を行ってはならないと聞きました。FVFのDrawPrimitiveやメッシュのDrawSubsetをBeginSceneの前で行っても描画されます。BeginSceneとEndSceneの間でモデルやカメラ、ライトの計算を行っているコードを良く見ますが、これもBeginSceneより前で行っても処理されます。BeginSceneとEndSceneを消したら描画はされなくなりました。諸々の計算をした後、描画をして、BeginSceneとEndSceneはただ呼び出すだけで、この間は何もしない方がいいような気がします。コード:/*良く見る方法*///BeginScene//モデルやカメラ、ライトの計算(移動とか)//モデルの描画(DrawSubsetとか)//EndSceneコード:/*私が思った方法*///モデルやカメラ、ライトの計算(移動とか)//モデルの描画(DrawSubsetとか)//BeginScene//EndSceneこの二つの方法どちらが良いのでしょうか。BeginSceneとEndSceneの本当の役割はなんでしょうか。私が思った方法で描画がされるので、描画の開始終了宣言ではないと思うのですが・・・。8年前3Dの描画はGPUが行いますが、高速に処理するために、プログラムが発行した命令をそのまま実行するとは限りません。BeginScene~EndSceneは一連の命令をGPUにプッシュするための指示です。このあいだ描画に専念しているというのはまったくのデタラメですね。EndSceneで締め切られた後、バッファがデバイス画面に表示されるまでのあいだに描画されます。実際にどのように動作するかはGPU側の実装によりますが、GPU側にとっては命令がバラバラに送られるより、まとめて送られたほうが最適化しやすく、BeginScene/EndSceneはひとまとまりであることを示すための目印となります。BeginScene~EndSceneのあいだにカメラやライトを変更すると最適化の邪魔になってパフォーマンスに少なからず悪影響を与えると思います。実測しないと分からないですし環境によっても異なるでしょうが。実際にどのように動作するかはGPU側の実装によりますが、GPU側にとっては命令がバラバラに送られるより、まとめて送られたほうが最適化しやすく、BeginScene/EndSceneはひとまとまりであることを示すための目印となります。これからは、BeginSceneとEndSceneの間で描画する様にします。BeginScene~EndSceneのあいだにカメラやライトを変更すると最適化の邪魔になってパフォーマンスに少なからず悪影響を与えると思います。前私が書いた方法ですが、複数のモデルの移動を考えていませんでした。複数のモデルを動かそうとすると、モデルのワールド座標の計算はBeginSceneの前で行い、SetTransformでの設定はBeginSceneの間で行う事になりますよね。マテリアルやテクスチャを変えたり、FVFで描画するためにライトを無効する処理はどうしても描画したいモデルの直前(BeginSceneとEndSceneの間)で行う必要があると思います。これは、仕方がないのでしょうか。あと、ポイントスプライトについて質問があります。ポイントスプライトのサイズを0.3fぐらいに設定して、2つのポイントスプライトを描画して異なるテクスチャを貼りました。ポイントスプライトのZ座標を大きくした時に、なぜか物体の見かけの大きさは変わりませんでした。0)の位置の物体が奥に移動する(Z座標の値が大きくなる)と物体の見かけの位置が画面の中心によってきますが、これはポイントスプライトでも生じました。ポイントスプライトの見かけの大きさが変わらないんでしょうか。マテリアルやテクスチャを変えたり、FVFで描画するためにライトを無効する処理はどうしても描画したいモデルの直前(BeginSceneとEndSceneの間)で行う必要があると思います。これは、仕方がないのでしょうか。先の返信にも書きましたが、このあたりは実測をもとに試行錯誤するしかありません。GPUメーカーもどんどん工夫を進めているので何が最適なのかは分かりませんし将来的に変化する可能性もあります。重要なのはEndSceneのあと、Presentでデバイス画面を更新するまでのあいだ上手にGPUのレンダリングと並行して処理を進めることです。EndSceneの直後にPresentしたりするとレンダリングが完了するまで無駄に待つことになります。ポイントスプライトの見かけの大きさが変わらないんでしょうか。いう仕様だからとしか言えないのですが...。D3DRS_POINTSCALEENABLEをTRUEに設定すればカメラからの距離に応じたサイズに調整されるみたいですけど。重要なのはEndSceneのあと、Presentでデバイス画面を更新するまでのあいだ上手にGPUのレンダリングと並行して処理を進めることです。EndSceneの直後にPresentしたりするとレンダリングが完了するまで無駄に待つことになります。EndSceneの後、GPUがデータを受け取って描画を行い、バックバッファとフロントバッファを入れ替えるまでに、「GPUの描画処理時間以下の処理時間の処理」を行うと効率が良いと言う事でしょうか。いう仕様だからとしか言えないのですが...。D3DRS_POINTSCALEENABLEをTRUEに設定すればカメラからの距離に応じたサイズに調整されるみたいですけど。trueにしてあるんですけどね・・・。ポイントスプライトにテクスチャを貼ってビルボードの代わりに出来ないかと思ったのですが、「まあポイントスプライトはこういうものだ」と思って使うのは諦めます。EndSceneの後、GPUがデータを受け取って描画を行い、バックバッファとフロントバッファを入れ替えるまでに、「GPUの描画処理時間以下の処理時間の処理」を行うと効率が良いと言う事でしょうか。GPUが働いている時間以下の処理でなければならない理由はないですね。GPUとプログラムの処理のどちらが先に終わるかではなくて、互いに相手の処理が終わるのを待っている無駄な時間を少なくすることに意味があるので。trueにしてあるんですけどね・・・。ポイントスプライトにテクスチャを貼ってビルボードの代わりに出来ないかと思ったのですが、「まあポイントスプライトはこういうものだ」と思って使うのは諦めます。ポイントスケール係数(D3DRS_POINTSCALE_A/D3DRS_POINTSCALE_B/D3DRS_POINTSCALE_C)を設定してないから大きさが変わらないとか。ポイントスプライトのサイズ計算は透視変換とは異なるのでビルボードの代わりにはならないですけどね。GPUが働いている時間以下の処理でなければならない理由はないですね。GPUとプログラムの処理のどちらが先に終わるかではなくて、互いに相手の処理が終わるのを待っている無駄な時間を少なくすることに意味があるので。私が何か勘違いしている様で理解できません。GPUが描画を完了したらバッファを入れ替えて表示をしますよね。描画が完了した時に、別の処理をしていてすぐにバッファを入れ替えられないと無駄な時間が発生しませんか。ポイントスケール係数(D3DRS_POINTSCALE_A/D3DRS_POINTSCALE_B/D3DRS_POINTSCALE_C)を設定してないから大きさが変わらないとか。ポイントスプライトのサイズ計算は透視変換とは異なるのでビルボードの代わりにはならないですけどね。ポイントスケール係数を設定したら見た目の大きさが変わりました。ビルボードの代わりにならないのは残念です。GPUが描画を完了したらバッファを入れ替えて表示をしますよね。描画が完了した時に、別の処理をしていてすぐにバッファを入れ替えられないと無駄な時間が発生しませんか。フレームレートを一定に保つため、レンダリングが完了してからバッファを入れ替えるまで時間が空きます。そのあいだメインCPUを何もせず待たせるのはもったいないですよね。フレーム落ちしなければどちらが後でもかまわないのですよ。背景のモブとか他のオブジェクトに影響与えないオブジェクトの内部処理を前のフレームから進めておいて、バッファを入れ替えたらすぐにシーンをプッシュ、レンダリングしている間にメインオブジェクトの内部処理を行いシーンをプッシュ...と交互に進めると並行処理を活用できます。描画だけなら手前のオブジェクトから描画するほうが速かったりとかありますけど、並行処理を絡めると逆転することがいろいろあります。負荷のバランスはゲームタイトルごとに、環境にも左右されるので試行錯誤です。カプコンのMTフレームワークはそのあたりを自動化してるらしいですけど。フレームレートを一定に保つため、レンダリングが完了してからバッファを入れ替えるまで時間が空きます。そのあいだメインCPUを何もせず待たせるのはもったいないですよね。フレーム落ちしなければどちらが後でもかまわないのですよ。背景のモブとか他のオブジェクトに影響与えないオブジェクトの内部処理を前のフレームから進めておいて、バッファを入れ替えたらすぐにシーンをプッシュ、レンダリングしている間にメインオブジェクトの内部処理を行いシーンをプッシュ...と交互に進めると並行処理を活用できます。描画だけなら手前のオブジェクトから描画するほうが速かったりとかありますけど、並行処理を絡めると逆転することがいろいろあります。負荷のバランスはゲームタイトルごとに、環境にも左右されるので試行錯誤です。なんとなく分かった様な、難しいですね・・・。いう最適化は是非使いこなしたいですが。ミクプラは自由にリンクできます。