09/07/10 00:05:10
>>296
その根拠は？
>>292
動的バッファLock時のオプションは
どうしてる？
300:デフォルトの名無しさん
09/07/10 00:14:21
>>297
む、こりゃちょっとひどい気がする
スレちゃんと読んでないけど、xyzは毎フレーム変化してるんだよな？
どのタイミングで更新してるんだい？
301:デフォルトの名無しさん
09/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
え、初心者サイトのサンプルをほぼそのまま使ったのですが、妙でしょうか？
ｘｙｚの更新は、Lockの前に行っています。
m_smokesというのが、ビルボードの中心座標の配列vector<D3DXVECTOR3>です。
302:デフォルトの名無しさん
09/07/10 00:24:23
ちゃんとD3DLOCK_DISCARDでロックしてるし、
動的バッファの取り扱いは、特に問題はなさそう。
へえ、これでUP系の半分の性能なんだ、信じられんｗ
303:デフォルトの名無しさん
09/07/10 00:29:11
>>302
オンボ環境ではしっかりUPのほうが遅かったので、環境によるような気がします。
明日再度オンボ環境の場所に行くので、再度慎重に測り直してみます。
304:デフォルトの名無しさん
09/07/10 00:30:56
>>301
うーむ、Lockの前に更新って、矛盾してないか
このソースだとDYNAMICでバッファを確保した意味がないよ？
305:デフォルトの名無しさん
09/07/10 00:34:25
こりゃ計測方法も怪しくなってきたなｗ
両方のソース示さない限り無意味だろｗ
306:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/10 00:41:06
>>294=>>298=>>305
初心者スレ荒らして楽しい？
他人の足引っ張って立って、自分の価値を高めることにはならないぜ？
無意味だと思うならスルーしてなよ
308:デフォルトの名無しさん
09/07/10 00:43:46
特に問題あるようなソースには見えないな
UP系のほうが早い場合があるというのは面白い
UPはドライバ側で何かしらの最適化を行っているのかもね
309:デフォルトの名無しさん
09/07/10 00:44:01
>>307
連続でお疲れさんｗ
310:デフォルトの名無しさん
09/07/10 00:45:48
294 indexbufferも使えない素人が！（ｷﾘｯ!!
297 >>294 IndexBufferは使ってますよ
腹抱えてﾜﾛﾀｗ
311:デフォルトの名無しさん
09/07/10 00:53:01
久々に有益情報が出てるな
俺は何も考えずにDrawPrimitiveUP使ってた
Instancingとやらを使うと速度が5倍になるとかマジパネェから俺も実験してみるわ
312:デフォルトの名無しさん
09/07/10 00:53:04
俺のソースでは、mallocaで確保した一時バッファにデータを作ってから
Lock→memcpyでまるごとコピー→Unlock と、
ロックしている時間が短くなるようにしてたな。
なんとなくその方が良かろうと思っただけで、計測してないから鵜呑みにはするな。
313:デフォルトの名無しさん
09/07/10 00:57:20
294じゃないけど、よくおまえらそこまで無条件で信用できるな。
煽る気はないけど、ソースのないベンチなんて昔は弾いていた気がするんだが。
314:デフォルトの名無しさん
09/07/10 01:01:39
DirectX10使えば縮退ポリゴンもいらねーしデータ転送量も抑えられるしでウハウハ。
SO使えば座標更新もGPUで出来てさらにウハウハ。
315:デフォルトの名無しさん
09/07/10 01:06:14
>>312
D3DLOCK_DISCARDを指定すると、
一時バッファを用意してくれるらしいので
その処理は冗長と言える。
316:デフォルトの名無しさん
09/07/10 01:16:45
俺もGeforce9600GTなんで、さくっと試してみたよ
DrawIndexedPrimitiveとDrawIndexedPrimitiveUP
LVetexで位置のみ毎時更新
前者は動的バッファがたまり次第フラッシュ
後者もそれに合わせようと思ったけど、面倒なんでメモリ一括確保
疲れてるんで固定機能でやったけど、1万ポリでも誤差程度
寝る
317:デフォルトの名無しさん
09/07/10 01:20:16
>>316
そうなるはずだ。
UP系かそうでないかでそんなに差が出るというのはちょっとおかしいんじゃないか。
プリミティブの座標更新をGPUにやらせることで全体の高速化を図るというのならまだ分かるが。
318:デフォルトの名無しさん
09/07/10 01:30:53
>>316
結局描画におけるGPUの時間が変わらないからフレーム単位だと時間は変わらないが
DrawPrimitive()とDrawPrimitiveUp()だと関数から帰ってくるまでの時間にかなり差があったと思うが。
319:デフォルトの名無しさん
09/07/10 02:04:48
DirectShowのスレでも質問したのですが、スレの勢いを考えてこちらにも質問させていただきます。
DirectShowでGeekなページを参考に動画再生をするプログラムを作りました
URLﾘﾝｸ(www.geekpage.jp)
参考ＵＲＬでは『put_Rateの引数を2.0などに変更すると倍速再生になります。
put_Rateの引数に負の値（マイナスの値）を渡すと巻き戻し再生になります』
とありますが、
pMediaPosition->put_Rate(0.5);
のput_Rateの引数を負の値にしても大部分のフィルタは逆再生をサポートしていないため実行されません。
そこでIMediaSeekingかIMediaPositionを用いて、または用いなくてもいいのでdirectshowで
動画の巻き戻しをするプログラムを作りたいのですが、どうすればよいのやら困っています。
何か良い考えはないでしょうか？
是非知恵をおかしください！
320:デフォルトの名無しさん
09/07/10 04:29:31
テクスチャのサンプリングをWrapにして何度も繰り返すような貼り方をすると負荷が高いと聞いたんですが
これは本当ですか？
使用するテクスチャが小さくなるから、むしろこっちのほうが良いと思ったんですが
自分の環境（ GTX280 )では違いが見られなかったんですが
オンボードのような低スペックのビデオカードだと遅くなったりしますか？
321:デフォルトの名無しさん
09/07/10 08:27:10
うそです。
322:デフォルトの名無しさん
09/07/10 08:28:23
ゲームの動画再生にDirectShowはいつも使っているけど、再生速度の変更が必要になったことがないから知らない。
323:デフォルトの名無しさん
09/07/10 08:34:33
AGPっていつの時代だよw
324:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/10 11:36:58
定数レジスタの数について質問があります
DX8時代は96
DX9時代は256
というのはなんとなく知っているのですが、これは頂点シェーダのバージョンに依存しているのでしょうか？
もしそうだとして
定数レジスタを200個近く使っている状態で
VertexShader = compile vs_1_1 vertexShader();
とやったとき、問題なく動作してしまうのが不思議です
エラーもでませんし、見た目も問題なく表示されてしまうのです
326:デフォルトの名無しさん
09/07/10 12:08:32
最低サイズが だろ？
詳細はcapsで調べれたと思う
どのみち最低サイズを守った方が利口だが
327:デフォルトの名無しさん
09/07/10 13:03:54
ICH10RでSSD2台で7RCでRAID0組みたいです。途中でFDDからRAIDドライバ読み込み必要ですか？
328:デフォルトの名無しさん
09/07/10 23:54:37
>>324です。
原因がわかりました。
どうやら、>>306のように、ロックしてからループで書きこんでいくのはよろしくないようです。
>>312のように、一時バッファを用意して全部メインメモリ上で書きこんでから、Lock。
memcpyでいっきに流し込みすぐUnlock
とやることで、UP系と同等の性能になりました。
「これならUPでいいじゃん」って思ってしまいますね…。
329:316
09/07/11 12:23:40
>>324
なんの工夫もなくロックして位置や色を書き込み
memcpy未使用
フラッシュはバッファに溜まったものを吐き出すって意味
今時使わない？俺もロートルか
330:316
09/07/11 13:00:33
memcpyでもやってみたが同じだな
フォーラムをざっと見てきたが、UPはレガシー扱いで間違いないだろう
・UPはハードウェアサポートが約束されていない
・UPは中間バッファを勝手に使うからパフォーマンスが落ちる(チューニングしづらい)
少なくとも2倍から3倍のメモリを使う
・描画命令を出しても、完了してから制御を戻すわけでないので、UPのために確保したメモリがいつまで妥当であるべきかが不定
・例え変化が無くてもmemcpyが描画命令のたびに呼ばれる(最適化が出来ない)
問題の件だが、冗長なメモリコピーがそのままUPのコストになるので、
扱う頂点数が増えるほどUPは不利になるだろう
おそらく結果が逆転してしまうなら、正しく使えてないのだと思う
331:デフォルトの名無しさん
09/07/11 13:12:57
ロックが長いってだけで、1.6倍の遅延に繋がるとは思えない。
なぜそうなるのか、シナリオが作れない。
誰か説明してくれない？
332:デフォルトの名無しさん
09/07/11 13:35:23
>>330
・描画命令を出しても、完了してから制御を戻すわけでないので、UPのために確保したメモリがいつまで妥当であるべきかが不定
流石にこれはないだろ。
UPを呼び出した直後に、確保したメモリーを壊してしまっても大丈夫だよ
333:316
09/07/11 14:12:18
>>332
さてどうだろうな
描画命令はFIFOで処理されタイミングは不定
投げ入れ側は(Sendではなく)Post扱い
そしてUPの場合、向こう側で全コピーが必ず発生している
壊したメモリがたまたま生きていただけかもしれない
*大丈夫だった*以上のことは言えないはずだ
334:デフォルトの名無しさん
09/07/11 14:15:00
UP系は関数から抜けたときにはソースのデータは破棄してOKなはず。
ようするに中でメモリ確保してコピーして保持してるって事だけどな。
335:デフォルトの名無しさん
09/07/11 14:21:21
ハハ、DrawPrimitiveUPは
何時クラッシュするかわからない
ファイナルハゲマル丼的な関数というわけですね。
わかります。
336:デフォルトの名無しさん
09/07/11 14:23:18
>IDirect3DDevice9::DrawPrimitiveUP に渡す頂点データは、呼び出しの後も保持する必要はない。
>MicrosoftR Direct3DR は、呼び出しから戻る前に、そのデータへのアクセスを完了する。
>>330の引用元の信用がガタッと減ったな
337:デフォルトの名無しさん
09/07/11 14:25:35
MSDNの記事くらいは読もうよ。
＞IDirect3DDevice9::DrawPrimitiveUP に渡す頂点データは、呼び出しの後も保持する必要はない。
＞MicrosoftR Direct3DR は、呼び出しから戻る前に、そのデータへのアクセスを完了する。
338:316
09/07/11 14:27:54
>>336
こりゃすまなかったな
引用元はよく使うGDevだ
しかし全コピーが発生するのは間違いないだろう
339:デフォルトの名無しさん
09/07/11 14:30:06
>>336
だからこそUP系は遅いんだろ
>>318で既に出ているけど
340:デフォルトの名無しさん
09/07/11 14:30:50
UP系は中でDYNAMICなバッファのプールに対してLOCK_DISCARDと
DrawPrimitiveを必要な数繰り返していると推測できる。
341:デフォルトの名無しさん
09/07/11 15:01:39
>>340
その間制御を戻さないならば、CPU時間が減るし、
コピー後に制御を戻すとしても、メモリとコピー時間が無駄なわけだよね。
どう考えてもUP系の方が速くなるはずがないのだけど、
そもそも質問主以外にそんな結果の人はいるんですかね？いないなら不毛な気が・・・。
342:デフォルトの名無しさん
09/07/11 15:16:29
昔、散々会社で似たような検証してたみたいだけど
結局、使い方が悪いだけで変わらない（まあ、当然かｗ）って結論が出てたなｗ
343:デフォルトの名無しさん
09/07/11 15:20:01
だからといって、ある程度までの頂点数ならUP系でもほとんどペナルティーは無いわけだし、
種々のコンテナが使えるヒープメモリで間接的にレンダリング設定できるのはありがたい。
前作ったライブラリではUP系のみで実装した。
もっとも、現在製作中のライブラリは頂点バッファの確保/Lock込みで実装してしまったのでもう関係ない話だが……。
344:デフォルトの名無しさん
09/07/11 15:20:38
>>341
たんなるベンチ風に測れば速度は変わらないでしょ。
UP系は同期関数でUPじゃないほうが非同期って考えれば
データ量が多くなってゲームなんかでCPUを使うようになれば差が出てくると思う。
3Dゲームで毎フレーム書き換える頂点データつったらエフェクトくらいしか思いつかないけど。
345:デフォルトの名無しさん
09/07/11 15:23:47
２Ｄゲー作っててもたまに３Ｄゲーと同じような演出とかやりたいときあって
結局、UP系特化で作ったライブラリって開発してるとゴミになるぞ
346:デフォルトの名無しさん
09/07/11 15:37:54
UP系大好きなお前らに悲しいお知らせです。
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
＞DrawPrimitiveUP と DrawIndexedPrimitiveUP はどうなったのですか。
＞D3D10 で廃止されました。
347:デフォルトの名無しさん
09/07/11 16:16:24
>>340で正解だな。加えて毎回バッファのプールを再作成していたような。
ロックで遅くなるってヤツは、メモリアクセス中にCPUとGPUがバッティングしたらどうすんの。
UP系だって結局中で同じことをせざるを得ない。UP系が未来の技術でない限りは。
しっかし100レス近くも費やす内容なのかねぇ
348:デフォルトの名無しさん
09/07/11 16:25:30
>>347
まあ、とんちんかんなベンチレポとそれに賛同したり火消ししたりが延々と続いたからな。
ソースをさらしてれば話は早かったんだが。
349:デフォルトの名無しさん
09/07/11 16:48:56
>>346
やっぱ、意味ないよねｗ
350:デフォルトの名無しさん
09/07/11 16:59:16
>>344
変わらないならOKでしょ。むしろ速くなるっていうからさ。
まー質問主というより、無条件で賛同しちゃっている人が悪いな。
351:デフォルトの名無しさん
09/07/11 19:25:56
自演だろ
352:デフォルトの名無しさん
09/07/11 20:55:16
オンボ環境なら俺らが思ってるとおりの速さ順で、
GeForce9600GT下なら逆転する
って言ってるのだから、何かしらあるんだろ
面白い事象だと思うがねー
353:デフォルトの名無しさん
09/07/11 21:04:14
それじゃあ俺クロシコの9600GT入れてるんですけどまずいっすねえ
354:デフォルトの名無しさん
09/07/11 22:05:35
>>352
さすがにもう来ないでくれ
355:デフォルトの名無しさん
09/07/11 22:20:58
結局のところ逆転現象が起こる理由について誰も指摘できないわけか
356:デフォルトの名無しさん
09/07/11 22:30:09
ソースもexeもなしで何をどう説明できるんですか。
357:デフォルトの名無しさん
09/07/11 22:30:39
だから言ったろうに、端からチラ裏レベルの情報なんだから相手にする必要なし
ソースコードも出せない怪しげな情報まき散らされると、
まともな初心者さんに迷惑なんですがねぇｗ
358:デフォルトの名無しさん
09/07/11 22:35:53
みんなソースを出せと平気で言うけど
そんな簡単に出せるもんかね
誰も、使い捨てのテストプログラム作ってる訳じゃないでしょ
そこは、非難する部分じゃない
359:デフォルトの名無しさん
09/07/11 22:40:48
>>358
三角プリミティブ表示にDirectDraw使ったら、D3Dと変わらなかったよ。
ソースは出せないけど、コードは絶対間違ってない！
なんでこんな結果になるか説明して。環境？もちろん俺環境だお！
360:デフォルトの名無しさん
09/07/11 22:41:43
なんでもいいけどさあ
あんまり初心者っぽくない人多いよね
361:358
09/07/11 22:45:21
>>359
同じ現象になる使い捨てのテストプログラム作って
そのソースとEXEをアップしろよ
362:デフォルトの名無しさん
09/07/11 22:51:41
色々な要因が絡んでる場合、うまく抜粋してソース出せるとは限らんしな
それなりの報告とそれなりの信ぴょう性がありゃとりあえず「本当だとして」アドバイスするよ
それが気にくわないならレスしなきゃいい
363:デフォルトの名無しさん
09/07/11 22:52:40
>>361
簡単に言わないでください。非難…批難ｲｸﾅｲ!!
ボクの計測結果ならいくらでも出します。ほらDirectDrawの方が速くなりました
なんでですか！
…という流れだな
364:デフォルトの名無しさん
09/07/11 22:55:38
いずれにしろDirectX10ではなくなった。
DirectX11で復活することもないだろう。
過去のAPIの事はもういいじゃないか。
今からエンジン作るって人がDirectX9なんて選択しないし。
365:デフォルトの名無しさん
09/07/11 22:56:48
後はゲ製でどうよ？IDもあるし
ｽﾚﾘﾝｸ(gamedev板)
遠慮する気があるなら質問者から移動してくれ
マジで機能しねぇぞ初心者スレがｗ
366:デフォルトの名無しさん
09/07/11 23:22:10
別に他の質問のやりとりもあるし>>325-326
なんで機能しなくなるのかわからん
367:デフォルトの名無しさん
09/07/11 23:39:48
正直流れ速いと質問しづらいよ
368:デフォルトの名無しさん
09/07/11 23:41:25
>>364
え？2ヶ月前からDX9やり始めたんですけどDX10にしといた方がいいのかな？
持ってる本がDX9用だったんでつい・・・
369:デフォルトの名無しさん
09/07/11 23:45:00
>>368
もちろん最先端を勉強するとかいう目的ならDX10や11のほうが良い
が、実用品を作る（売る同人ゲームとか）目的なら、古い枯れた技術のほうが良い
そもそも10にしたら、XPユーザー全切りだぜ？
過去のAPIの事は～とか言っちゃう阿呆は気にしないでいいよ。このスレのタイトルすら読めないみたいだし
370:デフォルトの名無しさん
09/07/11 23:46:10
しっかしとってつけたような質問だな
371:デフォルトの名無しさん
09/07/11 23:50:44
10でも9でも好きなほうを使えばいい。
どっちみちWindows7が浸透するまで３年くらいはかかるだろうし。
372:デフォルトの名無しさん
09/07/11 23:51:20
いくら自己レスでも、初心者にDirectX11の勉強を勧ってすげぇな
373:デフォルトの名無しさん
09/07/11 23:52:03
そうだな・・・まあ興味本位でだから問題ないか
ところでボーンのアニメーションを作ってみたいんですけど
ID3DXAllocateHierarchy *p_AlllocHrachy;
ってやってD3DXLoadMeshHierarchyFromXで渡すとエラー出るんですけどなんでですか？
まさかこの辺は自分で作るんですか？
374:デフォルトの名無しさん
09/07/11 23:59:58
そうだよ
375:デフォルトの名無しさん
09/07/12 00:02:05
了解
調べてやってみます
376:デフォルトの名無しさん
09/07/12 00:04:15
DirectX9を最初から勉強するならDirectX10を
最初からやるほうがはるかに簡単だけどな。
DirectX9は細かいルールを覚えていくのが面倒くさい。
一般に公開するなら断然DirectX9だけど。
377:デフォルトの名無しさん
09/07/12 00:23:50
パーティクルの件でお騒がせしているものです
再現コードができましたのでUPしておきました
URLﾘﾝｸ(www1.axfc.net)
パス： particle
です。
中にソースとEXEが入っています。
描画方法をクラスでわけてあり、TypeAがUPを使った方。TypeBがロックして書きこむほうです。
起動するとそれぞれで1000回ほど描画を行い、それぞれのかかった時間をダイアログで表示します。
(1)がUP系、(2)がロックです。
GF9600GTでは下記の結果になります。なぜか後者のほうが断然遅い…。
(1) 2641 ms
(2) 4918 ms
きっとTypeBのほうに何か誤りがあるのだと思うのですが、アドバイスいただけると幸いです。
ちなみに>>328になるようにコードを書き直すと、だいたい同じくらいの速さになります。
378:デフォルトの名無しさん
09/07/12 00:27:52
キーワードが正しくありません
379:デフォルトの名無しさん
09/07/12 00:30:15
>>378
初心者スレ荒らして楽しい？ほんとに楽しい？
380:デフォルトの名無しさん
09/07/12 00:41:44
マジネタだったのか
381:デフォルトの名無しさん
09/07/12 01:01:27
MobilityRadeon9700だけど、
(1) 11849 ms
(2) 11959 ms
こっちは、ほぼ推測どおりの結果だね。
382:デフォルトの名無しさん
09/07/12 01:03:57
エラー: このリンクは無効です。
が出るけど荒らし認定されるのかしら
383:デフォルトの名無しさん
09/07/12 01:05:06
>>382
>>379
384:382
09/07/12 01:06:21
試しにリロードしたら早速レスついているし
こいつはずっと張り付いているんだろうか…
385:デフォルトの名無しさん
09/07/12 01:57:02
>>381は自演か
386:デフォルトの名無しさん
09/07/12 02:15:06
つながりにくいんじゃない？
パスは通ったけど俺も全然ダウンロードできない。
387:デフォルトの名無しさん
09/07/12 02:19:26
>>377
WRITEONLYで作った頂点バッファに対して読み取りアクセスしてるから遅いんだよ。
そこを修正したら、頂点バッファの方が速くなったよ。
388:デフォルトの名無しさん
09/07/12 03:49:19
>>377
移動してよ…
389:デフォルトの名無しさん
09/07/12 08:33:53
>>387
ありがとうございます。修正ができました。
代入しかしていないつもりでしたが、+=が実質参照していることに気が付けました。
WRITEONLYでも「読める」んですね…。
長々失礼しました。
一応言っておきますが、変なあおりレスとかはつけてません。こちらは質問させていただいている立場ですから。
390:デフォルトの名無しさん
09/07/12 08:48:16
389です。
気になったので、D3DUSAGE_WRITEONLYの説明を調べてきました。
URLﾘﾝｸ(msdn.microsoft.com)
＞この能力を使って作成された頂点バッファからの読み出しは失敗する
URLﾘﾝｸ(msdn.microsoft.com)
＞このフラグを使用する頂点バッファからの読み出しでは、メモリ アクセス時間が非常に低速になることがある
どっちだよ！といった感じですが、結果を見るに後者のようですね。
391:デフォルトの名無しさん
09/07/12 08:57:10
そもそもVRAMへのアクセスはAGPだと書き込みに対して読み込みが劇的に遅い。
PCIeで改善が図られているが、メインメモリに比べればやはり遅いのでやるべきではない。
392:デフォルトの名無しさん
09/07/12 09:10:33
御苦労さん
結果を報告してくれる質問者はいつでも歓迎だぞ
やっぱム板こそID欲しいよなー
393:デフォルトの名無しさん
09/07/12 10:39:41
まともな初心者さんに迷惑なんですがねぇ（笑）
さすがにもう来ないでくれ（笑）
自己レス（笑）
自演か（笑）
エラー: このリンクは無効です。（笑）
ほんとに屑が住み着いてるな
屑はさすがにもう来ないで欲しい
394:デフォルトの名無しさん
09/07/12 10:44:29
ファイルが見つかりません
395:デフォルトの名無しさん
09/07/12 10:54:08
このスレにクーラーが設置されました。
r─────┐
| l王三王三王三王三l o==ﾆヽ
| |王三王三王三王三| .| //
ゝ 乂━━━━乂＿| `-=
￣￣￣￣￣￣￣￣￣
/ / / / / / / /
/ / / / / / / ｺﾞｰｺﾞｰ
396:デフォルトの名無しさん
09/07/12 11:24:06
解決したからファイル消しちゃったのかな？
397:デフォルトの名無しさん
09/07/12 12:05:44
DirectXSDKをインストールしてるなら
DirectXのControlPanelでランタイムをDebugRuntimeに設定できる。
そうするとWRITEONLYへの読み込みを行った場合に
ビデオカードやドライバに関係なくDirectX層でエラーを履いてくれるようになる。
世間に出すようなプログラムの場合は必ずDebugRuntimeでの動作確認をしましょう。
398:デフォルトの名無しさん
09/07/12 13:12:51
>>394
すいません、解決したということで削除してしまいました
Lockした内容に対し
v.x = 1.0f;
v.x += data[i].x;
という、+=を使っていたのが原因でした
>>397
＞DirectXのControlPanelでランタイムをDebugRuntimeに設定できる。
これ知りませんでした。
早速試してみたら、いろいろ細かいエラーが出たのでささっと直せました。
すばらしいですね。入門サイトにはぜひ書いておいて欲しかった…。
良い情報ありがとうございました。
399:デフォルトの名無しさん
09/07/12 13:45:37
>>393
ID無いと便利ね（笑）
400:デフォルトの名無しさん
09/07/12 14:15:52
ソース見れないが、あれだけ説明したのに、結局UPも何も関係なかったわけかい。
情報を小出しにするからだよ。一番ダメなパターンだろ。
煽られて終わってもしょうがないのに、変に擁護がつくし、逆に俺が煽られるし。
WRITEONLYの線は>>306みて違うと思っていたが、じゃあ実際は別のコードなんだな。
401:デフォルトの名無しさん
09/07/12 15:53:17
いい加減にしないとこのスレ潰すから。
鬱だ死のうDirectXスレのように
402:デフォルトの名無しさん
09/07/12 16:35:19
>>400
一通り読んだが乙としかいいようがない。終始まともな回答ついているのねぇ。
原因は実装だからソース見ないと分からないってレスも早期にあるし。
403:デフォルトの名無しさん
09/07/12 18:46:35
別にスムーズにソースでてきたと思うんだが
>>328の段階でレスが終わって、その後ソース準備をしてたわけだろ？
単に質問者がいないとこで勝手に煽りあいしてｋｓｋしてたのを、質問者のせいにするなよ
404:デフォルトの名無しさん
09/07/12 18:51:06
再現ソースが出来てから質問しにくるのが最低限の礼儀だろ。
情報を小出しにするとか最悪すぎる。
405:デフォルトの名無しさん
09/07/12 18:57:34
>>404
別にそんなことはない。勝手に敷居を上げるなよ。
今回の件だって、蓋を開けてみれば、
動的バッファを扱う上でFAQと言えるべきものだった。
個人的には、ソースなんか無くても
証言だけでわかってしかるべきと思う。
まあ、全然わからなかった訳だが。
406:デフォルトの名無しさん
09/07/12 18:59:52
今回の件WRITEONLYのバッファにREADしてるのが原因なだけだろ。
DebugRuntimeにしてりゃエラーでてたろ。
407:デフォルトの名無しさん
09/07/12 19:10:52
>>406
誰一人として「Debugランタイムがなんかエラー吐いてないか？」と言っていないわけで
408:デフォルトの名無しさん
09/07/12 19:18:52
もういいよこの話題
409:デフォルトの名無しさん
09/07/12 19:20:01
とりあえず次からは>>1にDbugRumtimeについて書いておこうぜ
大抵の問題はあれのログ見ればわかる気がする
410:デフォルトの名無しさん
09/07/12 19:30:55
>>405
>>400
411:デフォルトの名無しさん
09/07/12 20:29:59
Windows7でもDX9使える？
412:デフォルトの名無しさん
09/07/12 20:33:29
DirectX3も動くだろ
413:デフォルトの名無しさん
09/07/12 22:24:37
tairanaporigondea)4wyd@)4-4fbweuyq@:s@
表示するときにテクスチャの一部分を選んで貼り付けるにはどうすればいいの？
414:デフォルトの名無しさん
09/07/13 00:11:04
UVを適切に設定しろ
415:デフォルトの名無しさん
09/07/13 00:17:51
それは頂点に含まれているので固定です。
416:デフォルトの名無しさん
09/07/13 01:21:22
描画時に変えられるようにしたいなら、データの時点で変えられるように考慮すべき。
どうしてもプリミティブ情報が確定してからいじりたいというのならシェーダを使う。
(UV座標変更かけるだけならvertex、pixelシェーダどっちでもいいかな？)
417:デフォルトの名無しさん
09/07/13 01:27:21
データがXファイルしかありません。モデリングツールは買えないので持ってません。
Xファイル読み込み処理は変えられません。レンダリングステートを設定するだけでなんとかさせてください。
…な予感。
418:デフォルトの名無しさん
09/07/13 01:50:51
いや、テクスチャステージステートで変えられるし
散々既出だよ
419:デフォルトの名無しさん
09/07/13 08:31:19
┏━━━┓ ┏━━━┓
┃┌─┬─┐┃ ┃┌─┬─┐┃
┏━┛│ │ │┗━┓ ┏━┛│ │ │┗━┓
┃┌─┼─┼─┼─┐┃ ┃┌─┼─┼─┼─┐┃
┃│ │ │ │ │┃ ┃│○│ │ │ │┃
┃├─┼─┼─┼─┤┃ ┃├─┼─┼─┼─┤┃
┃│ │ │ │ │┗━┛│○│●│ │ │┃
┃└─┼─┼─┼─┼─┬─┼─┼─┼─┼─┘┃
┗━┓│○│○│○│○│○│●│ │ │┏━┛
┃└─┴─┼─┼─┼─┼─┼─┴─┘┃
┗━━┓│●│●｜●│○│┏━━┛
┃├─┼─┼─┼─┤┃
┏━━┛│ │●│●│○│┗━━┓
┃┌─┬─┼─┼─┼─┼─┼─┬─┐┃
┏━┛│ │ │ │ │●│○│○│○│┗━┓
┃┌─┼─┼─┼─┼─┴─┼─┼─┼─┼─┐┃
┃│ │ │ │ │┏━┓│●│ │ │ │┃
┃├─┼─┼─┼─┤┃ ┃├─┼─┼─┼─┤┃
┃│ │ │ │ │┃ ┃│●│●│●│ │┃
┃└─┼─┼─┼─┘┃ ┃└─┼─┼─┼─┘┃
┗━┓│ │ │┏━┛ ┗━┓│ │ │┏━┛
┃└─┴─┘┃ ┃└─┴─┘┃
┗━━━┛ ┗━━━┛
Next：○
420:デフォルトの名無しさん
09/07/13 08:37:57
┏━━━┓ ┏━━━┓
┃┌─┬─┐┃ ┃┌─┬─┐┃
┏━┛│ │ │┗━┓ ┏━┛│ │ │┗━┓
┃┌─┼─┼─┼─┐┃ ┃┌─┼─┼─┼─┐┃
┃│ │ │ │ │┃ ┃│○│ │ │ │┃
┃├─┼─┼─┼─┤┃ ┃├─┼─┼─┼─┤┃
┃│ │ │ │ │┗━┛│○│○│ │ │┃
┃└─┼─┼─┼─┼─┬─┼─┼─┼─┼─┘┃
┗━┓│○│○│○│○│○│●│ │○│┏━┛
┃└─┴─┼─┼─┼─┼─┼─┴─┘┃
┗━━┓│●│●｜●│○│┏━━┛
┃├─┼─┼─┼─┤┃
┏━━┛│ │●│●│○│┗━━┓
┃┌─┬─┼─┼─┼─┼─┼─┬─┐┃
┏━┛│ │ │ │ │●│○│○│○│┗━┓
┃┌─┼─┼─┼─┼─┴─┼─┼─┼─┼─┐┃
┃│ │ │ │ │┏━┓│●│ │ │ │┃
┃├─┼─┼─┼─┤┃ ┃├─┼─┼─┼─┤┃
┃│ │ │ │ │┃ ┃│●│●│●│ │┃
┃└─┼─┼─┼─┘┃ ┃└─┼─┼─┼─┘┃
┗━┓│ │ │┏━┛ ┗━┓│ │ │┏━┛
┃└─┴─┘┃ ┃└─┴─┘┃
┗━━━┛ ┗━━━┛
Next：●
421:デフォルトの名無しさん
09/07/13 14:13:26
シェーダーって何なんですか？
つまり受け取ったデータをどういう風に加工して画面に出力するかっていう
関数の一種なんですか？
422:デフォルトの名無しさん
09/07/13 14:26:09
＞421
このページ読むとわかりやすいよ
URLﾘﾝｸ(marupeke296.com)
423:デフォルトの名無しさん
09/07/13 15:23:08
ありがとうございます
あとシェーダーを書いたとしてGPUによって
表示が違うとかという問題は起こるのでしょうか？
424:デフォルトの名無しさん
09/07/13 15:29:50
もちろん起こる
それにシェーダーをコンパイルしたビデオチップが違うと
同じPCでも表示結果が変わったりする
425:デフォルトの名無しさん
09/07/13 15:34:57
>>424
それはない。
いちいち突っ込まれることを
書くから荒れる。
426:デフォルトの名無しさん
09/07/13 15:36:01
ちゃんと作れば同じになるな
427:デフォルトの名無しさん
09/07/13 15:38:27
そうですか
ありがとうございました
シェーダーに挑戦してみます
428:デフォルトの名無しさん
09/07/13 15:49:38
>>425
いや、おれも変わらないと思うんだけど
なぜか変わるんだよね
解るなら説明してくれない？
PC-AとPC-Bで開発してます
まず同じプログラムからPC-AとPC-Bで作った実行結果を比べると
テクスチャの浮動少数の精度のせいなのか微妙に結果に誤差がでます
ただし
PC-Aで作成した実行ファイルをPC-Bで動かした場合
実行結果はPC-Aで確認できるものと一緒
PC-Bでコンパイルしなおすと出来上がる実行結果ははPC-Bのものになる
逆の場合同じ
なんで？
429:デフォルトの名無しさん
09/07/13 15:53:32
同じ奴じゃあるまいな
430:デフォルトの名無しさん
09/07/13 15:54:21
Direct3Dはビデオカードによって出力結果が変わるのは常識なのに、
同一だと思っている人間がいることに驚きだ。
431:デフォルトの名無しさん
09/07/13 15:55:09
Utilities\bin\x86\psa.exe
Utilities\bin\x86\fxc.exe
のバージョン違いかな？
432:デフォルトの名無しさん
09/07/13 15:55:31
シェーダーってどうデータを渡して加工するかだけだから
コンパイルは関係なくね？
まあ精度の点は知らんしGPUそんなにいろいろないからわからないけど
433:デフォルトの名無しさん
09/07/13 15:59:36
ラデで問題ないものがゲフォで変だったことはあるな
結局>>426だったのだけど、本当に見つかりづらかった
434:デフォルトの名無しさん
09/07/13 16:01:20
変わるのはシェーダのバイナリではなく、
レンダリング時のピクセルの状態
435:デフォルトの名無しさん
09/07/13 16:04:57
>>430
だから
PC-Aで作った実行ファイルを
PC-Bで動作させた場合に動作がPC-Bに準拠してくれるなら納得なんだけど
なぜか動作はPC-Aで動かした場合と同じになる
これをPC-Bでコンパイルしなおすと
出来上がる実行ファイルはPC-Aのもと違った動作をする
この実行ファイルをPC-Aに持っていくと
動作はPC-Aに準拠したものではなくPC-Bで動作していたときと一緒になる
シェーダーはコンパイル済みじゃなくて.fxファイルに書いてある
いまいち納得できないんだけど
436:デフォルトの名無しさん
09/07/13 16:13:31
PC-AとPC-BにインストールしてるSDKのバージョンは？
特にpsa.exeのバージョン
437:デフォルトの名無しさん
09/07/13 16:14:40
シェーダー関係ないのでは？
同じライブラリをリンクしてる？
438:デフォルトの名無しさん
09/07/13 16:16:39
>>435
fxファイルをコンパイルして出来たエフェクトオブジェクトを
D3DXDisassembleEffectで逆アセンブルして、diffを取ってくれ。
双方に違いがないようなら、話を進めよう。
439:デフォルトの名無しさん
09/07/13 22:08:10
D3DXのランタイムのDLLが異なるだけだろ。
それをビデオカードのせいだと考える思考回路が、あまりにも馬鹿馬鹿しい。
440:デフォルトの名無しさん
09/07/13 22:17:49
お前らさ、なんで先日の質問者の（悪い部分だけを）真似した嘘質問にまともにレスしてるの？
からかわれてるだけだろ
441:デフォルトの名無しさん
09/07/13 22:24:18
元々こんな質問ばっかりだぞ？
前はまだ自浄能力があったけど
442:デフォルトの名無しさん
09/07/13 22:29:40
自浄能力・・・？
443:デフォルトの名無しさん
09/07/14 10:35:50
^2
444:デフォルトの名無しさん
09/07/15 22:56:27
SDK2008Nov入れてるんですけど、DirectPlayってなくなったんですか？
ヘッダがみつからないんですが.....
ネットワーク関係の機能ってどこにあるんですか？
445:デフォルトの名無しさん
09/07/16 00:12:12
WinSock
446:デフォルトの名無しさん
09/07/16 00:39:52
８のＳＤＫからヘッダだけひっこぬけばよくね？
DirectPlayは8で終了だっけ？
サポートとか心配ならおとなしくＷｉｎＳｏｃｋとか使えって話なんだろうが
セッションとか考えるのだるいし音声セッションとかかなりめんどいし
ＵＰＮＰポートマッピングとか自作するのは資料少なくてかなり泣けるのでまじおすすめしない
ただし、ＷｉｎＳｏｃｋでDirectPlay並のものが実装できるようになるとかなりスキルあがるよ
時間が余ってるならチャレンジしてもいいかもしらん
ただ、あくまでゲームつくるのが目的ってなら時間もったいなす
DirectInput８だっていまだに使われまくってるから
DirectPlay使ったっていいじゃない
と思わなくもないが、否定派が多い木がします
447:デフォルトの名無しさん
09/07/16 01:00:06
DirectPlayはいまいち中途半端な感じがしたが・・・
ロビーサーバーがLinuxとかでもちゃんと通信できたっけ？
448:デフォルトの名無しさん
09/07/16 03:05:43
今だったらboost.asioを使うのがいいのかな
449:デフォルトの名無しさん
09/07/16 07:33:12
DirectShowも消えたしなー
450:デフォルトの名無しさん
09/07/16 07:35:11
消えたんだｗ何になったの？
451:デフォルトの名無しさん
09/07/16 07:37:06
DirectShowは消えたのではなく、Platform SDK入りをした。
452:デフォルトの名無しさん
09/07/16 08:02:42
DirectShowの設計はかなり酷い
ソースをメモリから転送するだけでソースフィルタから書けってどんだけ
453:デフォルトの名無しさん
09/07/16 08:15:42
阿良々木 暦のプログラマブルコントローラーの配線図
阿良々木 暦
「絶望した…。自分の配線図でさえも、きっちりし過ぎて何が何だか分からないことに絶望した…。」
阿良々木 暦の変直切り替えは、キハ110系と同様、自動で最適なタイミングで切り替えていきますので、
かなり複雑な電子制御方式であり、プログラマブルコントローラーで自動的にアイドル指令を出すような設計です。
454:デフォルトの名無しさん
09/07/16 08:16:30
>>449
昇格じゃん
455:デフォルトの名無しさん
09/07/16 15:29:03
市販のゲームって.xファイルとかが置いてなくてアプリケーション内に組み込んであるじゃないですか
あれどうやってやるんですか？
456:デフォルトの名無しさん
09/07/16 15:36:42
いくらでもやりようはあると思うが。
リソースに入れて一連のAPIで読みだしてもいいし。
457:デフォルトの名無しさん
09/07/16 15:49:40
リソースに入れるにしろxファイルは使ってないわな
458:デフォルトの名無しさん
09/07/16 15:59:20
普通は自前のオリジナルフォーマット使うだろう。
Xファイルは悪くは無いがいかんせん古い。
今は物理データやコリジョンデータやシェーダーパラメーター埋められないとなー。
459:デフォルトの名無しさん
09/07/16 16:20:00
時代はVRML
460:デフォルトの名無しさん
09/07/16 16:31:43
Xファイルが有用だとは言わないが、
テンプレートを追加すればいくらでも
カスタムデータを埋め込むことは可能なんだが、
埋められないとか言う前に仕様ぐらい確認して欲しいところだ。
461:デフォルトの名無しさん
09/07/16 16:42:55
>>460
あんなのに埋めこんでどーする
出力と入力を自前で書くハメになるから、それなら結局自前フォーマットで構わん
462:デフォルトの名無しさん
09/07/16 16:57:08
デバイス->SetSamplerState(0, D3DSAMP_MAGFILTER, D3DTEXF_LINEAR);
これやるとテクスチャとテクスチャの隙間が白く見えるようになってしまった。どうして？
463:デフォルトの名無しさん
09/07/16 17:05:53
>>461
よくわからない理屈だな
結局、その主張に
なにか根拠や理由がある訳じゃないんだね
464:デフォルトの名無しさん
09/07/16 17:11:44
というかあの質問は初心者のものだろ？
つまりexeファイルだけ出力させてスッキリさせたいって話であって
Xファイルの仕様云々じゃないと思うけど
465:デフォルトの名無しさん
09/07/16 17:13:48
>>461
有用かどうかはさておき、Xファイルの仕様として追加できると言ってるのに、
埋め込んでどうするとか意味不明なんだけど。
466:デフォルトの名無しさん
09/07/16 17:19:35
質問者は、「とか」って言ってるからxファイルに限らないのだろう
467:デフォルトの名無しさん
09/07/16 17:58:04
だよなぁ ぽまいら脱線しすぎなんだよ
モデルファイルとか音声ファイルをＥＸＥの中に入れてしまいたい系の質問じゃないのか？
468:デフォルトの名無しさん
09/07/16 17:58:23
Xファイルに3Dデータを追加できるって主張は、
テキストファイルに3Dデータを追加できるって主張とほぼ同義だろ
Xファイルを使うことが目的でない限り、何の意味もないわ
469:デフォルトの名無しさん
09/07/16 18:14:41
まあリソース埋め込みでいいのなら、カスタムリソースでググればいいかな。
使うのはFineResource、LoadResource、LockResource
470:デフォルトの名無しさん
09/07/16 18:44:16
＞Xファイルは悪くは無いがいかんせん古い。
＞今は物理データやコリジョンデータやシェーダーパラメーター埋められないとなー。
単にこれがアホな発言だというだけ。
わざわざデータを入れることに意味があるかどうかの是非に、話をすり替える必要はない。
これで無知を晒す前に確認することを学んだのならそれでいい。
471:デフォルトの名無しさん
09/07/16 18:51:38
まあXFileまわりも
せっかくDirect3Dのコーポネントなら、
D3Dのリソースを直でシリアライズするような
機能があってもよかったと思うな。
なんだか知らんが、MSがRMと一緒に
即切りしやがったからな。
472:デフォルトの名無しさん
09/07/16 19:01:50
Xファイルは使わないとして、
初心者は何でボーンの木構造やアニメーション情報をやり取りすれば良いの？
素人の俺は、ToyStudioみたいなのにするのかなと想像してる
473:デフォルトの名無しさん
09/07/16 19:09:50
そもそもモデリングソフトは何を使用しているのかという問題がある。
まともにやろうとすると覚悟が必要な金額になる。
474:デフォルトの名無しさん
09/07/16 21:21:30
とりあえず趣味のレベルだからメタセコイアで
XSIはちょっと重くて無理
475:デフォルトの名無しさん
09/07/16 21:31:43
自分のゲームにどうやってモデリングデータを持って行くか話してる時に
そのソフトを同列に書くってどういう事？
重いとかそう言う事じゃねーだろ
476:デフォルトの名無しさん
09/07/16 21:35:35
うるさいな
477:デフォルトの名無しさん
09/07/16 21:54:27
実際個人で趣味程度につくるぶんにはメタセコ程度が価格的に限界でつ
別にＣＧやりたいわけじゃなくてあくまでゲームつくりたいだけだからなー
メタセコにはモーション作る機能追加してほしいぜ
で、Ｘファイルダメとか言ってるやつは実際どうしてるのかくらい書いてくれないと
参考にもならないおっおっお
478:デフォルトの名無しさん
09/07/16 22:00:48
初心者がツール名をあげて、話を誘導するのかと思ったが
ただの厨だったでござる
同じメタセコユーザーなので、MIKOTOやkeynote等のファイルリーダーを
作るとか、既にあるなら知りたかったな
479:デフォルトの名無しさん
09/07/16 22:05:32
どーでもいいけどファイル仕様で騒ぐなよ
ここ初心者スレよー
初心者には難しくてわからんよー
いや俺なんだけどね
それよりさあID3DXAllocateHierarchyまわり面倒クセー
やっぱりアニメーションは自分で何とかしようかなあ・・・
480:デフォルトの名無しさん
09/07/16 22:19:24
∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ ＜やっぱりアニメーションは自分で何とかしようかなあ・・・
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
なんというループ
481:デフォルトの名無しさん
09/07/16 22:24:22
>>474
メタセコイアもXSIも独自形式で書き出すプラグインとか作るのですか？
482:デフォルトの名無しさん
09/07/16 22:25:14
昔アニメーションを別ファイルに書き込んでそれを読み込んで
手足を配置って方法取ってたけどいろいろめんどくさくてやめた
483:249
09/07/16 22:27:59
>>251
レスめちゃくちゃ遅れてすいません
自分でいろいろ試してみました。
１．StretchRect
pSourceSurfaceにIDirect3DDevice9::GetBackBufferで取得したサーフェイスを指定
pDestSurfaceにCreateOffscreenPlainSurfaceで作ったサーフェイスを指定
領域は二つともNULL、フィルタはD3DTEXF_NONE
→D3DERR_INVALIDCALLが返る
２．pDestSurfaceをCreateRenderTargetで作ったサーフェイスに変える
転送先のサーフェイスは上記のメソッドで作ってはいけないようだったので。
→CreateRenderTargetを実行時に強制終了
CreateRenderTarget(w, h, D3DFMT_X8R8G8B8, D3DMULTISAMPLE_NONE, 0, true, &lpDestSurface, NULL)
３．StretchRectではなくGetRenderTargetDataを使う
→何とかコピーに成功
でもStretchRectと比べて制限が多いですし、できればStretchRectの方を使いたいです。
なぜCreateRenderTargetで強制終了するんでしょうか？何かおかしな指定してるんでしょうか・・
484:デフォルトの名無しさん
09/07/17 03:04:45
デバッグランタイムにすれば、原因わかるんじゃないの
失敗するときは、大抵ログ吐いてくれる
485:デフォルトの名無しさん
09/07/17 03:43:44
サンプルを落としてコンパイル→当然成功
少し書き加える→エラー
書き加えたところを削除して元に戻す→未解決の外部シンボルが大量に
ふ ざ け ん な
何で元に戻したら悪化するんだよ糞が・・・
486:デフォルトの名無しさん
09/07/17 06:12:34
>>485
原因お前だろｗ
487:デフォルトの名無しさん
09/07/17 06:42:38
やっとできた・・・
追加の依存ファイルに追加してなかったのが原因か・・・
これならだいぶ前にやったはずのに・・・
でもとりあえずコンパイルできるようになってよかった
8時間ぐらいかかったけどｗ
しかし一度エラーが出たら元に戻してもエラーが出るというのは謎だ
488:デフォルトの名無しさん
09/07/17 07:03:23
>>487
どう考えても自分が原因なのにうるさい
489:デフォルトの名無しさん
09/07/17 09:40:02
Xファイルを自前の形式に変換してゲーム中に表示させたいので質問です。
AnimationKeyの番号が0で回転を表しているのですが
floatが四つ並んでいます。
どうやら調べるとクオータニオンを使って変換するらしいのですが
ｘｙｚｗでクオータニオンってDirectXの関数で作れますか？
幾ら調べても見逃しているのか見つかりません。
また他にもframeに番号1(拡縮)と2(移動)があるのですが
これ 拡縮行列ｘ回転行列ｘ移動行列の結果を影響のある頂点にかければいいのでしょうか？
490:デフォルトの名無しさん
09/07/17 09:43:24
d3dxのクオータニオン構造体あるだろ
あれの要素がｘｙｚｗだからそのまま放り込めばおｋ
491:489
09/07/17 09:50:27
盲点でした…。
クオータニオンってもっと複雑な物かと思ったいたら
中身はｘｙｚｗしかなかったのですね…。
ありがとうございます。
492:デフォルトの名無しさん
09/07/17 10:50:30
盲点でもなんでもねえ
493:デフォルトの名無しさん
09/07/17 11:02:59
>>483
StretchRectはさまざまな制限があるけど、MSDNは確認した？
めくら撃ちしたって時間の無駄だよ。
拡大・縮小がダメな場合もあるから領域指定がNULLなのも怪しい。
ちゃんと動くまではちゃんと指定してあげること。
494:デフォルトの名無しさん
09/07/17 15:02:08
DirectX関係ないな
495:デフォルトの名無しさん
09/07/17 15:03:10
あ、ごめん、リロードしてなかった
496:デフォルトの名無しさん
09/07/18 16:33:32
スキンメッシュで手とか足のボーンの位置とか傾きを取得するにはどうしたらいいですか？
497:デフォルトの名無しさん
09/07/18 16:37:24
該当フレームの行列を確認すればいい
498:デフォルトの名無しさん
09/07/19 14:09:51
頂点データを取得したいんですが
D3DXLoadMeshFromXでLPD3DXMESH *ppMeshを取得して
DWORD FVFSIZE;
LPDIRECT3DVERTEXBUFFER9 ppVB;
BYTE *pointVec;
ppMesh->GetVertexBuffer(&ppVB);
FVFSIZE=D3DXGetFVFVertexSize(ppMesh->GetFVF());
ppVB->Lock(0,0,(void**)&pointVec,0);
とやってこのあとどうすれば頂点データを一つずつ取得できますか？
FVFSIZEの分だけpointVecに足してやればいいんでしょうか？
499:デフォルトの名無しさん
09/07/19 19:02:25
フォーマット通りに並んでいるだけなんだから、
順番に取り出していけばいいだけ。
500:デフォルトの名無しさん
09/07/19 20:02:19
DirectX9のSDKで最新はどれですか？
501:デフォルトの名無しさん
09/07/19 23:39:52
ぼくしょうがくせいだけど
それはDirectXデベロッパーセンターにいけばわかることくらいわかるよ
502:デフォルトの名無しさん
09/07/21 01:14:33
Xファイルのデータでボーンアニメーションって出来ますか？
503:デフォルトの名無しさん
09/07/21 01:51:32
うん
504:デフォルトの名無しさん
09/07/21 03:25:35
Xファイルをサービス関数を使わず独自の形式で読み取りたいです。
そこでモーションつきのモデルを読み込みたいのですがうまくいきません。
まずメッシュの頂点データと法線データとUVデータは全て読み込みました。
ちなみにメッシュは1メッシュです。マテリアル等は無視しています。
質問①
「SkinWeights」の項目にそのフレームが影響する頂点とそのウエイトが定義されているのですが
その一番最後に4ｘ4行列があるんですがこれがよくわかりません。
これは親子関係を考慮しつつ各頂点にかければいいのですよね？
質問②
入れ子によって親子関係を定義している部分がありますが
そこにあるFrameTransformMatrixはボーンアニメーションする場合は
一切無視していいのでしょうか？
調べてみるとアニメーションの概念ができる前から存在すると聞きました。
質問③
最後に「AnimationSet」の項目に
ローテーション・スケール・トランスレーションが各フレーム毎にデータがあるんですが
スケール行列ｘローテーション行列ｘトランスレーション行列で1つにまとめたあとに
影響する頂点にかければいいのですよね？
質問④
これらの事をしてもときちんと動かないのですが何か抜けている点はあるでしょうか？
505:デフォルトの名無しさん
09/07/21 08:26:28
質問①
いいえ
ボーンの行列 = ボーンのオフセット行列 * 親子関係によって積算した後のフレーム行列
質問②
はい
アニメーションとそれは相互排他
質問③
はい
質問④
わかりません
506:デフォルトの名無しさん
09/07/21 08:29:55
まずは、スキンメッシュじゃなくて
普通のアニメーションするメッシュが
正しく動作するか確認して
507:デフォルトの名無しさん
09/07/21 09:41:17
質問②
相互排他ではありません。
たとえばアニメーションに位置の情報が無い場合は
そこから位置だけを抽出する必要があります。
当然アニメーションに回転が無い場合も回転だけ
そこから抽出する必要があります。
508:デフォルトの名無しさん
09/07/21 10:33:35
>>507
その発想はなかった。確かにアニメーションデータに位置の情報がなければ（そんなXファイルつくるなｗ）引用する必要がでてくるな。
俺は、②のFrameTransformMatrixは「デフォルトポーズ」だと認識してるぜ
509:デフォルトの名無しさん
09/07/21 11:49:57
回転と移動と伸縮を別に管理してるとどれか情報がないって事はよくあるけどな
D3DXのはマトリックスしか持ってないんだっけ
510:505
09/07/21 14:46:52
>>507
FrameTransformMatrixが相互排他であるかないかは
多分ドキュメント類には記述はなく、未定義だろうから、
DXSDK関連のソースでもみて結論付ける必要があるだろう。
個人的には、>>507は十分わかるんだが
Xfileでアニメーションする際には、必ずFrameTransformMatrixの
分解が必要になる訳で、ちょっとナンセンスかなと思うな。
例えば、フレームの移動が必要ないなら、アニメキーは無しに、
全編を通して固定位置にしたいなら、キーを1つだけ用意する。
これで対応出来るし、こっちの方がスマートだと思う。
511:デフォルトの名無しさん
09/07/21 16:55:23
GDIかなんかで５頂点ポリゴン描画すると
URLﾘﾝｸ(www.traum-projekt.com)
真ん中がくりぬかれて描画されますが、
DirectXのDrawPrimitiveで
同じ5頂点を利用してこのような描画って
できますか？
512:デフォルトの名無しさん
09/07/21 17:37:42
ステンシルバッファ使えば出来なくもない
513:デフォルトの名無しさん
09/07/21 19:08:08
>>511
>真ん中がくりぬかれて描画されますが
は？
514:デフォルトの名無しさん
09/07/21 19:17:03
ROPなんてゲーム作るうえで誰も必要としてないから
515:デフォルトの名無しさん
09/07/21 19:19:08
XORな描画ステータスあったらいけそう
516:デフォルトの名無しさん
09/07/21 19:24:00
わざわざ５頂点でやる意味がわからない
517:デフォルトの名無しさん
09/07/21 20:18:54
出来るかどうか聞いてるのに
文句言ってるやつって何なの？
518:デフォルトの名無しさん
09/07/21 20:29:30
まぁ文句出る気持ちも分かるけど
>>511
DrawPrimitiveでやるなら、まずテセレーション(面倒だけどネットに情報あり)して三角形に分解後、
それぞれの三角形を塗るかどうか判定(三角形内部から適当に線を延ばし、他の辺と交わる回数が奇数なら描画)
していくしかないね。
しっかしXファイルのことなんてレスつかないだろうから、帰ったらレスしようと思ったら、意外に皆詳しいなｗ
519:504
09/07/21 20:58:41
皆さんありがとうございます
505さんの言うボーンの行列 = ボーンのオフセット行列 * 親子関係によって積算した後のフレーム行列
が何をさすかピンときませんががんばって見ます
520:デフォルトの名無しさん
09/07/21 21:06:07
>>517
明らかに馬鹿でウザイから
まず具体的にやりたいことから言えって感じ
詳しく聞くとそんな仕様まったく必要ないのにくだらないもの探してるってオチだと思う
521:483
09/07/21 23:43:40
>>493
レスありがとうございます、ですが領域はNULLでもいいみたいです。
CreateOffscreenPlainSurfaceとGetRenderTargetを使ったコードを
そのままCreateRenderTargetとStretchRectを使ったコードにしたら動きました！
しかしこれが最も速く画像を取得する方法なんでしょうか。
GetRenderTargetData→転送先サーフェイスからGetDC、BitBlt
StretchRect→転送先サーフェイスからGetDC、BitBlt
GetRenderTargetDataは遅いそうですが、StretchRectはそれより速いのか分かりません。
522:デフォルトの名無しさん
09/07/22 08:55:23
>>512 が早々に適格なこと言ってると思うんだが
まあ実際、面倒ならやらないわ―ってレベルだろ
523:デフォルトの名無しさん
09/07/22 12:57:58
D3DXMatrixPerspectiveFovLHのfovyは
URLﾘﾝｸ(msdn.microsoft.com)
このページのfov/2の値をのことでしょうか？
私のプログラムでは，fovyを90度ににすると歪んで見え，
45度にすると普通に見えます．また，SDK付属のサンプル
も45～60度で設定しているようです．
しかし検索すると
URLﾘﾝｸ(www.gamedev.net)
のページのように，fovyはfov/2ではなく，fovを設定すると書かれているページ
に多く出会います．もしfovを設定するのだとすれば，fovyを45度に設定
することは視線から上側の視錐台の角度がたったの22.5度しかないことになって
しまいます．
真相はどうなっているのでしょうか？
524:デフォルトの名無しさん
09/07/22 13:29:37
自分の目からディスプレイの上端までと目から下端までの間の角度を測ってみ
90度もある？ (あるとしたら、どれだけディスプレイに目を近づけてるんだ)
不自然だから歪んで見えるのでは？
525:デフォルトの名無しさん
09/07/22 13:32:37
ちゃんとラジアン角度にしてるか？
D3DXToRadian(90);
526:デフォルトの名無しさん
09/07/22 13:42:41
>>525
もちろんしてます．
SDKのサンプルも90度に設定して動かすとやはり歪んで見えます
527:デフォルトの名無しさん
09/07/22 15:18:44
>>526
>>524
528:デフォルトの名無しさん
09/07/22 21:51:21
質問です。
Xfileを表示してキーボードでそれを動かし、当たりがあったら文字を表示するというプログラムを作ったのですが。
普通に起動させると動作が遅いのですが、メディアプレイヤーを起動している時だけはなぜか動作が速くなります。
なぜこんなことが起こるのか教えてください
529:デフォルトの名無しさん
09/07/22 22:07:34
URLﾘﾝｸ(cpplover.blogspot.com)
これだろ
530:デフォルトの名無しさん
09/07/22 22:09:26
timeBeginPeriod メディアプレイヤー
でぐぐってみれば、理由を考察してるサイトがいくつか見つかる
531:デフォルトの名無しさん
09/07/22 23:00:12
一応解決しました。貴重な情報ありがとうございました
532:デフォルトの名無しさん
09/07/22 23:56:22
3Dモデルを表示するソフトウェアを開発しています。
描画エンジンとしてDirectX9.0のDirect3Dを使おうと考え、
色々調査しているのですが、PCの画面色数が24Bitの場合、正常に動作しません。
Googleで調べた所、いくつかのソフトでは24Bitでは動作不可との記述が見つかりました。
URLﾘﾝｸ(postpet.jp)
URLﾘﾝｸ(mxengine.net-dimension.com)
しかし、MSDNには24Bit動作不可との記述が見当たりません。
質問ですが、
DirectX9.0のDirect3Dウィンドウモードでは、16Bit/32Bit以外の動作は不可でしょうか？
24Bitで動作させる方法(コーディング例)がありましたら、ご教授お願いします。
533:デフォルトの名無しさん
09/07/22 23:58:58
ねーよ。
そもそも24Bitの画面モードが選べるような
ビデオカードが現存してた事に驚いた。
534:デフォルトの名無しさん
09/07/23 00:00:08
24ってマイナーじゃないの？存在を初めて知った
535:デフォルトの名無しさん
09/07/23 00:06:37
>>533
>>534
早速のレスありがとうございます。
実は配布先PCは特殊な環境で16Bit/24Bitのみ選択可、
通常は24Bitで動作しております。
すでに客先で動作しているPCであり、
客先は全国にある為、
インストールの為、画面設定を変更するのは難しいです。
やはり24Bitで動作させるのは難しいのですね。
最悪、DirectXではなく、他の描画ルーチンを使用することも考えています。
536:デフォルトの名無しさん
09/07/23 00:13:26
24はVRAMが少量しかなかった時代に
少ないメモリでフルカラー表現するために存在した。
VRAMが豊富になって32Bitが使えるようになったら滅んだ。
24Bitって3Byte単位のアクセスだから速度がすげー遅かったし。
>>535
DirectX7か8のどっちかならいけるはず。
無論速度は度外視な。
537:デフォルトの名無しさん
09/07/23 00:14:40
どうせならOpenGLってどうかな？（いや、よくしらんけどｗ）
538:デフォルトの名無しさん
09/07/23 00:43:53
その前にビデオカードの具体的な製品名を明らかにしろよ。
なんでいちいち情報を小出しにするんだ？
539:デフォルトの名無しさん
09/07/23 00:46:31
それ大事か？
しかし24なんて使ったことがないから可とも不可ともいいようがない・・・
540:デフォルトの名無しさん
09/07/23 00:48:12
D3D9は確かにディスプレイフォーマット24bitは
サポートしてないみたいだけど、
それってFullScreenだけじゃなく
Windowモードもそうなの？
541:デフォルトの名無しさん
09/07/23 00:49:54
MatroxのG200とかは24Bitモードあったぜ
542:デフォルトの名無しさん
09/07/23 00:51:14
>>540
デバイスの初期化が通らないよ。
543:デフォルトの名無しさん
09/07/23 00:53:58
どうやらVoodoo Bansheeあたりも24bitあったみたい。
しかし、Bansheeは良いカードだったｗ
544:デフォルトの名無しさん
09/07/23 01:05:03
ディスプレイモードの列挙が通らなくて強制終了だな
完全にサポートしてないと動かない
545:デフォルトの名無しさん
09/07/23 10:02:17
GF2MX400とかも普通に24bitモードあったぞ。
てか、24bitがマイナーだと初めて知ったｗ
当時、32bitこそ「無駄遣いだなぁ。24bitでフルカラー表現できるのに、なんだこの糞異端ボード」とか思ってた。
546:デフォルトの名無しさん
09/07/23 11:25:14
Direct3Dを使わないのが前提なら24bit対応のビデオカードは多い
547:デフォルトの名無しさん
09/07/23 11:30:19
でもわざわざ24bitを使う理由ってなに？
548:デフォルトの名無しさん
09/07/23 11:35:13
質問者は、個人制作で自宅の24bit環境が普通だと思った
メーカーがどうして用意したかは、上に散々かいてある
昔のPCI
549:デフォルトの名無しさん
09/07/23 12:51:38
815あたりの内蔵グラフィック機能だと、32bppが無いんじゃなかったっけ？
16/24しか選択できなくて、3D機能が使えるのは16だけみたいな感じ。
550:デフォルトの名無しさん
09/07/23 14:53:47
スパロボのようなゲームを作っているのですが、
マウスで入力するために入力関係に特化したようなサイトとかありますか?
551:デフォルトの名無しさん
09/07/23 17:39:07
>>550
言いたいことはわからんでもないけどとりあえず日本語で(ry
552:デフォルトの名無しさん
09/07/23 17:42:04
たぶん碁盤の目のようなフィールド上でクリックしたら
コマンドが出るようにとかしたいんだろうけど
DirectXの要素はマウスの座標取得ぐらいしかねえじゃん
553:デフォルトの名無しさん
09/07/23 20:33:35
>>551
すいません、要するにスパロボのフィールド画面を作りたいんです
>>552
そうです、まさにそんな感じです
セルの上にマウスを置いたらセルを囲み、右クリック等でコマンドが出る・・等の構成にしたいのです
ゲームのサイト色々見てるのですが、なかなか目的のものが見つからないのですよ
とりあえずマウスの座標取得から始めてみますね
554:デフォルトの名無しさん
09/07/24 01:45:36
作ったゲームのテストたのんだ友人の中の一人だけがエラーで止まるので
いったい何が悪いんだと調べてみたらフォント描画が原因だった
\r\nを含んだ文字列描画すると原因不明のエラー警告で落ちる
\r\nを\nにしたらエラーでなくなったが、一体なにが悪いのかよくわかりませんでつた
ＯＳもＤｉｒｅｃｔＸランタイムバージョンも他の正常に動作してるＰＣと同じでつ
555:デフォルトの名無しさん
09/07/24 03:42:55
>>554
DirectXとOSのバージョンと描画方法は何ですか？
556:デフォルトの名無しさん
09/07/24 07:06:17
プログラム中の文字列の改行コードにCRLFって使った事無いなｗ
テキストに落とす時は別だけど
557:デフォルトの名無しさん
09/07/24 08:30:56
>>554
落ちた１台が例外なんじゃなくて、
他のPCではたまたま動いたってだけの話だろうたぶん
558:デフォルトの名無しさん
09/07/24 13:50:58
555は偉いなぁ…真似できん
559:デフォルトの名無しさん
09/07/24 17:36:51
質問です
DIRECTXで作られた質の高いフリーゲームってありますか？
560:デフォルトの名無しさん
09/07/24 17:47:19
ここはプログラムを作ることに関しての板ですゲームサロンにでもいってください
561:デフォルトの名無しさん
09/07/24 17:55:50
プログラマブルシェーダでのSetTextureについて質問です。
D3DXEffect effects[100];
for(int i = 0; i < 100; ++i)
{
effects[i].SetTexture("DecaleTex", textures[i]);
}
と、それぞれのエフェクトにそれぞれ別のテクスチャーをセットするとします。
これで、すべてのエフェクトが予想通りに動いているのは確認済みです。
このときに疑問が湧いたのですが、d3ddevice->SetTexture相当のことはいつ行われているのでしょうか？
1)effect[0]を使って描画
2)effect[0]を使って描画
3)effect[1]を使って描画
4)effect[1]を使って描画
とやった場合、2→3のところで内部的に行われているのでしょうか？
となると
1)effect[0]を使って描画
2)effect[1]を使って描画
3)effect[0]を使って描画
4)effect[1]を使って描画
とやると、d3ddevice->SetTextureのコストという面では2倍コストがかかってしまっているのでしょうか？
そもそも全てのエフェクトにテクスチャをあらかじめセットしてまわっておく。というのは正しいやり方なのでしょうか？
「d3ddevice->SetTextureはなるべく減らすように」と昔教えられたもので
（実際に、パーティクルなどの表示で切り替えまくると遅かったし）
かなり気になっています。
アドバイスいただければと思います。よろしくお願いします。
562:デフォルトの名無しさん
09/07/24 21:22:42
DX9ならBeginPassとCommitChanges
DX10ならApply
それ以外に公開情報あったっけ
563:デフォルトの名無しさん
09/07/24 21:23:32
質問です。
d3d9.hの読み込みより前に
#define D3D_DEBUG_INFO
を設定することで、デバッグウインドウ上で情報が表示されるということで実践してみたのですが、
どう考えてもおかしな数値が入っているように表示されます。
これは皆さんの環境でそうなのでしょうか？
単なるD3Dの初期化＞D3Dデバイスの中身をデバッグウインドウで見る＞数値とかがぐちゃぐちゃ
なのですが…。
環境はVS2008Express
Microsoft DirectX SDK (March 2008)
を使っています。
564:デフォルトの名無しさん
09/07/24 21:36:20
君のプログラムの文字セットの設定は何だろう？
ちなみにIDirect3DTexture9::NameはLPCWSTRだ。
565:デフォルトの名無しさん
09/07/24 21:40:51
マウスをクリックしたとき、どのオブジェクトをクリックしたかというのはどういうコードを書けばよいんでしょうか
それとも、マウスをクリックした時にその地点にオブジェクトがあるかないかを総当りで調べるものなのでしょうか?
566:デフォルトの名無しさん
09/07/24 21:55:37
スクリーン座標をsx,syとする。
スクリーン座標の手前(sx,sy,0) 奥(sx,sy,1) を3D空間の座標に変換する
（＝3D空間の座標をスクリーン座標にする変換の逆）
2点を結ぶ直線と最初に交差したオブジェクトを選択。
総当りで問題なくOKなら総当り。
総当りでは重いならばケースバイケースで効率的な方法を考える。
567:デフォルトの名無しさん
09/07/24 21:57:32
>>566
うおおおおありがとうございます
568:デフォルトの名無しさん
09/07/24 22:12:08
>>566
直線だけだと漏れが出ないか？
四角錐じゃないと。
569:デフォルトの名無しさん
09/07/25 00:05:32
>>563について自己解決です
注
オブジェクトのプロパティ名が表示されますが、この値はデバッグのランタイムが有効な場合のみ正確です。リテール ランタイムに対して実行するときは、値は無効です。
とありました。
DirectX Control PanelからUseDebugVersionOfDirect3D9 を選んだところきちんと値が見られるようになりました
570:デフォルトの名無しさん
09/07/25 13:52:15
D3DXIntersectを使って当たり判定をしてる人がいましたらご教授願います。
表示した３ｄモデルに対して現在一体にしか当たり判定が有効になっていません。
複数のモデルに対して当たり判定を有効にするには何か特別な仕掛けをしていますか？
571:デフォルトの名無しさん
09/07/25 18:12:35
自分で組め
572:デフォルトの名無しさん
09/07/25 20:11:23
まともなゲームならほとんどすべて、
詳細な当たり判定より先におおざっぱで高速な判定をして
比較するオブジェクトの数を減らす。
最終的には、D3DXIntersectだろうが自作だろうが
当たり判定の必要な回数だけ繰り返す。
573:デフォルトの名無しさん
09/07/25 21:14:18
レスありがとうございます！
574:デフォルトの名無しさん
09/07/27 00:22:28
このスレの70％はゲー専生で構成されているとかいないとか
575:デフォルトの名無しさん
09/07/27 01:14:25
そんなことはない。
大学にも行かず浪人にもなれず就職もしない人は実社会では多数派でもないし
ゲーム業界内でも少ないだろう。２流３流大卒がほとんど。
576:デフォルトの名無しさん
09/07/27 01:51:48
数学とかそこらは、中学レベルだと感じるな。
577:デフォルトの名無しさん
09/07/27 09:42:08
というかそんな高度な知識がなくても組めるし
まあ効率とかを考えるといろいろむずかしくなるけれども
578:デフォルトの名無しさん
09/07/28 07:57:06
今、線分とメッシュとの当たり判定を作っています。
中身は線分と三角形との当たり判定を行っているのですが、
そのために必要な三角ポリゴンデータを、
DirectXのメッシュデータから取得する方法がわかりません。
頂点バッファのロックメソッドから、頂点データへの先頭アドレスを取得し
そのアドレスから12byteずつずらしながら、無理やり三角ポリゴン（と仮定したデータ）を取得し
当たり判定させてみましたが、途中から頂点のデータが「3.587e-043#DEN」などと壊れるようです。
ご存じの方がいらっしゃれば、ご教授よろしくお願いします。
579:デフォルトの名無しさん
09/07/28 08:08:47
>>578
空間上の特定の点がポリゴンの内包する閉空間状に存在するか(要するに当たり判定）は
計算幾何学の分野で、一応n log nのオーダーで出ることは知られているけど
計算が死ねるのでよしたほうがいい。
大学の研究レベルでやるならともかく、ゲームでやるなら質点同士の運動と考えれば十分なはず。
580:デフォルトの名無しさん
09/07/28 08:22:50
URLﾘﾝｸ(sukima.vip2ch.com)
江戸時代の人々はこれで抜けるんなら
ある意味聖人だな
581:デフォルトの名無しさん
09/07/28 08:28:13
>>579
レスありがとうございます。
線分と三角形の当たり判定は、テストデータで計算出来ていることは確認しています。
ですので、知りたいのはポリゴンデータの取得なのです。
わざわざレスくださったのに申し訳ないです。
582:デフォルトの名無しさん
09/07/28 08:31:38
>>579
すいません、読み違えてました。
Xファイルで入力してるので、問題ないと思っているのですが
無理でしょうか？
583:デフォルトの名無しさん
09/07/28 12:25:04
>>578
12byteの根拠は？
頂点データにはxyz以外も含まれていると思うので、12byteではないと思うが。
ID3DXBaseMesh::GetFVFでメッシュのFVFを取得してD3DXGetFVFVertexSizeで
頂点データのサイズを取得するか、ID3DXBaseMesh::CloneMeshFVFを使って
都合のいい頂点フォーマットに変換してから扱うのがいいかと。
584:デフォルトの名無しさん
09/07/28 12:59:33
最近DirectXを勉強しはじめました。
初心者丸出しですが、質問させてください。
DirectXで2Dを扱う場合、Spriteを使用する方法と
座標変換済み頂点を使用する方法があると知りました。
また、座標変換済み頂点を使う方が処理が早いという書き込みも
チラっとみたのですが詳しく書かれておらず、把握している程度です。
質問は
①Spriteか座標変換済み頂点のどちらを使用すれば処理が早いか。
②Spriteと座標変換済み頂点の両方の利点・欠点。
よろしくお願いします。
585:デフォルトの名無しさん
09/07/28 13:21:14
スプライトというのは、本来のDirectXの姿を隠して
ユーザが扱いやすいようにラップしているだけで、
最終的に頂点を組み立てて描画するのは同じ
ラップしているオーバーヘッドのぶん、処理が遅いかもね
586:デフォルトの名無しさん
09/07/28 13:22:42
>>584
D3DXSprite自身が、内部的に座標変換済頂点(rhw)を使ってるんだが、どうよ？
単体の画像を何枚か扱う程度ならこのままでもいいが、小さなチップを大量に描画するようなら
通常の頂点バッファ(Position)を使うことを考えた方がいい。
587:デフォルトの名無しさん
09/07/28 13:22:55
DirectXにSpriteなど無い
588:デフォルトの名無しさん
09/07/28 13:24:51
D3DXSPRITEなら定数として存在するが、D3DXSpriteなど無い
589:デフォルトの名無しさん
09/07/28 13:39:16
>>583
D3DXGetFVFVertexSize( mesh.pmesh->GetFVF() );
として取得したところ、返された数値は12でした。
ですので12byteと判断しているのですが……。
もし不都合があれば教えてください。
よろしくお願いします。
590:584
09/07/28 13:50:35
URLﾘﾝｸ(marupeke296.com)
URLﾘﾝｸ(marupeke296.com)
座標変換済み頂点は、ここの内容を見てます。
>>585
つまり結局は同じ処理をしているという事ですか…
>>586
>通常の頂点バッファ(Position)を使うことを考えた方がいい
通常の…ですか。勉強不足で通常というのがよく分らないのですが
上記のURLにあるコードのような使い方をする場合
「小さなチップを大量に描画」というのは不向きなのでしょうか？
591:デフォルトの名無しさん
09/07/28 14:04:27
流体力学研究所とかいうとこを参照してみては？
592:デフォルトの名無しさん
09/07/28 15:10:47
>>589
途中から？それって頂点データを超えて取得してるんじゃないの？
GetNumFacesとかGetNumVertices使ってる？
593:デフォルトの名無しさん
09/07/28 17:51:19
|￣￣￣￣￣￣￣￣￣￣|
| |
| |
/ ￣￣￣￣ /＿＿＿__
/ また旅に出ます /ヽ＿＿／/
/ / / /
/ 探さないで下さい / / /
/ ＿＿＿＿ / / /
／ ／ / /
／ 光 圀 ／ / /
￣￣￣￣￣￣￣￣￣￣/ / /
のパターンじゃないんだな
594:デフォルトの名無しさん
09/07/28 21:15:24
>>592
使用している部分について、ソースをアップしました。
URLﾘﾝｸ(www1.axfc.net)
もしよろしければ、ソースをダウンロードしていただいて
見てもらってよろしいでしょうか？
GetNumFaces、GetNumVerticesは、一応数値は取得していますが
実際のところどのようにしてポリゴンとして頂点が格納されているのかが
まだ分かっていません。
595:デフォルトの名無しさん
09/07/29 02:52:06
pvertex + fvfsize
らめぇぇぇぇぇ
596:デフォルトの名無しさん
09/07/29 02:55:49
あれ？そこだめなの？
俺は
v1=*(D3DXVECTOR3*)(pointVert+FVFSIZE*(indexp[0]));
v2=*(D3DXVECTOR3*)(pointVert+FVFSIZE*(indexp[1]));
v3=*(D3DXVECTOR3*)(pointVert+FVFSIZE*(indexp[2]));
ってやってるけど問題ないぞ
597:594
09/07/29 03:29:12
>>595
試しに
pvertex[*(pindex+i)];と配列でアクセスしたら幸せになりました。
理由はわかりません。
今回わかったことは、頂点バッファ内に「三角形ポリゴン数×３」個の頂点が格納されているわけではないので
インデックスバッファも使ってアクセスしないときちんと読み取れないということでした。
凸凹の大きいモデルを使った場合、ポリゴンの読み間違いが起こると、Hitが抜けなかったり、
本来あるはずない場所でHitが出たりなどという現象が起こるのは当然でしょう。
しかし、今回の問題は読み込んだ数値自体がおかしくなっていたことでした。
明らかにストライドの量がおかしかったんだと思いますが、何が理由かよくわかりません。
>>596
私の環境でも結果は駄目でした。
突き抜けた穴のあいたポリゴンを使用してテストしていますが、
途中でHitが出てしまいます。
本当に助かりました。
協力してくださった方、ありがとうございました。
598:デフォルトの名無しさん
09/07/29 03:30:46
(pvertex + 0) の次の頂点は (pvertex + 1)なんだぜ
599:デフォルトの名無しさん
09/07/29 03:38:42
poly.v[0] = *(Point3D*)((BYTE*)pvertex + fvfsize*(*(pindex+i-2)));
poly.v[1] = *(Point3D*)((BYTE*)pvertex + fvfsize*(*(pindex+i-1)));
poly.v[2] = *(Point3D*)((BYTE*)pvertex + fvfsize*(*(pindex+i-0)));
こうするか、
もしくは最初からpvertexをBYTE*で宣言すればOK
600:594
09/07/29 03:50:17
>>599
動作確認出来ました。
pvertexがD3DXVECTOR3*型だったから駄目だったんですね。
ポインタのアドレスって、どんな型であろうと変わらないかと思っていました。
ポインタのアドレスを弄るときはchar*なわけですね。
すごく助かりました。
今度C言語の参考書よみなおします。
601:デフォルトの名無しさん
09/08/01 02:17:57
初心的質問ですみません。
DirectXを使っているプログラム内でwavを再生させるにはどうすればよいのでしょうか？
ほとんどのところでdmusici.hを使えとなっているのですが、ヘッダーをインクルードしても見あたらないというので調べたところ廃止(?)になったとかで書かれていて
いくつか調べたのですが、ほとんどのところがdmusici.hを使ってでのやり方なので、解らずじまいです。
現在の再生方法をおしえていただけないでしょうか？
602:デフォルトの名無しさん
09/08/01 02:21:17
おとなしくＤｉｒｅｃｔＳｏｕｎｄを使ったほうがいい
603:デフォルトの名無しさん
09/08/01 02:57:27
普通にXAudio2使えよ
604:デフォルトの名無しさん
09/08/01 10:26:20
XBox360の市場が壊滅状態でもXAudio2はヤバくないんですか？
605:デフォルトの名無しさん
09/08/01 11:15:28
実際のところ、X～～ ってどうなんでしょう。
XAudio2って言うほどまともとは思えないんですが。
606:デフォルトの名無しさん
09/08/01 12:12:44
失礼します。
directx_mar2009_redist.exeをCドライブにインスコしようとするのですが、
必ず半分ぐらい進んだところでゲージが巻き戻り、結局右端までたどり着かず
途中で終了してしまうのです。一体どういうことなのでしょうか
607:デフォルトの名無しさん
09/08/01 13:14:58
炎や爆発、煙などのエフェクトをビルボードを大量に出して
描画しようと思っているのですが、どうすれば高速に描画できますか。
608:デフォルトの名無しさん
09/08/01 15:09:40
現状のエフェクトでどんな処理をやっているのかが分からないので、
より高速な方法について答えようにも答えることができません。
609:デフォルトの名無しさん
09/08/01 15:38:19
大量に出すのをやめる
610:デフォルトの名無しさん
09/08/01 15:43:31
より高速かどうかは置いといて、
最も早いと思われる描画方法を教えてください。
611:デフォルトの名無しさん
09/08/01 15:44:56
マジレスすると
視錐台クリップが最重要だな
次にその中に入ってしまったものをまとめて描画だな
あらかじめDrawPrimitiveにぶち込んでしまうとクリッピングされないから
ある程度の塊でおおざっぱな判定でもするといいよ
なんにせよクリップ方法が最重要
これでしっかり省けば余計な最適化いらない場合のが多いよ
612:デフォルトの名無しさん
09/08/01 15:46:35
>>610
それはいつでもどこもでネタでもなんでもなく「描画しない」ってのが最速
613:デフォルトの名無しさん
09/08/01 16:00:32
>>611
まとめて描画とは、Zsortをして
板ポリ(2ポリ4頂点)×出す量 を毎フレーム描画
ということですか？
>>612
描画しなかったら私のも速くなります。
しかしビルボードをたくさん描画すると重くなるのです。
614:デフォルトの名無しさん
09/08/01 16:31:13
やめろよ
また不毛な議論が始まるぞ
せめてどうやってるのかも書かない奴に
答えてどうする
615:デフォルトの名無しさん
09/08/01 16:53:11
>>614
カメラ空間でのZ値でZsortして、板ポリ一個一個毎フレーム
逆行列作る
worldViewProjectionMatrix作る
effect->SetMatrix
でセットし
effect->setTechnique
effect->Begin
effect->BeginPass
effect->setTexture
effect->CommitChanges
ここでdeclarationをセットし
DrawIndexedPrimitive((D3DPT_TRIANGLELIST....);
effect->EndPass
effect->end
と普通にやっています。
616:デフォルトの名無しさん
09/08/01 16:57:07
>>613
その前にクリッピングそれができないなら気にしなくていい
617:デフォルトの名無しさん
09/08/01 17:11:27
>>616
そうですか、今回作るゲームが引いた視点なので
結構、というかほとんど視錐台に入るんですよね…
618:デフォルトの名無しさん
09/08/01 17:23:29
特殊な条件、爆発の煙や湿原の霧でパーティクルが数百個くらい普通に出てるような状況。
ポリゴンを自前で座標変換後したあとにバッファにためておいて、バケツソートで数個のブロックに分けて描画とか。
619:デフォルトの名無しさん
09/08/01 17:42:07
>>618
>ポリゴンを自前で座標変換後したあとにバッファにためておいて、
>バケツソートで数個のブロックに分けて描画とか。
ちょっと良く分からなかったのですが、
座標変換は存在するすべてのビルボードパーティクルに対して行い(頂点座標を書き換えるのでなくてワールド座標)
それらビルボード一枚一枚をzソートするクラスに溜めています。
そしてｚソートし、一気に一枚一枚描画しています。
ブロックごとに分けて描画するとなると
ブロック内のz値の順番はうまくいきますが
ブロックごとのz値の順番がおかしくなりませんか？
620:デフォルトの名無しさん
09/08/01 18:01:08
ソートした後で分割
621:デフォルトの名無しさん
09/08/01 18:29:54
>>620
分割する意味がわかりません
622:デフォルトの名無しさん
09/08/01 18:40:22
もしかしてポリゴン1枚づつDrawPrimitveしてるの
623:デフォルトの名無しさん
09/08/01 18:51:59
そうです。
624:デフォルトの名無しさん
09/08/01 18:58:04
そりゃないわ。
炎を100個のビルボで表現しているとするなら、その100個は1回のDrawPrimitiveで描画してしまいなさい。
ところで、加算合成なら前後関係をソートする必要がないのは知ってるか？
半透明にしても、ソートがてきとーでも、そうそうばれないからあまり気にするな。
炎単位でソートするくらいで十分。ビルボ1つ単位でソートしてたらすさまじいことになっちまうぜ。
625:デフォルトの名無しさん
09/08/01 19:17:12
>>624
>炎を100個のビルボで表現しているとするなら、その100個は1回のDrawPrimitiveで描画してしまいなさい。
いったいどうやるんですか？
頂点バッファに全ビルボードの移動後の頂点を入れておくとかですか？
そうだとすると、フレームによってビルボードの数が変わるので
毎フレーム頂点バッファを作りなおさなくてはいけなくなりませんか？
全加算なら単純に足すだけですから、炎とかならいいと思いますが
ミサイルなどの手前から奥に飛んでいく煙を表現する場合の線形合成は(今回使います)
ソートは必須です。
しかもいくつもミサイルが飛んでいる場合それらの煙単位でソートしては
煙１と煙２が重なった場合板ポリの輪郭が見えてしまいます。
なので煙全部でソートしないとうまくいかないんです。
626:デフォルトの名無しさん
09/08/01 19:22:06
ここで以前DrawPrimitiveUPや動的頂点バッファの話をしてたが、
まさに枚フレーム書き換えるような頂点のためだよ
627:デフォルトの名無しさん
09/08/01 19:25:30
>>625
>頂点バッファに全ビルボードの移動後の頂点を入れておくとかですか？
それでOK。
頂点バッファを毎フレーム「作り直す」のはつらいので、500ビルボード分作る。
MSのヘルプによると、一回のDrawPrimitiveでは1000ポリくらいが適切だということなので、ビルボは三角形二つだから500ビルボード分ね。
ミサイルの煙を半透明でやるのね。OK。
「気にすんな」でOK
とりあえず試してみ。前後関係が狂っててもまったく気にならないから。
「気にならない」正確さより、「気になる」処理落ちを防ぐのを優先。
>煙１と煙２が重なった場合板ポリの輪郭が見えてしまいます。
半透明の物体を描くときは、Zバッファへの書き込みをOFFにするべき。
そうすればこの現象は起きないよ
628:デフォルトの名無しさん
09/08/01 19:28:30
>頂点バッファを毎フレーム「作り直す」のはつらいので、500ビルボード分作る。
500ビルボード分の大きさで作る。のほうがわかりやすかったね。補足。
描画するたびに中身を書き換えて使うべし。
ロックする際D3DLOCK_DISCARDを指定すれば、ロック待ちも発生しないので早いぞ。
629:デフォルトの名無しさん
09/08/01 19:33:42
>>626
毎フレーム書き換えるのは頂点バッファをLock,UnLockして書き換えるより
頂点シェーダでやったほうが高速だと思ってたので、すべて頂点シェーダでやっています。
それはスキンメッシュのスキニングをシェーダでやったほうが
何倍も高速だったのでそう思っています。
DrawIndexedPrimitiveを何回も呼ぶより
バッファ作ってLockして書き換えたほうが速いということですか？
上のほうで言ってたことは
結局はDrawIndexedPrimitiveもUPも大して速度は変わらないという結論ですよね。
630:デフォルトの名無しさん
09/08/01 19:43:28
>DrawIndexedPrimitiveを何回も呼ぶより
>バッファ作ってLockして書き換えたほうが速いということですか？
書き換えたほうが速い。
というのも、DrawIndexedPrimitiveの呼び出しオーバーヘッドは遅いので。
頂点シェーダでやると高速化するのは確かにそうだが、やるなら281法をやることになる。
確かにID3DXEffect::SetVectorArray()で座標情報を渡すのが大抵のグラボで最速。
ただ、定数レジスタの数の制限を考えるに1回につき250ビルボ程度しか描画できない。
あとは場合によりベターな方法は変わる。
まとめて描画する単位が250ビルボ以下ならこちらでいいと思われ。
631:デフォルトの名無しさん
09/08/01 19:50:21
固定的な頂点バッファとは別に、毎フレーム書き換わるデータ向けの動的頂点バッファがあるの。
その違いを分かってないから、スキンメッシュとの比較検証も、効率悪いやり方でやった場合の結果にすぎない。
632:デフォルトの名無しさん
09/08/01 19:59:06
>>630
複数の頂点情報ストリームを登録しておいて、片側を毎回書き換えるという方法が考えられるな。
（で、VertexShaderで合算する）
計算がいくらか楽になるかもしれない。どれくらい速度が変わるかは試してみないと分からないけど。
633:デフォルトの名無しさん
09/08/01 20:02:57
とりあえず、281法含めて色々実測した身としては、
UPだろうがUPじゃなかろうが、頂点シェーダを使う方法だろうが
「沢山のビルボードを、まとめて一回のDrawIndexedPrimitive*で描画する」という基本を守っている限り、
速度誤差は0.1%にも満たないということだ。
小難しいことを考えるが面倒なら、DrawIndexedPrimitiveUP使っておくといいよ。
（レガシー関数だから嫌というこだわりがなければ。ね）
本気で速度の差はほっっっっっとんどでないから。
まぁ、流石マイクロソフト。DrawIndexedPrimitiveUPの中身もちゃんと最適化されてるんだなといったところ。
634:デフォルトの名無しさん
09/08/01 20:11:38
>>627
>一回のDrawPrimitiveでは1000ポリくらいが適切
それは知りませんでした。
>半透明の物体を描くときは、Zバッファへの書き込みをOFFにするべき。
>そうすればこの現象は起きないよ
そうですよね、なるほど！
>>630
>書き換えたほうが速い。
>というのも、DrawIndexedPrimitiveの呼び出しオーバーヘッドは遅いので。
そうなのですか。
>>631
Lockして書き込む際のD3DLOCKの種類のことですよね？
ここはよくわかっていませんでした。
D3DLOCK_NOSYSLOCKを指定していました。
Lockの際に、D3DLOCK_DISCARDを指定すれば動的頂点バッファになるということですね。
CreateVertexBufferの第二引数はD3DUSAGE_WRITEONLYでOKですか？
いろいろやり方が見えてきたので早速試してみたいと思います。
ありがとうございました。
635:デフォルトの名無しさん
09/08/01 20:55:13
WRITEONLYが適切。
だけどこのスレで「間違えて読み込みしてて、性能だだ落ちしてた」ってのが実例としてあったから気をつけるこった。
636:デフォルトの名無しさん
09/08/01 21:10:38
質問です。
2D描画時のテクスチャー矩形転送のお約束として、
転送先座標を-0.5ｆするというのがありますよね。
あれの意義はわかりますし、そうやっているので普段は良いのですが、
拡大転送する際「テクスチャーの参照の際、隣のドットの色が影響してしまう」現象が起きるようです。
これを回避する方法はないでしょうか？
LINEARを使わず、NEARPOINTでやればいいのでしょうが、拡大の粗が見えてしまいますので・・・。
637:デフォルトの名無しさん
09/08/01 21:19:08
一枚のテクスチャの中で別パーツと混ざるのが嫌なケース？
そりゃ周囲には1ピクセルずつ余白を置くとかじゃね。
昔の2Dゲームのような32x32のチップをぎっしり敷き詰められたデータなら、諦めるか、34x34で置き直すとか。
638:デフォルトの名無しさん
09/08/01 21:36:52
はい、そのケースです。
やっぱり余白しかないですか･･･。
縮小ならわかるのですが、拡大でも周りを参照しちゃうのがちょっと納得いかないところなんですが・・・
639:デフォルトの名無しさん
09/08/01 21:39:12
状況が許すなら、まず拡大しないブリットでチップを
レンダーターゲットのテクスチャに敷き詰めて
そのテクスチャを拡大するって手はある
640:デフォルトの名無しさん
09/08/01 21:46:51
>転送先座標を-0.5ｆするというのがありますよね。
そのやり方は正しいと思えないんだが。
むしろUVを半ピクセルずらすのが正しいやり方だろ？
UVをそのままで表示座標を変えてごまかしたりするから、表示倍率を変えると狂っちゃうわけで。
UVマッピングの詳細はMSDNにちゃんと書いてあるので確認すること。
ちゃんとやったらチップを画面いっぱいに並べようが拡大しようが、ずれたりすることはないよ。
現に手元で動いてる。
641:デフォルトの名無しさん
09/08/01 22:03:18
>>640
0.5ずらすのは
「バイリニアフィルタを適用している時に」
「頂点座標をスクリーン座標に直接マッピングすると」
ピクセルがテクセルの中心にマッピングしてしまい、拡大してなくてもぼやけてしまうのを防ぐためでしょ。
だから表示倍率を変えると云々はそもそも文脈としておかしいんだが。
642:641
09/08/01 22:06:18
うん、俺の文もおかしい。
x テクセルの中心
o 4テクセルの中心
643:デフォルトの名無しさん
09/08/01 22:16:46
>>641-642
オレの言ってることと君の言ってることはほとんど同じような気がするんだが、どうだろうか。
当倍表示の場合は636でも640でもいいが、拡大表示したら636ではおかしくなる。
そういうことだろ？
というか、そんな細かい処理をするときはフィルタはNoneにしたほうがいいと思うんだが。
拡大・縮小はきたなくなるけどな！
644:デフォルトの名無しさん
09/08/01 22:20:30
>>640
一応
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
これには目を通しています
これでも、ほかのサイトでも、転送先座標を + xy(-0.5f, -0.5f) するように思えます
640さんの方法は、拡大しても隣の色を巻き込んだりしないのでしょうか？
一応「座標はそのままに、UVを半ピクセルプラスする」方法でもやってみましたが、やはり拡大時には隣の色を巻き込んでしまうようです。
645:641
09/08/01 22:29:42
>>643
拡大するとおかしくなるんじゃなくて隣の色を拾うんだから
アルゴリズム上は正確な挙動だよ。
てゆーか言ってるのはテクスチャ座標を0.5テクセル分ずらす方法だよね？
言い忘れてたけど、その方法だと拡大はせずに反転した時に
完全なミラーにならずに一ピクセル分表示がずれちゃうよ。
そっち方法で隣の色を巻き込まないってのは、うーん、
手元で試せないので「そんな馬鹿な」としか言いようが・・・
646:デフォルトの名無しさん
09/08/01 23:11:12
ＦＦＴ式に回転させるとそんな苦労も水の泡だぜ
647:デフォルトの名無しさん
09/08/01 23:29:58
周りからそんなに反論されると、なんか自分も自信がなくなってきた。
まあそれはともかくとして、
表示を10倍くらいに拡大すると、もはや直角二等辺三角形２つを並べたテクスチャの斜めの辺の挙動が無視できなくなるな。
大体10x10にならんでるけどところどころ９になったり１１になったりする。
それに斜めにずれているところがあることに気づく。ちょうどポリゴンを斜めに並べたところだ。
なんだかどうにもならないことのような気がしてくる。
頂点を共有せずに微妙に１ピクセル分ずらしたりの調整が必要になってくるのかも。
648:デフォルトの名無しさん
09/08/02 00:21:13
とりあえず軽く実験してみたが、
転送先スクリーン座標を-0.5f, -0.5f しただけでは、拡大転送時に周りの1ドットの影響を受けてしまうな
649:デフォルトの名無しさん
09/08/02 00:33:43
>>648
そうだなぁ。例えば１０倍拡大したときは0.1f、0.1fくらいでちょうどいいようだ。
微妙に9倍や11倍されてるピクセルがあるようだが、
こんなに拡大されたＣＧを凝視するようなことはないだろうから実用上は問題ないだろう。
２Ｄ表示における倍率に指定すべきUVオフセットが影響を受けるのかもしれない。
しかしGPUの機種の差異もありそうだしなぁ。
650:デフォルトの名無しさん
09/08/02 14:36:23
>>641が言っているように、0.5ずらしは
本現象とは何の関係もない。
D3DTEXF_LINEARが、2x2エリアをサンプルするのが原因。
一応、UV座標を半テクセル分内側にずらすことで回避出来る。
float texture_width = 512;
float texture_height = 512;
float wh = 1.0/(texture_width*2);
float hh = 1.0/(texture_height*2);
float uv_quad = { u0 + wh, v0 + hh, u1 - wh, v1 - hh };
ただし、ずらす分マップするエリアが狭まるので注意。
651:デフォルトの名無しさん
09/08/02 15:24:25
状況や描画させ方によるので
唯一これが最速だという答えは出せません。
ゲーム、あるいはエンジンに合わせて最適化がそれぞれ必要です。
652:デフォルトの名無しさん
09/08/02 15:28:10
それでも、Direct3D9で2D等倍表示をするときだけしか正しくない「頂点座標を0,5ずらす」を
後生大事に信じ込むのは馬鹿だろう
653:デフォルトの名無しさん
09/08/02 15:40:27
基本的な質問で申し訳ないんだが、
GPUの機種によって描画できる場合と描画できない場合ができていて困っている。
原因は何が考えられるだろう？
動作条件は
・DirectX 9使用
・Vertex/PixelShader使用
・FVFはPosition|DiffUse|UV
・空間座標変換はCPU側で事前に合成してから単一の4x4行列としてID3DXEffectに入力。
現行のプログラムでRADEON HD4850だと正常にポリゴンが描画できるが、
Intel GMA950では描画されない。Device->Clear()は動いてる。
また、FVFがPositionRhw|DiffUse|UV のときは描画できることも確認している。（座標変換が利かなくなるが）
シェーダー使ってなかったころのプログラムやシェーダーを使ってる
サンプルプログラムでは描画できてるから、ハードウェアのせいではない。
654:デフォルトの名無しさん
09/08/02 15:45:16
きわめて一般的な描画方法だからどこかおかしいんと違う？
655:デフォルトの名無しさん
09/08/02 17:51:26
>>653
それだけの情報で分かるわけないだろう。
デバッグランタイムも何も文句言わないの？
656:デフォルトの名無しさん
09/08/02 19:32:40
>>655
デバッグランタイムは動かしたことないな。試してみる。
開発マシンじゃなくてテストマシンだったからDirectX SDKは入れてないので。
vs/ps3.0を指定してたら描画結果が真っ白になってしまったことはあったけど、
今回はそんなわかりやすい現象じゃないからなぁ。
657:デフォルトの名無しさん
09/08/02 23:00:15
URLﾘﾝｸ(developer.download.nvidia.com)
Stencil Routed K-BufferってDirectX9では出来ないんでしょうか？
マルチサンプルへのアクセスが必要でDirectX9では出来ない、というようなことが書いてありますが
マルチサンプル使わずに出来たりはしないんでしょうか。
658:デフォルトの名無しさん
09/08/03 00:21:35
ここで質問していいのか微妙な内容なのですが
スレ違いでしたらスルーしてください。
DirectXを使用するとどうしても気になってくるんですが
プログラムで使用されているVRAMの消費量を調べる方法はありませんか？
メモリ使用量を調べるような関数があるのかと思ったのですが見つけられず…
よろしくお願いします。
659:デフォルトの名無しさん
09/08/03 02:01:17
DeviceCaps取得すれば
ＶＲＡＭ容量わかるお
660:デフォルトの名無しさん
09/08/03 13:27:18
nai
661:デフォルトの名無しさん
09/08/03 13:27:58
このスレにいる人レベル高いなぁ
多分大学生が多いだろうから、大手狙いなんだろうなぁ……負けないように何か作るか
662:デフォルトの名無しさん
09/08/03 14:04:14
Zバッファがうまく動かないんですが
環境
WindowsXP VisualStudio2005 MFC Geforce9600GT
初期化
m_d3dPP.EnableAutoDepthStencil = TRUE;
m_d3dPP.AutoDepthStencilFormat = D3DFMT_D16;
LINE_VERTEX line[6] = {
{-1 , 0, 0, 0xFF00FF00},
{1 , 0, 0, 0xFF00FF00},
{0 , 0 , 0 , 0xFFFF0000} ,
{0 , 1 , 0 , 0xFFFF0000},
{0 , 0 , -1 , 0xFF0000FF} ,
{0 , 0 , 1 , 0xFF0000FF}
};
CreateVertexで書き込み