トップページ⇒tech
1001コメント284KB

【C++】 DirectX初心者質問ｽﾚ Part31 【C】

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/09/30(木) 21:45:21
※回答する人も、質問する人も必ず読んでください

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

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

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

前スレ
【C++】 DirectX初心者質問ｽﾚ Part30 【C】
http://hibari.2ch.net/test/read.cgi/tech/1278214135/
0582デフォルトの名無しさん2010/10/19(火) 15:19:25
DirectX SDKの最新版では　VisualC++2005　のサポートが打ち切られたと聞きました
テキストに買ってきた書籍が少し古くて　2005　基準で書かれたものなのですが
ここに書かれているソースコードが使えないということなのでしょうか
それともVisualC++2010　に DirectX SDK の最新版を入れて　同じ環境とみなせるでしょうか

サポートが打ち切られるというのがどういうことか分りません
0583デフォルトの名無しさん2010/10/19(火) 15:19:27
システムメモリとVRAMを共用してるようなビデオチップだとどっちでも変わらなかったり
0584デフォルトの名無しさん2010/10/19(火) 15:27:18
>>582
ソースコードが使えなくなるということではない
2010で動かすなら問題なく使える

とりあえず目立つところではたぶんサンプルから2005用のソリューションが消えたんじゃない？
あとは今後.libの互換性がなくなって
2005＋2010Oct以降だとリンクができなくなる(かもしれない)
0585デフォルトの名無しさん2010/10/19(火) 15:34:31
SDKのOct 2010なんて何処にある？
MSDN探しても見当たらないぞ。
0586デフォルトの名無しさん2010/10/19(火) 15:39:58
探したけどOct 2010なんてないなｗ
0587デフォルトの名無しさん2010/10/19(火) 15:41:25
釣りだったのか？
0588デフォルトの名無しさん2010/10/19(火) 15:44:34
>>584
ありがとうございます　とりあえず同じ環境とみなして進めていきます
.lib の互換性がなくなるというのは文法も変わってしまうということ？
サポートの打ち切りとはどういった背景（理由）で行われたかわかりますか
何か変えなくてはいけないことがあったんだと思うのですが
0589デフォルトの名無しさん2010/10/19(火) 15:47:58
M$の陰謀
0590デフォルトの名無しさん2010/10/19(火) 15:48:48
>>585
DirectX SDK は３，４か月に一度更新されているようですので　今後更新されるであろう
バージョンをさしてOct 2010（以降）と言ったのだと思います
0591デフォルトの名無しさん2010/10/19(火) 15:51:12
>>579
D3DLOCK_DISCARD使ってるから、使い方間違えてはいないと思うんだけどなぁ・・・

>>581の言う通り、1ループで1回しかLockしないから誤差の範囲内なのかもしれん。

>>583
GF9600だから、動的のほうが速いのを期待したんだけどなー
0592デフォルトの名無しさん2010/10/19(火) 16:00:05
>>581
そもそも1つのループで複数回ロックは論外。
0593デフォルトの名無しさん2010/10/19(火) 16:04:17
>>592
D3DLOCK_NOOVERWRITEでロックして追記や部分書き換えすればそれほどコストは掛からないんだぜ
これをD3DLOCK_DISCARDでロックするとアホみたいなことになる
0594デフォルトの名無しさん2010/10/19(火) 16:06:51
>>576
考えられる問題点

読み込みを伴うアクセスを行っている
全体を書き換えるのにDiscardを指定していない
Lockを複数回行っている
0595デフォルトの名無しさん2010/10/19(火) 16:08:41
>>593
そもそも何度もロックを繰り返すようなプログラムを組まなければならない時点で、
処理に無駄が多すぎる。
0596デフォルトの名無しさん2010/10/19(火) 16:17:41
>>594
んー、どれにも当てはまらないなぁ…。
とはいっても、さすがに俺のコードに問題があるんだろうし、ちょっと今再度計測してみるわ
0597デフォルトの名無しさん2010/10/19(火) 16:18:19
環境によって違う場合もあるしテストコードをうｐ
0598デフォルトの名無しさん2010/10/19(火) 16:19:50
ロックを繰り返さない方法って、ある程度は仕方ないと思うんだが、
どーすりゃいいんだ。
0599デフォルトの名無しさん2010/10/19(火) 16:26:50
1フレーム1回のDrawPrimitiveに対し複数回のLockは無駄でしかないが
1フレーム複数回のDrawPrimitiveに対し複数回Lockは当然あり得る
複数Lockする必要が無いなんていってる奴は単純な描画しかしたことがないんじゃね？
0600デフォルトの名無しさん2010/10/19(火) 16:29:35
>>599
やっぱりそうですよね。
0601デフォルトの名無しさん2010/10/19(火) 18:11:14
んー、やっぱり差が見られないなぁ

D3DPOOL_DEFAULT版
dev->CreateVertexBuffer(
desc.Size,
D3DUSAGE_WRITEONLY | D3DUSAGE_DYNAMIC,
desc.FVF,
D3DPOOL_DEFAULT
&buffer,
NULL
);
buffer->Lock(0, 0, &to, D3DLOCK_DISCARD);
::memcpy(to, from, desc.Size);
buffer->Unlock();

D3DPOOL_MANAGED版
dev->CreateVertexBuffer(
desc.Size,
0,
desc.FVF,
D3DPOOL_MANAGED
&buffer,
NULL
);
buffer->Lock(0, 0, &to, 0);
::memcpy(to, from, desc.Size);
buffer->Unlock();

こんな感じ。
もちろんCreateVertexBufferは最初の1回だけね。
モーフィングをやろうとして色々研究してたんだけど、D3DLOCK_DISCARDを使っても早くならねーなーと思ってたとこ。
後者のほうが微妙に速い上、D3DLOCK_DISCARDしないでモーフィング差分だけ書き変えればいい（memcpyいらね）から、ますます後者が速くなるんだ
0602デフォルトの名無しさん2010/10/19(火) 20:35:36
D3DPOOL_MANAGEDで作った頂点バッファは静的バッファってことでいいっすか？
0603デフォルトの名無しさん2010/10/20(水) 10:51:33
MANAGEDとD3DUSAGE_DYNAMICは共存できない

・・・いや、もしかしてMANAGEDの野郎、1度でも動的な使い方したら、内部で動的として確保しなおすとかしやがるのか・・・？
0604デフォルトの名無しさん2010/10/20(水) 12:22:51
下手に頂点バッファ使うくらいなら大人しくDrawXxxUP版にしておけば
すべての悩みから開放されます
0605デフォルトの名無しさん2010/10/20(水) 12:36:58
それは何ですか？
0606デフォルトの名無しさん2010/10/20(水) 13:19:02
D3DLOCK_NOOVERWRITE は、既に使用中である動的バッファー内のデータをアプリケーションが上書きしないことを示します
ロック呼び出しは古いデータへのポインターを返します。これにより、アプリケーションは
頂点バッファーまたはインデックス バッファー内の未使用領域に新しいデータを追加できます。

この古いデータへのポインターっていうところなんですが、
1000KBの頂点バッファがあったとして、200KB分しか使用してなかったとしたら、
その200KBの先頭のポインタを取得できるってことでしょうか？

もしそうだとしたら、未使用領域に新しいデータを追加できるっていうのは、
この先頭ポインタから200KB分のポインタを進めたところから追加しろってことでしょうか？
0607デフォルトの名無しさん2010/10/20(水) 13:25:59
それはないとおもう
0608デフォルトの名無しさん2010/10/20(水) 13:30:00
思ったんですが、座標を変えなきゃいけないやつは、DrawPrimitive系を使わない方がよくないですか？
座標をいじらずに、行列とかで移動できるやつはDrawPrimitive系でいいかもしれませんが、
それ以外の直接座標をいじるやつに関しては、DrawPrimitiveUP系を使ったほうが、管理とか速度面においても、
良いきがするんです。
0609デフォルトの名無しさん2010/10/20(水) 13:30:12
合ってるよ

0-199までLock
0-199までをDrawPrimitive
200-399を(使用中かもしれない0-199の中身が変わらないことを保証して)Lock
200-399までをDrawPrimitive

みたいな時に使う
0610デフォルトの名無しさん2010/10/20(水) 13:34:14
>>609
ありがとうございます！

ですが200-399までをDrawPrimitiveするときの、引数の指定がよく分からないです。
MSDNには、第二、第三引数は下記のように設定しろと載ってました。

StartVertex
[in] ロードする最初の頂点のインデックス。StartVertex を先頭に、正しい頂点数が頂点バッファから読み取られる。
PrimitiveCount
[in] レンダリングするプリミティブの数。プリミティブの許容最大数は、D3DCAPS9 構造体の MaxPrimitiveCount メンバをチェックして決定される。
PrimitiveCount は、プリミティブ タイプで指定されたプリミティブの数である。ライン リストの場合、各プリミティブは 2 つの頂点を持つ。三角形リストの場合、各プリミティブは 3 つの頂点を持つ。

これのプリミティブの数は分かりますが、頂点のインデックスって言う値が良くわからないです。
インデックスって何のことですか？
0611デフォルトの名無しさん2010/10/20(水) 13:51:16
>>610
頂点何個分ずらした位置から読むか
0-199で200プリミティブ(600頂点)だとしたら
200-399での先頭頂点は600、から200プリミティブ
400-599での先頭頂点は1200、から200プリミティブ
0612デフォルトの名無しさん2010/10/20(水) 14:24:18
>>611
なるほど！ありがとうございました！
0613デフォルトの名無しさん2010/10/20(水) 14:27:10
D3DDECLUSAGE_POSITIONTを使うのって邪道ですか？
0614デフォルトの名無しさん2010/10/20(水) 14:32:50
>>613
邪道ではないけど、いろいろ融通が利かなくなるから結局普通にやった方がよくなりそうな
0615デフォルトの名無しさん2010/10/20(水) 14:35:30
>>614
うう。そうですか。
どうにかして通常の座標変換で左上を0,0として、スクリーン座標で指定できる
方法があればいいんですが。
0616デフォルトの名無しさん2010/10/20(水) 14:44:04
>>615

http://hibari.2ch.net/test/read.cgi/tech/1278214135/781
0617デフォルトの名無しさん2010/10/20(水) 15:15:56
落ちちゃってますね。。。
0618デフォルトの名無しさん2010/10/20(水) 15:25:52
781 名前：デフォルトの名無しさん[sage] 投稿日：2010/09/13(月) 23:31:17
>>>780
>2Dスプライトを直感的にスクリーン座標と一致させたいってことだよね？
>パースペクティブ射影(D3DXMatrixPerspectiveFovLH)じゃなくて
>正射影(D3DXMatrixOrthoOffCenterLH)で射影行列作ればいいと思うよ
>スクリーンサイズが800x600なら
>
>D3DXMatrixOrthoOffCenterLH( D3DXMATRIX *pOut, 0, 800, 600, 0, FLOAT zn, FLOAT zf);
>
>で左上(0.0)になって分かりやすいんじゃないかな
>
0619デフォルトの名無しさん2010/10/20(水) 15:30:05
ありがとうございました
0620デフォルトの名無しさん2010/10/20(水) 16:51:30
カメラ空間はこう、ワールド空間はこう、射影空間はこう、ビューポート空間はこう
みたいな解説をしてくれてるページってないですかね？
0621デフォルトの名無しさん2010/10/20(水) 16:59:07
>>620
http://msdn.microsoft.com/ja-jp/library/ee422511(v=VS.85).aspx
0622デフォルトの名無しさん2010/10/20(水) 17:03:18
>>621
ありがとうございます。
0623デフォルトの名無しさん2010/10/20(水) 17:11:32
>>608
UP系の最大の欠点は頂点ストリームが1つしか使えないこと
それでまかなえる程度の単純なスプライト描画しかしないなら十分な速度は確保できると思われ
0624デフォルトの名無しさん2010/10/20(水) 17:38:18
>>623
ああ・・そういえばそうでしたね。
検討してみます。ありがとうございました。
0625デフォルトの名無しさん2010/10/20(水) 20:15:18
何度も質問して申し訳ないんだが、
DrawPrimitiveUPとDrawIndexedPrimitiveUPではどちらの方が効率が良いのでしょう？

DrawPrimitiveUPでもD3DPT_TRIANGLESTRIPで描画すればそんなに変わらないでしょうか？
0626デフォルトの名無しさん2010/10/20(水) 20:45:42
質問するよりも、自分で試してみるといいよ。
0627デフォルトの名無しさん2010/10/20(水) 22:32:31
俺が計った環境だとUPは何故か頂点数が多いにも関わらず
DrawIndexedPrimitiveUPよりDrawPrimitiveUPの方が速かった
0628デフォルトの名無しさん2010/10/21(木) 03:52:44
結局、DirectXのAPIはインターフェイスを提供してるだけであって
実際は、各グラボのドライバの処理による環境依存だからね

その時点までの他の頂点を含む状況、今描画しようとしている頂点内容や数、
これらの組み合わせで、どれが効率良いかなんて言えない

だから、これが効率的だ(自分のPCだけの話ってなら別だが)、
なんて物を求めないで、これは大多数のケースで非効率だって実装を避ければ良いだけだと思うが
0629デフォルトの名無しさん2010/10/21(木) 09:12:34
最後に一つだけ。。。本当ごめん。

色々やってみたんですが、DrawPrimitive系(UP含む）では、
四角形のポリゴンを一気に描くことはできないですよね？
ここで言う一気とは「一回の」DrawPrimitiveで描画という意味です。
何度やっても、思い通りの頂点と頂点がつながってくれなかったので、
最終確認したいんです。

これを可能にするにはDrawIndexedPrimitive系(UP含む)で、好きな頂点を指定してあげて
自分の思ったとおりに描画させるしかないってことでよいでしょうか？
06306292010/10/21(木) 09:13:58
ここで言っている四角形はお互いがくっついているわけではなく、
バラバラにある一定の距離を保って、大量にあるものとします。
0631デフォルトの名無しさん2010/10/21(木) 09:41:06
トライアングルリストで6頂点使えばいける
06326292010/10/21(木) 09:56:48
方法としては、順番に６頂点ずつバッファを埋めていけば、出来るってことですか？
0633デフォルトの名無しさん2010/10/21(木) 10:00:36
yes
06346292010/10/21(木) 10:04:21
>>633
ありがとうございました。嬉しいです。
頑張ります。当分一人で頑張りますね。
0635デフォルトの名無しさん2010/10/21(木) 22:30:01
VC2008でDXライブラリを使用しています
PlayMusic命令でMIDIファイルが再生できません
0x4b7e2bd8 で初回の例外が発生しました: 0xC0000005: 場所 0x4b7e2bd8 を読み込み中にアクセス違反が発生しました。
というエラーで出力が埋め尽くされています…
0636デフォルトの名無しさん2010/10/21(木) 22:31:44
>>635
知らんがな
http://hibari.2ch.net/test/read.cgi/gamedev/1286180687/
0637デフォルトの名無しさん2010/10/21(木) 22:32:56
そっちのあったのですね
素早いご指摘ありがとうございました
0638デフォルトの名無しさん2010/10/22(金) 00:27:34
たまにDXライブラリの質問が来るなあ
0639デフォルトの名無しさん2010/10/22(金) 00:45:44
DXライブラリは2chで聞くより本家で聞いたほうが速い希ガス
0640デフォルトの名無しさん2010/10/22(金) 02:42:29
FloatMax()なんて今更誰得だよ
0641デフォルトの名無しさん2010/10/22(金) 03:15:30
>>640
0642デフォルトの名無しさん2010/10/22(金) 07:14:42
それだけDXライブラリがいいってことだな
0643デフォルトの名無しさん2010/10/22(金) 07:24:05
DXライブラリを使う人間に、適切なスレを判断する程度の能力すらない者が多く混じっているということだろう。
0644デフォルトの名無しさん2010/10/22(金) 15:49:02
DXライブラリのスレにDirectXについて質問しにいったらどうなるのっと
0645デフォルトの名無しさん2010/10/22(金) 16:17:28
なんで自分でプログラミングする以前の問題として、
まともなモデリングソフトを触って研究しようとしないんだろう？
どれだけ馬鹿なの？
0646デフォルトの名無しさん2010/10/22(金) 16:20:29
はいはい、えらいでちゅねぇ
0647デフォルトの名無しさん2010/10/22(金) 17:54:58
シューティング作ろうと思ってるんですが、
弾は動的確保にしたほうがいいですか？
0648デフォルトの名無しさん2010/10/22(金) 18:07:23
>>647
一度に画面に出る最大数を決めておいて配列で用意したらいいじゃん
0649デフォルトの名無しさん2010/10/22(金) 18:08:13
>>648
やっぱりそのほうがいいですか？
動的確保はやっぱり重いでしょうか？
0650デフォルトの名無しさん2010/10/22(金) 18:15:01
初心者は重いかどうかなど考えなくて良い。
馬鹿の考え休むに似たりということにしかならない。
余計なことは考えずにやりたいようにどんどん作れ。
0651デフォルトの名無しさん2010/10/22(金) 18:15:21
>>649
やりたきゃ好きにしろよ
あんまり意味はなさそうだけど
なんだ？
弾一発めちゃくちゃ場所とるのか？
0652デフォルトの名無しさん2010/10/22(金) 18:42:37
>>649
とりあえずn発までがMAXって定義しといて、先に領域確保しといて弾ブッパするのと
１発ずつ確保してブッパするプログラム組んで、速度見てみるといいと思うの。
0653デフォルトの名無しさん2010/10/22(金) 18:52:26
>>649
処理オチする位に弾出してみればいいじゃん。そこから逆算してみたら？
むかーし、セレロン600Mhz位とGPU不明でやったときでも100位は出てたぞ。
現実的に３００位出ちゃうとよけるの不可能じゃね？
0654デフォルトの名無しさん2010/10/22(金) 19:15:02
皆さんたくさんの意見ありがとうございました。
とりあえず好きにやってみて、処理落ちしたらまた考えます。
ありがとうございました。
0655デフォルトの名無しさん2010/10/22(金) 19:15:59
「馬鹿の考え休むに似たり」

いい言葉だな
0656デフォルトの名無しさん2010/10/22(金) 19:19:24
連射によるメモリーが足りなくなる場合のテストとかめんどくさそうだ
0657デフォルトの名無しさん2010/10/22(金) 19:30:06
馬鹿の考え休むに似たりですね。覚えときます。
0658デフォルトの名無しさん2010/10/22(金) 20:33:53
>>656
何億発打てばメモリ不足になるんだよ？
というか馬鹿？
0659デフォルトの名無しさん2010/10/22(金) 20:37:41
メモリ不足より分断化の方が気になる
動的確保にしても予め確保しといたヒープ内からとかにしたい所だ
0660デフォルトの名無しさん2010/10/22(金) 20:39:32
＞連射によるメモリーが足りなくなる場合のテストとかめんどくさそうだ
馬鹿の考え休むに似たり

＞メモリ不足より分断化の方が気になる
馬鹿の考え休むに似たり
0661デフォルトの名無しさん2010/10/22(金) 20:48:25
メモリフラグメンテーションは普通に起きそうだけどな
0662デフォルトの名無しさん2010/10/22(金) 21:01:53
>>658
しらないけど、動的に取るならテスト項目に上がるでしょ？
0663デフォルトの名無しさん2010/10/22(金) 21:07:50
「しらないけど」ってどれだけアホな発言しているんだよ
0664デフォルトの名無しさん2010/10/22(金) 21:14:44
>>663
じゃ何発打てばメモリー不足になるんですか？
0665デフォルトの名無しさん2010/10/22(金) 21:43:26
動的に確保したら
解放とか忘れちゃうだろ
0666デフォルトの名無しさん2010/10/22(金) 21:52:34
っSTL
0667デフォルトの名無しさん2010/10/22(金) 21:55:41
STLはそのつど動的に確保してるわけじゃなくて
最初にある程度大きく確保しておいてその範囲内の内はそこから確保されるので
結局配列で確保したのと一緒になる
0668デフォルトの名無しさん2010/10/22(金) 22:22:32
STGの敵の弾はタスクシステムが一番だと思います。
重い仮想関数とか使わずとも多態化できますし。



嘘です。上のようなこと書くとスレがと荒れるらしいです。
0669デフォルトの名無しさん2010/10/22(金) 22:36:44
STLといってもアルゴリズムが複数あって手法が異なるのに
特定のアルゴリズムの限定的な話を突然始める>>667みたいな馬鹿って何なの？
0670デフォルトの名無しさん2010/10/22(金) 22:58:38
まあ、ぶっちゃけ今回の例だと動的確保してもメリットないよでＦＡだな
デメリットは穴ぼこメモリもたしかに気になるけど
それも極小すぎてデメリットといえるかどうかっつーとよくわからないな
ガベコレ動き出したコレ！とかいうjavaみたいな環境ならデメリットありまくりだけどｗ

まあ、でもかっちょよく（？）動的にしたいなら
「意味はないけど好きやりたいなら好きにしたらいーんじゃないですか？
それであなたが気持ちよくゲームを作れるならそれもいーんじゃないですか」でＦＡ
0671デフォルトの名無しさん2010/10/23(土) 04:03:24
お前らここ何のスレか分かってる？
0672デフォルトの名無しさん2010/10/23(土) 04:53:32
スレチうざいから消えろ
0673デフォルトの名無しさん2010/10/23(土) 05:02:26
comインターフェースってwindowsがドライバのAPI呼んで実体作ってるんでしょ？
メモリ管理とかどうなってるの？
0674デフォルトの名無しさん2010/10/23(土) 05:15:30
>>672
なんか語りたい話題があるならどうぞ
0675デフォルトの名無しさん2010/10/23(土) 07:02:57
>>673
COMはインタフェイスの実装手法であって、ドライバ云々との関連は通常のAPIと同じでしかない。
0676デフォルトの名無しさん2010/10/23(土) 10:44:07
ある空間上の点が、ウィンドウ上で描画領域内に
収まっているかどうかわかる方法はありますか？
0677デフォルトの名無しさん2010/10/23(土) 11:12:56
投影してみればいい
0678デフォルトの名無しさん2010/10/23(土) 11:16:33
>>676
点を座標変換して射影空間内に収まってるかどうかをチェックする

D3DXMATRIXA16 matWorld,matView,matProj;//各変換行列
D3DXVECTOR3 v ;// 空間上の点

D3DXVec3TransformCoord ( &v, &v, &(matWorld*matView*matProj) ) ;//既に移動済みの点ならmatView*matProj

-1.0 <= v.x <= 1.0
-1.0 <= v.y <= 1.0
0.0 <= v.z <= 1.0

でどうだろう？
0679デフォルトの名無しさん2010/10/23(土) 14:26:29
PIXで分かった希ガス
0680デフォルトの名無しさん2010/10/23(土) 18:36:23
DirectXはCOMで使うのとLoadLibraryどっちが良いの？
0681デフォルトの名無しさん2010/10/23(土) 20:55:22
サミータウンをやりたくて本日登録してゲームをダウンロードしたんですがDirectXのダウンロードに失敗したと出て起動出来ません…
どうしたら起動出来ますか？
0682デフォルトの名無しさん2010/10/23(土) 20:58:56
ここはDirectX"プログラム"の質問スレです
エンドユーザーの方はご遠慮下さい
■ このスレッドは過去ログ倉庫に格納されています