[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 08/06 20:32 / Filesize : 251 KB / Number-of Response : 956
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【C++】 DirectX初心者質問スレ Part24 【C】



1 名前:デフォルトの名無しさん mailto:sage [2009/06/22(月) 22:06:29 ]
※回答する人も、質問する人も必ず読んでください

これらに当てはまる人のための質問スレです。
1.C/C++は多少理解している。
2.最近DirectXを始めたばかり
3.SDKを見ても、Googleで検索しても、いまいち理解できない人
4.余計な雑談は不要ですよ

【 回答してくださる方 】
・ できるだけ優しく質問に答えてあげてください。
・ 優しく教えるのが嫌でしたら、解決するためのヒントだけでも結構です。
 「ググれ」「SDK見れ」以外の回答でおながいします。
・ 神ですら理解不能な質問は無視して下さい。

【 質問する方 】
・ どんな事で躓いているのか明確にしよう。
・ 長くならないなら躓いている部分のコードを晒してみれ。
・ 解決した場合、お礼を言うのは当然だが、何をどうしたら解決したかを明確に書こう。
・ 回答して貰ったら、出来るだけお礼もしよう。

【C++】 DirectX初心者質問スレ Part23 【C】
pc12.2ch.net/test/read.cgi/tech/1242977486/

231 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 11:44:25 ]
カメラの使用はDirectShowの範疇でありDirectXではない。

232 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 14:56:39 ]
DirectX9のフックについて、初心者向けの詳しいHPはありませんか?
当方、VC(++は少し苦手)、VB、Delphi分かります。dllのコンパイルも出来ます。

目標は、フルスクリーンの別アプリ画面に自前のグラフィックを描画することです。
レベルが低い質問かもしれませんが、よろしくお願いします。

233 名前:232 mailto:sage [2009/07/08(水) 15:02:38 ]
別アプリのhWnd取得と画像データの取得までは出来たのですが、描画の方が上手くいきません。

234 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 15:08:48 ]
またおまえか

235 名前:デフォルトの名無しさん [2009/07/08(水) 15:12:14 ]
16と16の平たいを毎回敷き詰めて描くと
テクスチャに写植して描くはどちらが速いか?

236 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 15:19:37 ]
実測しろ

237 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 15:20:59 ]
日本語がおかしいが
敷き詰めて書くのが1回の命令で出来るならそっちの方がいいんじゃね?
ただのループならWARP指定汁

238 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 16:18:32 ]
>>234
やはり直接フックがベストですか!
有り難う御座いました。

239 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 17:23:37 ]
質問です。
カメラから見た時の、あるメッシュの「厚み」を調べる方法を考えています。

サイコロのような凸型物体ならば、
・裏面を描画し、テクスチャAに深度値として書き込む。
・表面を描画し、テクスチャBに深度値として書き込む。
とし、A-Bで厚みが出ると思います。
(深度バッファシャドウの時のように、深度値をz/wで0〜1にしてしまうと、歪んでしまうので単純にzを記録する必要がありますが)

ただ、「コ」の字を上から見た時のような場合の厚み合計の出し方が思いつきません。
「コ」を真上から見た際、上辺の厚みと、下辺の厚みの合計が知りたいのです。
何か良い手はありますでしょうか?



240 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 17:34:02 ]
>>239
表面/裏面と分けるのではなく、カリングを無効にした状態でZFUNCを
LESSEQUAL、GREATEREQUALにして描画する。

241 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 17:39:32 ]
>>239
加算合成すればいいのではない?
裏面のZ値の合計から表面のZ値の合計を引く
0〜1の範囲をはみ出ないようにしないといけないけれど

242 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 17:49:10 ]
>>240
すいません、その結果何が解決するかがちょっと分からないのですが…。
一番奥であるポリゴンまでの距離が記録されるだけかと。

>>241
素晴らしいです!
まさにその通りですね!
(Af - An) + (Bf - Bn) == ((Af + Bf) - (An + Bn))
ということですね。

ありがとうございました。

243 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 18:31:47 ]
3Dゲームのプログラミングを始めようと思うのですが
オススメの書籍はありますか?

244 名前:240 mailto:sage [2009/07/08(水) 18:59:59 ]
>>242
上辺の厚みと下辺の厚みの合計ってとこ見てなかった。
コが1枚ずつの面ってことじゃなくて、厚みのある凹ってことね。

245 名前:216 mailto:sage [2009/07/08(水) 19:25:37 ]
>>220
EnumObjectsCallbackで何をやってるのかようやく理解できますた
VOID* pContext に LPDIRECTINPUTDEVICE8 を渡して
コントローラーごとに個別にプロパティが設定できるようになりました
ありがとうござますた


246 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 19:27:41 ]
>>243
DirectX逆引き大全500が鉄板だと思うが
Googleのオンライン書籍立ち読みで見れるので見るといい


247 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 21:33:09 ]
いまググって調べた。 東京12.960.883人の内、支那人149.113人だな。
堂々コリア人を抜いてる。  (09年5月調べ)

約、100人に1.15人いるんだな。

248 名前:デフォルトの名無しさん [2009/07/08(水) 22:49:17 ]
初心者ですが質問させてください。

現在DirectSoundを使った音声キャプチャプログラムを作成しています。
マイクやライン、サウンドミキサなどの入力先を指定してキャプチャを行いたいので
次の手順でキャプチャデバイスオブジェクトの作成を行っています。

手順1.DirectSoundCaptureEnumerate関数を使用して利用可能なデバイスを列挙
手順2.手順1で列挙したGUIDから任意の入力先のGUIDを選択し
   DirectSoundCaptureCreate8関数の第1引数に設定しキャプチャデバイスオブジェクトの作成

Vista環境では手順1のDirectSoundCaptureEnumerate関数で
マイクやラインなど録音デバイスの項目に表示されている
入力先の数だけデバイスの情報が取得できて
入力先を選択してのキャプチャが実施できるのですが、
XP環境では1つのデバイスしか列挙できず入力先の指定が行えません。
(録音コントロールにはマイク、ライン入力など複数の入力先が表示されています。
 録音コントロールで選択されている入力先の音しかキャプチャ出来ません。)

XPでは入力先を指定してのキャプチャデバイスオブジェクトの作成は行えないものなのでしょうか?
不可能な場合は何か入力先を指定してキャプチャするよい方法はないでしょうか?
よろしくお願いします。


249 名前:デフォルトの名無しさん mailto:sage [2009/07/08(水) 23:44:16 ]
Ring 3 Circus のDirect3D9 Hookingを改造して
Direct3D9を使ったゲームの画像を取得するプログラムを作ったんですが
デバイス作成時にバックバッファをロック可能にするフラグを指定していないと
バックバッファの内容が取得できないようです。

それでIDirect3DSwapChain9::GetPresentParametersを呼んで、
得られたD3DPRESENT_PARAMETERSのFlagsを
flags |= D3DPRESENTFLAG_LOCKABLE_BACKBUFFER
のように変更し、Resetを読んだら、HRESULTがD3DERR_INVALIDCALLに・・。
Resetはだめみたいです。

ランチャとか用意して、バックバッファをロック可能でデバイスを作成させるのは使うとき面倒です。
ほかにバックバッファの内容を取得する方法は無いんでしょうか



250 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 00:36:26 ]
取得しないといけない状況がまったく思いつかないので分からない。

251 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 00:45:51 ]
IDirect3DDevice9::StretchRectでコピーすりゃいいんでないの

252 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 10:30:42 ]
質問です

パーティクル(たくさんのビルボード)を表現するのに
DrawPrimitiveUP + D3DPT_TRIANGLELIST
を使っています。

1つのビルボードを表現するのに6頂点。
100個なら600頂点のデータをDrawPrimitiveUPに渡す必要があるのですが、これが思いのほか遅い気がします。
パーティクルを表現するのに、DrawPrimitiveUPを使うのは常道なのでしょうか?

DrawPrimitiveUPによって、メインメモリーからVRAMに転送するコストが大きいのが遅い原因かな?と思います。
ただ、パーティクルは移動なども毎フレーム行われるため、DrawPrimitive(UPではない)のほうでは実現が難しい気がします。
(結局は毎フレームStreamに流す作業が必要。これではVRAMへの転送コストは変わらない)

253 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 10:47:49 ]
AGPメモリ

254 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 11:05:55 ]
どんなパーティクルを想定してるのかわからないけど
6頂点のポリじゃなくて1頂点のポイントスプライトにしてみるとか
そうすると制御が楽になるので簡単な飛び散りくらいなら
頂点シェーダで動かせるようにもなるし

255 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 11:16:33 ]
>>252
ホントにDrawPrimitiveUPの呼び出しだけを計測してる?
頂点演算って毎フレームCPUにやらせると結構負荷かかるよ。
パーティクルの移動計算が幾何学的なものならシェーダーにやらせたほうがいい。

256 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 11:31:06 ]
レスありがとうございます

>>254
ポイントスプライトも考えたのですが(ポイントスプライトで実装しているパーティクルもあるので)、
今回は頂点毎に違う方向を向いた法線が必要だった(疑似ボリュームパーティクル)ため、ビルボードにすることにしました

目指しているのは疑似ボリュームパーティクルによる煙表現です

>>252
実験としてDrawPrimitiveUPに流し込む(FVFで定義した頂点フォーマットの)構造体を編集せず、描画し続けさせてみました。
ほぼ同等の速度のようです。
おそらくCPUパワーはほとんど足を引っ張っていないかと思われます。

257 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 11:43:31 ]
>>256
TriangleStripなら4頂点で済むよ。

DirectXのバージョンが分からんが、たぶんヘルプに「動的な〜」頂点バッファ処理云々の項があって
そこにDrawPrimitiveで、頂点位置が毎フレーム変わるようなものの処理の仕方が書いてあるはず。

簡単に言えば、頂点バッファを確保して、後は毎フレームに
バッファをロック>書き込み>一杯になったらアンロックしてDrawPrimitive>再度バッファを…

更にインデックスバッファを使ってTriangleStripにすれば、転送コストはかなり違ってくるわよ。

258 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 11:49:37 ]
Stripじゃ縮退ポリゴンで2頂点増えるから、減らないだろう。

259 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 11:57:46 ]
バッファをロックするんじゃ、結局遅いと思うが



260 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 12:10:23 ]
インデックスは毎回転送する必要がないから、流すデータ量は減るんじゃないか

261 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 12:17:30 ]
微妙な即レスが続いて、なんか答えるのが馬鹿馬鹿しくなってきたが

>>258
2通りにとれるな。もう少し理由を言ってみ。縮退ポリなんか使わんよ。

>>259
今時そんな…ではDrawPrimitiveUPはどうやってVRAMに送ってるんだ?
ロックとDrawは極力まとめるんだ。まぁ、UP系もそれなりに上手くやってくれるけど。

確かLunaの作者が昔実験結果を掲載してくれてたけど、今はなくなっちゃったみたいだな。

262 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 12:45:15 ]
スプライトって全部板なんだから頂点情報ひとつで十分だろ

263 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 12:49:55 ]
>>261
縮退ポリゴンを使わずに、複数のビルボードをStripで描画するってどうやるの?

264 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 12:55:40 ]
>>261
いまどきそんな。とか言ったって、DrawPrimitiveUPより早くならなきゃ質問に答えたことにはならないんだぜ?
しかも今回は、毎フレーム1回しかUPを呼び出さだないわけだし、どうやってUP以上に「ロックとDrawをまとめる」んだよ?

265 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 13:01:22 ]
>>263-264
ごめんなさい
俺こそが質問者の質問をよく読んでない、ただの馬鹿馬鹿しい男でした

266 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 13:07:44 ]
ちゃんと自分の間違いを謝れる奴は、伸びる奴

267 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 13:10:27 ]
>>256
そこまで試したならついでに、静的なVertexBufferに頂点データ入れてみて
本当に転送が問題なのかも確かめた方がいいかと。

268 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 13:15:57 ]
            /j^i
           ./  ;!
          /  /__,,..
         /  `(_t_,__〕
         /    '(_t_,__〕
        /    {_i_,__〕
       /    ノ  {_i__〉
     /      _,..-'"
   /      /
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜




269 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 13:23:51 ]
だから動的更新ならAGPメモリ使えよ。



270 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 13:40:13 ]
>>263
インデックスバッファ

>>264
まず>>259でロックが遅いなんて書くから、UPでもロックのコストは変わらないと書いた。
「動的な〜」の項読んでみろと。>>253氏のも乗ってたはず。

で更にUP系でIB使うと、毎回IBの転送が起こるよな?
ところが非UP系ならば初期(或いはVBサイズ変更時のみ)コストだけで済む。

で、更に頂点数の転送量は2/3に抑えられる。

もう少しいうと、DrawPrimitiveUP系の場合、計算用のアクセスしやすいバッファの他に、
描画用の配列をメインメモリに取って、更にVRAMにも同じのが出来るわけだ。無駄だと思うがねぇ。

まぁ、好きに実装したらいいじゃないの。なんでそんな必死よ>>265-266

271 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 13:43:23 ]
>>252がDrawPrimitiveUPを連投してるなら
それをまずやめるべき。
>>257方式で、まとめるのが一番良い方法だろうな。

余力と環境があるなら、ジオメトリインスタンシングも
試して欲しいところだが。

272 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 14:06:50 ]
結局「縮退ポリゴンを使わずに、複数のビルボードをStripで描画する」方法の説明がないわけだが

273 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 14:11:03 ]
インデックスで縮退用のを適当に一枚かますってことか
それでなくてもDrawPrimitiveUPにこだわる人は、
描画数増えたときどうするんだろ?

274 名前:デフォルトの名無しさん [2009/07/09(木) 14:24:44 ]
「DirectSoundで鳴らしている音」を録音したいのですが、
どうすればよいでしょうか?

例えば、自作ゲームの「BGM」と「プレイ中に適宜鳴る効果音」の両方を
1つのWAVファイルに録音したいと思っています。
よろしくお願いします。


275 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 14:27:40 ]
縮退ポリは使わないと言ってるだろ

276 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 14:39:01 ]
なんか大人と子供だな

277 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 14:40:13 ]
そもそも2000〜3000ポリゴン以下ならDrawPrimitive系もDrawPrimitiveUP系も
速度にほとんど差がないんだが、みんな計測した上で話をしてるんだろうか?

278 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 14:43:08 ]
誰もそこの速度差は問題にしていないけどな

279 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 14:46:15 ]
259です。
>>270
>UPでもロックのコストは変わらないと書いた
259で書いてるのは「結局(UPと同じくらい)遅いと思うが」という意味です。



280 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 14:54:53 ]
>>277 >>278
むしろ本当に3000ポリゴン程度で差が出るなら問題じゃね?
速いほう使った方がいいだろ

281 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 15:07:02 ]
たくさんのご意見ありがとうございます。

まず、UPをやめる+INDEX化で転送量が2/3になるのは良さそうです。
やってみます。
さらにINDEXバッファは1回だけ書けば書き換え無用ですから、純粋に2/3になりそうで良いですね。

TriangleStripで〜という方法は、いまいちわかりません。
離れた位置の四角ポリゴン(実際は三角ポリ×2)を描画する必要がある以上、TriangleStripは使えないのではないでしょうか?
縮退ポリゴン(描画されない細い三角ポリゴン)を使うことによる手法も聞いたことはありますが。

AGPメモリというのが最初よくわかりませんでしたが、D3DUSAGE_DYNAMICを指定することなんですね。
こちらも試してみます。

このほかに、下記のような手法も考えたのですが、一般的ではないのでしょうか?
説明を楽にするために、INDEXではない方法での説明とします。
・「四角形を1つ描画するのに必要な情報」を作る。つまり6頂点分。
 頂点データの中にD3DFVF_SPECULARを加え、その領域に「何個目の四角形か」を入れておく。

・上記の6頂点×描画しうる四角形分の”静的”頂点バッファを作り、情報を書き込む。
 その際D3DFVF_SPECULARの領域に入れている「何個目の四角形か」をきちんと適切な値にしておく。

・パーティクルを表現するには、四角形毎の座標情報を更新する必要がある
 そこでID3DXEffect::SetVectorArray()で座標情報を渡す

・エフェクト側ではD3DCOLORtoUBYTE4を使って、対応するVectorArrayの座標情報を引き出し、頂点座標に加算する

問題点として、ビルボードをカメラに正面向けにするためのMATRIX変換を頂点シェーダ内でやる必要があります。
(今までは、頂点データ内のxyzを正面向くように調整済みだった)

282 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 15:16:38 ]
>>281
長々書いてあるが、テストすれば分かることだから自分でやってくれ。

Index関係の思い出といえば、
Indexバッファを途中から使うための引数の与え方が全然資料が無いことだった。
正しく動作させるまでかなり試行錯誤したな。
一度動けばなんてことないんだが。

283 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 15:24:58 ]
>>282
詳しく
前にIndexバッファを途中から使おうとしたんだけど
GeForceとIntel系チップセットでは想定通りの動きをしたんだけど
ATI系のビデオカードではうまく動いてくれなかったんだよね

284 名前:282 mailto:sage [2009/07/09(木) 15:28:43 ]
>>283
逆に、マジかと言いたい。
オレはGeForceで開発した上でIntel系とATI系でも動いてることを確認する形を取ったが、
Direct3DのAPIレベルで互換性が無いような違いが
IndexedBufferレベルであるんだろうか?

285 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 15:44:09 ]
>>281
全然わからんが、要はこれがしたいのか?
FVFが通るか、不安があるけど。

uniform float4x4 g_world_transform[n] = { ... };
static const float4 g_local_position[4] = { ... }; // for box vertices

struct vertex_in_t
{
uint24 transform_index; // 0~n
uint8 position_index; // 0~3
};

struct vertex_out_t
{
float4 positon;
float4 color;
};

void vp_main( in vertex_in_t iv, out vertex_out_t ov )
{
float4x4 world_transform = g_world_transform[iv.transform_index];
float4 local_positon = g_local_position[iv.position_index];

ov.position = mul( local_positon, world_transform );
pv.color = float4(1,1,1,1);
}

286 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 17:34:48 ]
縮退ポリゴンとはなんぞや?

287 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 17:43:39 ]
>>286
面積が0のポリゴン
ストリップは数珠繋ぎしか出来ないけど
途中面積が0のポリゴンを繋げれば
バラバラに見えるでしょ

288 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 17:52:37 ]
報告です。

281で提唱した方法だとでかかる時間を1とすると、
AGPメモリに置く方法は2
DrawPrimitiveUPでやる方法は3
となりました。

何の因果か、きれいに1:2:3になりました。

281で提唱した方法だと、実質VRAMへ転送している量はvector4 * particleNumでかなり節約できます。
その他ですと、
float x, y, z;
float nx, ny, nz;
DWORD color;
float u, v;
でfloat * 9 * particleNumほど転送しているので、二倍超転送していることになります。
やはりボトルネックはこのあたりなのでしょう。

次は、ストリームを分けることで、AGPメモリに置く方法をとりつつxyzの値しか転送しないようにしてみます。


289 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 17:59:13 ]
1*1のポリゴン用意して
トランス演算とDraてPrimitive繰り返せばよくね?



290 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 18:21:59 ]
>>281を見てると「それってInstancingじゃね?」と言いたくなる
ttp://msdn.microsoft.com/ja-jp/library/bb174602(VS.85).aspx

291 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 18:48:59 ]
小沢の西松建設問題の時
09/01/21 西松建設社長を逮捕
09/01/21 元西松建設専務 死亡
09/02/24 長野知事の元秘書(西松建設事件での参考人) 死亡
      (電柱にロープを巻きつけ首吊り自殺)
09/03/01 「小沢一郎氏と秘書と、ダム工事のただならぬ関係」を追及してきた記者(吉岡元議員) ソウルで取材中に死亡
09/03/03 民主党岩手支部家宅捜索
09/03/04 民主党事務所のある相模原卸売市場全焼
助かった人
小沢氏の第一秘書・大久保容疑者も自殺の恐れが出てきたため、検察が緊急逮捕

鳩山の献金問題



292 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 23:14:37 ]
288です。
288の報告は、いわゆるオンボでの実験で、頂点シェーダがソフトウェアで行われていました。

グラボつき(GF9600)の環境で試したところ、
UP系 5
AGP  8
281法 1

の割合で時間がかかりました。
AGP法のほうが、UPよりも遅くなっているのが印象的です。

>>290
面白い記事ありがとうございます。
まさしくこれですね。

293 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 23:42:09 ]
なんかやり方が下手な気がする
ソースあげてみ

294 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 23:49:07 ]
つかindexbufferも使えない素人のコードによる測定になんの価値があるんだ
いつまでやる気だろ

295 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 23:57:00 ]
>面白い記事ありがとうございます。
節子…それ、公式サンプルや

一般的な方法がわかって良かったんじゃね

296 名前:デフォルトの名無しさん mailto:sage [2009/07/09(木) 23:59:00 ]
まともなグラボならUP使ったほうが早いのは常識だろ
293とか294は典型的な2ch馬鹿だな

297 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:04:24 ]
>>293
一番あやしいのは、逆に遅くなってるAGPのやつですよね。

pDev->CreateVertexBuffer(
sizeof(D3DVERTEX) * 4 * MAX_SMOKE,
D3DUSAGE_DYNAMIC | D3DUSAGE_WRITEONLY ,
MYFVF,
D3DPOOL_DEFAULT,
&m_buffer,
NULL
);

pDev->CreateIndexBuffer(
sizeof(WORD) * 6 * MAX_SMOKE,
D3DUSAGE_WRITEONLY ,
D3DFMT_INDEX16,
D3DPOOL_DEFAULT,
&m_index,
NULL
);

で生成し、毎フレーム下記のようになっています。
>>294 IndexBufferは使ってますよ

m_buffer->Lock(0, sizeof(D3DVERTEX) * 4 * m_smokes.size(), (void**)&vertex, D3DLOCK_DISCARD);
m_buffer->Unlock();
pDev->SetStreamSource(0, m_buffer, 0, sizeof(D3DVERTEX));
pDev->SetIndices(m_index);

pDev->SetFVF(MYFVF);
pDev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 4 * m_smokes.size(), 0, 2 * m_smokes.size());

298 名前:294 mailto:sage [2009/07/10(金) 00:04:34 ]
>>296
は?UP云々なんて一言も言ってないんだがw

299 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:05:10 ]
>>296
その根拠は?

>>292
動的バッファLock時のオプションは
どうしてる?



300 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:14:21 ]
>>297
む、こりゃちょっとひどい気がする
スレちゃんと読んでないけど、xyzは毎フレーム変化してるんだよな?
どのタイミングで更新してるんだい?

301 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:19:30 ]
>>299
D3DLOCK_DISCARDですね。
m_buffer->Lock(0, sizeof(D3DVERTEX) * 4 * m_smokes.size(), (void**)&vertex, D3DLOCK_DISCARD);
この行が、動的バッファのロックです。

LockとUnlockの間に「ここで頂点情報を書き込んでいます」とか書くべきでした。すいません

>>300
え、初心者サイトのサンプルをほぼそのまま使ったのですが、妙でしょうか?

xyzの更新は、Lockの前に行っています。
m_smokesというのが、ビルボードの中心座標の配列vector<D3DXVECTOR3>です。

302 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:24:23 ]
ちゃんとD3DLOCK_DISCARDでロックしてるし、
動的バッファの取り扱いは、特に問題はなさそう。
へえ、これでUP系の半分の性能なんだ、信じられんw

303 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:29:11 ]
>>302
オンボ環境ではしっかりUPのほうが遅かったので、環境によるような気がします。
明日再度オンボ環境の場所に行くので、再度慎重に測り直してみます。

304 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:30:56 ]
>>301
うーむ、Lockの前に更新って、矛盾してないか
このソースだとDYNAMICでバッファを確保した意味がないよ?

305 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:34:25 ]
こりゃ計測方法も怪しくなってきたなw
両方のソース示さない限り無意味だろw

306 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:39:25 ]
>>304
すいません。ちょっと更新の意味を取り違えているのかもしれません
for(DWORD i = 0; i < m_smokes.size(); ++i)
{
m_smokes[i].y += 0.1f;
}
m_buffer->Lock(0, sizeof(D3DVERTEX) * 4 * m_smokes.size(), (void**)&vertex, D3DLOCK_DISCARD);
for(DWORD i = 0; i < m_smokes.size(); ++i)
{
(D3DVERTEX) *p = &vertex[i * 4];
p[0].x = m_smokes[i].x - 0.5f;
p[0].y = m_smokes[i].y + 0.5f;
p[0].z = m_smokes[i].z;
p[1].x = m_smokes[i].x + 0.5f;
p[1].y = m_smokes[i].y + 0.5f;
p[1].z = m_smokes[i].z;
p[2].x = m_smokes[i].x + 0.5f;
p[2].y = m_smokes[i].y - 0.5f;
p[2].z = m_smokes[i].z;
p[3].x = m_smokes[i].x - 0.5f;
p[3].y = m_smokes[i].y - 0.5f;
p[3].z = m_smokes[i].z;
}
m_buffer->Unlock();

こんな感じにやっています。
実際は座標のほかに、normal, color, uv もセットしています。
あと、もうちょいマシなコピーの仕方をしています。

>>305
単純に1000フレーム回るまでの時間を計測しています。
描画以外はほとんど何もやっていないのと、座標移動計算はまったくといってよいほど時間をくっていないのを確認済みです。

307 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:41:06 ]
>>294=>>298=>>305
初心者スレ荒らして楽しい?
他人の足引っ張って立って、自分の価値を高めることにはならないぜ?
無意味だと思うならスルーしてなよ

308 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:43:46 ]
特に問題あるようなソースには見えないな
UP系のほうが早い場合があるというのは面白い
UPはドライバ側で何かしらの最適化を行っているのかもね

309 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:44:01 ]
>>307
連続でお疲れさんw



310 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:45:48 ]
294 indexbufferも使えない素人が!(キリッ!!
297 >>294 IndexBufferは使ってますよ

腹抱えてワロタw

311 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:53:01 ]
久々に有益情報が出てるな
俺は何も考えずにDrawPrimitiveUP使ってた
Instancingとやらを使うと速度が5倍になるとかマジパネェから俺も実験してみるわ

312 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:53:04 ]
俺のソースでは、mallocaで確保した一時バッファにデータを作ってから
Lock→memcpyでまるごとコピー→Unlock と、
ロックしている時間が短くなるようにしてたな。
なんとなくその方が良かろうと思っただけで、計測してないから鵜呑みにはするな。


313 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 00:57:20 ]
294じゃないけど、よくおまえらそこまで無条件で信用できるな。
煽る気はないけど、ソースのないベンチなんて昔は弾いていた気がするんだが。

314 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 01:01:39 ]
DirectX10使えば縮退ポリゴンもいらねーしデータ転送量も抑えられるしでウハウハ。
SO使えば座標更新もGPUで出来てさらにウハウハ。

315 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 01:06:14 ]
>>312
D3DLOCK_DISCARDを指定すると、
一時バッファを用意してくれるらしいので
その処理は冗長と言える。

316 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 01:16:45 ]
俺もGeforce9600GTなんで、さくっと試してみたよ
DrawIndexedPrimitiveとDrawIndexedPrimitiveUP
LVetexで位置のみ毎時更新
前者は動的バッファがたまり次第フラッシュ
後者もそれに合わせようと思ったけど、面倒なんでメモリ一括確保
疲れてるんで固定機能でやったけど、1万ポリでも誤差程度
寝る

317 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 01:20:16 ]
>>316
そうなるはずだ。
UP系かそうでないかでそんなに差が出るというのはちょっとおかしいんじゃないか。

プリミティブの座標更新をGPUにやらせることで全体の高速化を図るというのならまだ分かるが。

318 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 01:30:53 ]
>>316
結局描画におけるGPUの時間が変わらないからフレーム単位だと時間は変わらないが
DrawPrimitive()とDrawPrimitiveUp()だと関数から帰ってくるまでの時間にかなり差があったと思うが。

319 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 02:04:48 ]
DirectShowのスレでも質問したのですが、スレの勢いを考えてこちらにも質問させていただきます。

DirectShowでGeekなページを参考に動画再生をするプログラムを作りました
www.geekpage.jp/programming/directshow/change-rate.php
参考URLでは『put_Rateの引数を2.0などに変更すると倍速再生になります。
put_Rateの引数に負の値(マイナスの値)を渡すと巻き戻し再生になります』
とありますが、

pMediaPosition->put_Rate(0.5);
のput_Rateの引数を負の値にしても大部分のフィルタは逆再生をサポートしていないため実行されません。

そこでIMediaSeekingかIMediaPositionを用いて、または用いなくてもいいのでdirectshowで
動画の巻き戻しをするプログラムを作りたいのですが、どうすればよいのやら困っています。
何か良い考えはないでしょうか?
是非知恵をおかしください!



320 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 04:29:31 ]
テクスチャのサンプリングをWrapにして何度も繰り返すような貼り方をすると負荷が高いと聞いたんですが
これは本当ですか?
使用するテクスチャが小さくなるから、むしろこっちのほうが良いと思ったんですが
自分の環境( GTX280 )では違いが見られなかったんですが
オンボードのような低スペックのビデオカードだと遅くなったりしますか?

321 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 08:27:10 ]
うそです。

322 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 08:28:23 ]
ゲームの動画再生にDirectShowはいつも使っているけど、再生速度の変更が必要になったことがないから知らない。

323 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 08:34:33 ]
AGPっていつの時代だよw

324 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 09:08:50 ]
ソース無いベンチなんて意味ないよ
ということではあるそうですが、一応報告しておきます

グラボつき(GF9600)の環境で試したところ、
UP系 5
AGP  8
281法 1

オンボ環境で試したとところ
UP系 10
AGP  9
281法 8.5

くらいの処理時間になりました。
あくまで同一環境内での比率なので、GF9600の数値とオンボの数値には関係性はありません。
まったく同じ実行ファイルで実験しました。

>>316
私の実験と差がありそうなのは下記2つっぽいですね
>座標だけ更新
座標だけストリームを分けて、そこだけ更新したということでしょうか?
(私のは、座標のほかに法線・カラー・UVも毎フレームVRAMに転送しています)

>前者は動的バッファがたまり次第フラッシュ
これはどういう方法でしょうか?
D3DLOCK_DISCARDではない方法ですかね

325 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 11:36:58 ]
定数レジスタの数について質問があります
DX8時代は96
DX9時代は256
というのはなんとなく知っているのですが、これは頂点シェーダのバージョンに依存しているのでしょうか?

もしそうだとして
定数レジスタを200個近く使っている状態で
VertexShader = compile vs_1_1 vertexShader();
とやったとき、問題なく動作してしまうのが不思議です
エラーもでませんし、見た目も問題なく表示されてしまうのです

326 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 12:08:32 ]
最低サイズが だろ?
詳細はcapsで調べれたと思う
どのみち最低サイズを守った方が利口だが

327 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 13:03:54 ]
ICH10RでSSD2台で7RCでRAID0組みたいです。途中でFDDからRAIDドライバ読み込み必要ですか?

328 名前:デフォルトの名無しさん mailto:sage [2009/07/10(金) 23:54:37 ]
>>324です。
原因がわかりました。

どうやら、>>306のように、ロックしてからループで書きこんでいくのはよろしくないようです。
>>312のように、一時バッファを用意して全部メインメモリ上で書きこんでから、Lock。
memcpyでいっきに流し込みすぐUnlock
とやることで、UP系と同等の性能になりました。
「これならUPでいいじゃん」って思ってしまいますね…。

329 名前:316 mailto:sage [2009/07/11(土) 12:23:40 ]
>>324
なんの工夫もなくロックして位置や色を書き込み
memcpy未使用

フラッシュはバッファに溜まったものを吐き出すって意味
今時使わない?俺もロートルか



330 名前:316 mailto:sage [2009/07/11(土) 13:00:33 ]
memcpyでもやってみたが同じだな

フォーラムをざっと見てきたが、UPはレガシー扱いで間違いないだろう
・UPはハードウェアサポートが約束されていない
・UPは中間バッファを勝手に使うからパフォーマンスが落ちる(チューニングしづらい)
  少なくとも2倍から3倍のメモリを使う
・描画命令を出しても、完了してから制御を戻すわけでないので、UPのために確保したメモリがいつまで妥当であるべきかが不定
・例え変化が無くてもmemcpyが描画命令のたびに呼ばれる(最適化が出来ない)

問題の件だが、冗長なメモリコピーがそのままUPのコストになるので、
扱う頂点数が増えるほどUPは不利になるだろう
おそらく結果が逆転してしまうなら、正しく使えてないのだと思う

331 名前:デフォルトの名無しさん mailto:sage [2009/07/11(土) 13:12:57 ]
ロックが長いってだけで、1.6倍の遅延に繋がるとは思えない。
なぜそうなるのか、シナリオが作れない。
誰か説明してくれない?






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<251KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef