1 名前:デフォルトの名無しさん mailto:sage [2008/04/09(水) 09:55:56 ] ※回答する人も、質問する人も必ず読んでください これらに当てはまる人のための質問スレです。 1.C/C++は多少理解している。 2.最近DirectXを始めたばかり 3.SDKを見ても、Googleで検索しても、いまいち理解できない人 4.余計な雑談は不要ですよ 【 回答してくださる方 】 ・ できるだけ優しく質問に答えてあげてください。 ・ 優しく教えるのが嫌でしたら、解決するためのヒントだけでも結構です。 「ググれ」「SDK見れ」以外の回答でおながいします。 ・ 神ですら理解不能な質問は無視して下さい。 【 質問する方 】 ・ どんな事で躓いているのか明確にしよう。 ・ 長くならないなら躓いている部分のコードを晒してみれ。 ・ 解決した場合、お礼を言うのは当然だが、何をどうしたら解決したかを明確に書こう。 ・ 回答して貰ったら、出来るだけお礼もしよう。 【C++】 DirectX初心者質問スレ Part16 【C】 pc11.2ch.net/test/read.cgi/tech/1202634347/
401 名前:デフォルトの名無しさん mailto:sage [2008/05/09(金) 04:47:40 ] >>399 言い訳にしか聞こえないw
402 名前:デフォルトの名無しさん mailto:sage [2008/05/09(金) 06:45:56 ] どう考えてもボーンとかよくわかってない人がとりあえず 頑張ってみました的臭いするやんか?
403 名前:デフォルトの名無しさん mailto:sage [2008/05/09(金) 10:28:23 ] >>401 昨今のグラフィックカードでは常識
404 名前:デフォルトの名無しさん mailto:sage [2008/05/09(金) 14:53:11 ] スキニングの計算をCPUでやることになるから グラフィックカードあんまり関係なくね?
405 名前:デフォルトの名無しさん mailto:sage [2008/05/09(金) 15:13:41 ] ボーンを使おうが使うまいが階層のマトリックス演算は結局行なう。 そのマトリックスをWorldとして頂点シェーダーで計算するか、 スキン用のマトリックスとして頂点シェーダーで計算するかの違いだろ。 ボーンの場合Offset用の演算が加わるが、 DrawPrimtiveのコールはマトリックスの乗算とは比較にならないくらい重い。 スキンの処理までCPUでやるっつーなら話は別だけどDirectX7でやってるわけじゃないっしょ。
406 名前:デフォルトの名無しさん mailto:sage [2008/05/09(金) 15:29:43 ] スキンの処理までCPUでやるようにしないと、この輪郭線抽出はできませんよね? ttp://www.twin-tail.jp/contents/vsdx8/d3d/011/index.htm
407 名前:デフォルトの名無しさん mailto:sage [2008/05/09(金) 16:08:51 ] >>406 DirectX7世代でやるならそうなる。 それ以上ならもっとよい方法が存在する。
408 名前:デフォルトの名無しさん mailto:sage [2008/05/09(金) 20:43:33 ] >>407 よかったら輪郭線抽出について情報いただけませんか Zバッファの差を見る方法や、マテリアル境界を見る方法、モデルをちょっと太らせて裏返して黒描画する方法など色々調べましたが 406のURL先ほどまで「正確」で「自在な太さ」にできる術が見つかりませんでした
409 名前:デフォルトの名無しさん mailto:sage [2008/05/09(金) 21:35:32 ] トゥーンレンダリング
410 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 02:49:05 ] >>406 のは 希望をこめて絵を修正してるって書いてあるやん
411 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 03:21:23 ] >>408 そこまで知りたいなら金だせよ
412 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 10:46:29 ] >>408 自分で答え書いてるじゃん。 深度バッファやマテリアルの境界を輪郭検出のアルゴリズムで線を引けばいい。 その場合1ドットのラインしか引けないわけだが、 1ドットのラインを別のバッファに書いてそのバッファを上下左右にずらして もう1度書くと太くなるというのはわかるかい?
413 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 21:09:08 ] >>412 もちろんその手の「太くする」方法はわかりますが、 深度バッファ法はちょっとひいったアゴのような、深度差が浅い部分に輪郭線が出ません マテリアル法でも同様です。 モデルをちょっと太らせて裏返す法や、406のURL先のものほど「正確な」ものはなかなかありません。
414 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 21:42:40 ] 内積が正か負で判断して線引く>>406 のをシェーダでかけば同等の正確さじゃないの?
415 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 21:57:07 ] ○輪郭線アルゴリズム 確かに>>406 のものが 最も正確でキレイに作れそうなので、 >>406 を主にすべきだな。 ○ジオメトリ操作は、なるべくGPUでやりたい。 1パス目:D3DFILL_SOLIDで描画 2パス目:D3DFILL_WIREFRAMEで描画 この2パス目を、先のアルゴリズムで 輪郭線のみ描かれるようにすればいいんじゃないの。 ○線の太さは任意に変更したい。 これは、2パス目を>>412 の方法で太くすればいいんじゃないの。
416 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 22:00:03 ] >2パス目:D3DFILL_WIREFRAMEで描画 > >この2パス目を、先のアルゴリズムで >輪郭線のみ描かれるようにすればいいんじゃないの。 書いてから気付いたけど、これはちょっと難しいかなぁ
417 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 22:03:56 ] >>414 頂点シェーダで線を引くことはできないと思いますけど… >>415 その方法ですと、やはりアゴなどに輪郭線を出すことができませんよね。
418 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 22:05:38 ] >>406 のものと同等の正確さというのはかなり難しいなぁ… GPUを使ったものは、やはり速さ優先で作られてるし
419 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 22:07:33 ] うるせえ!!!
420 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 23:26:00 ] 「自在な太さ」というのが>>406 だと結構難しいはずなので(あと処理がキツイだろこれ) 結局のところ割り増しモデルを裏返し手法に落ちついちゃうんだよなぁ。 精度は落ちるけど、押し出す頂点位置を距離によらず一定になるように頂点シェーダで 調整すればそれなりの見栄えにはなる。
421 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 23:31:03 ] >>420 I3DXLine使えば太さは楽勝じゃね? 頂点データをもとに自前で線引いてるんだから
422 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 23:46:00 ] >>421 使ったことないので知らんが、あれでは太くなったら普通に線の一部が元モデルにめり込むか、 Z値を考慮せずに描画されるならなおさらこの手法には使えないのでは? 一ドットの線ならZバイアス使わんでも自前で射影行列なり弄れば>>406 の「理想」の線は描画できるが、 それ以上の太さになるとポリラインで表現することになり、そうなればどこまで線のZ値を前に押し出せば 元のモデルと重ならずに描画できるかは簡単には見積もれないはずだ。
423 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 09:25:17 ] >>422 ああ、ごめん。モデル側にめり込むのはご法度って考えだったのね。 俺は太さ3までだったら、モデルに1ドットめり込むだけだから別にいいやって思ってたもんで >一ドットの線ならZバイアス使わんでも自前で射影行列なり弄れば>>406 の「理想」の線は描画できるが、 よかったらこのあたり、詳しく解説してくれないか
424 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 17:38:11 ] 法線方向にプッシュして裏返すのって、特許取ってなかったっけ?
425 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 21:26:54 ] ちょっとD3DFILL_WIREFRAMEが話題にあがったから試してみたんだが D3DFILL_WIREFRAMEにしてもD3DFILL_SOLIDと描画時間が一緒だったんだが… 何かの間違いだろうか? PixelShaderの呼び出し回数が段違いだと思うのに…
426 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 21:46:10 ] なら頂点シェーダーかCPUがボトルネックなんだろ。 たいした量描画してるわけじゃないなら大抵CPUがネック。
427 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 21:51:10 ] 質問です 今、PixelShaderを使う描画を学んでおり、自分のメインPCでは正しく動作しました。 試しにと、PixelShaderに対応していない(1.0にすら対応していない)古いサブマシンに持っていって動かしたところ、正しく動いてしまいました。 ここで疑問なのですが、何故正しく動いてしまったのでしょうか? どうやら PixelShader = compile ps_1_1 PS(); と書いた部分が、メインPCだと正しく適用されるが、サブPCだと無視され固定パイプライン(という呼び方でOK?)のPixelShaderにより描画されているっぽいです。 これはHLSLの仕様なのでしょうか? てっきりHLSLのコンパイルエラーとなり、fxファイルのロードに失敗するかとふんでいたのですが…
428 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 21:53:26 ] 補足です。 >ここで疑問なのですが、何故正しく動いてしまったのでしょうか? の時点では、書いていたPixelShaderが固定パイプラインのそれと同等だったため「正しく動いているように見えた」のです。 ためしにPS()内で必ず「黒」を返すようにしたところ ・メインPCでは正しく黒を ・サブPCでは通常通りの描画を したため「サブPCではPS()が無視され、固定バイプラインのPixelShaderが呼ばれている」と判断したのです。
429 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 21:55:50 ] >>426 どうやらボーンによる頂点変換(ソフトウェア処理)がボトルネックだったっぽ すまん
430 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 22:36:13 ] 確かに俺の環境も PS2.0世代のGPUのくせに PS3.0コンパイルのShaderが HWで動いているな。 多分これは、PS2.0に対応とか3.0に対応ではなく 2.0、3.0で追加された機能に対応しているという話だろう。 ただアンタの言うPSの代わりに固定機能が動くというのはないな。 勘違いだろ。
431 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 23:16:43 ] 対応してなくても動作はするけど 対応してないPCじゃコンパイルはできないよね あとピクセルシェーダーの動作って コンパイルしたマシン(のGPU?)に依存してる? 家のPCでテストした実行ファイルを仕事場のPCで動かすと 家のPCと同じ動作するけど コンパイルしなおすと動作が変わったりする
432 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 23:29:40 ] >>430 お返事ありがとうございます。 >ただアンタの言うPSの代わりに固定機能が動くというのはないな。 うーん、どういじっても PixelShader = compile ps_1_1 PS(); の PS()の中身は無視されてしまいます。 float4 f = {1.0f, 1.0f, 1.0f, 1.0f} return f; という単純なPS()の中身ですら、メインPCだと正しく真っ白になり、 サブPCだとPixelShader = compile ps_1_1 PS();の宣言がないがごとく振舞います。 エフェクトは D3DXCreateEffectFromFile でロードしています。
433 名前:デフォルトの名無しさん mailto:sage [2008/05/11(日) 23:34:51 ] D3DXが気を利かせてくれてるのかねぇ・・? PS非対応環境なんてもはや持ってないから、アドバイスできん。すまん
434 名前:デフォルトの名無しさん mailto:sage [2008/05/12(月) 03:39:42 ] なんもエラー出てないの?
435 名前:デフォルトの名無しさん mailto:sage [2008/05/12(月) 15:10:21 ] 何もエラーでないですね…。 ただ、ReleaseビルドのEXEファイル生実行ですので、次はサブPCのVC6.0上でDebug実行し、D3DXのログ出力を見てみます。 家に帰るのは夜です 正直質問した時は、あっさり 「PSが無い環境では、compile ps_1_1 PS(); って記述は無視されて、固定パイプラインとして実行されるよ」 とかくるかと思っていたのですが…
436 名前:デフォルトの名無しさん mailto:sage [2008/05/12(月) 22:44:35 ] 435です。 やはり特にエラーメッセージもなく、単にスルーされているだけっぽい動作です。 どなたか心当たりあるかたいらっしゃいませんかー? 仮説 PixelShader = compile ps_1_1 PS(); などは、動作環境のサポートバージョンが、コンパイル指定したバージョン未満の場合は (エラーを出さず)変わりに固定パイプラインを呼び出す
437 名前:デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:55:38 ] >>436 はじめにサポートバージョンってわからないっけ?CAPSで つか、何がしたいんだっけ?
438 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:35:14 ] >>436 それ固定昨日と頂点定義が一致してないとランタイムで死ぬだろ
439 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 09:47:00 ] >>437 やりたいことというより、こういう動作をするものなの?という疑問を解決するのが目的ですね。 CAPSでシェーダのバージョンはとれるので、意図しない動作を起こさないようにバージョンではじくことは可能ですね。 >>438 ちょっといまいちわかりませんが、頂点シェーダでの出力定義が「(固定パイプライン的に)普通」じゃないとランタイムエラーになるということでしょうか? そもそも頂点シェーダでは「普通」じゃない出力はできないと思っていましたが違うのでしょうか? (だから計算結果とかを、使ってないテクスチャーUVの中に入れるとかでごまかして渡す) とりあえず、そんなことをしている場合は描画がしっちゃかめっちゃかになりそうですね。
440 名前:788 [2008/05/13(火) 17:48:16 ] directXのAppwizardってVC++6の時代のものですか? UPdate Summer2003(v9.0b)では,CD3DApplicationという汎用クラスが あったのに最新バージョンではなくなっています. その代わり,DXUTというフレームワークがふんだんに使われています. directXのバージョンによってプログラミングテクニックがころころ変化して いるように見えるんですけど(1〜2年前の参考書が最新バージョンと大きく 食い違っている),いったいどのバージョンを勉強したらお得なんでしょうか? 小生,これからdirectXを勉強しようというものです. やっぱり,最新バージョンでSDKを使ってシコシコ書くのがベストでしょうか? MFCのdaialogベースでdirectxを使ってみたいのですが. あと,DXUTを解説している本やサイト(英語でも可)があったら教えてください.
441 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 18:29:35 ] ttp://www.kohgakusha.co.jp/books/detail/978-4-7775-1272-0 これとかか? ただし、DXUTの仕様はSDKのバージョンごとに変わってたりするんで そのまま使えるかどうかはしらね
442 名前:デフォルトの名無しさん [2008/05/13(火) 19:48:34 ] >>441 ありがとうございます。早速、購入してみます。
443 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 20:05:47 ] ID3DXLineって便利だけど 遅いの?
444 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 23:29:46 ] >>439 例えば、自分が固定パイプラインと同じ機能をシェーダ使って実装するとしてどうなる?って話じゃねぇの
445 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 23:19:22 ] シェーダの質問なのですが、 D3DFMT_R16FやD3DFMT_A8のように4要素のないテクスチャで float4でtex2Dを取得した場合zやwはどんな値になるのでしょうか? 不定なのか、0が入るのか、前の値が保持されたままなのか、など教えていただけると助かります。
446 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 00:14:53 ] ドキュメントくらいはちゃんと嫁。 float4(0, 0, 0, 1)に対して渡された要素が上書きされるイメージ。
447 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 00:28:16 ] >>446 ありがとうございます。 ドキュメントの探し方が甘かったようです。申し訳ありません。
448 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 18:07:18 ] www.geocities.co.jp/SiliconValley-Oakland/9582/GamePrg/JoyTest.lzh のexeを実行するとちゃんと動くんだけど、ソースをVC++2008で、コンパイルするとうまく動かない。 どうも、lpDIJoyDev->QueryInterface でfalseが返ってるみたいだけど、どこ修正すればよい?
449 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 19:39:30 ] >>448 PCに入ってるSDKのバージョンがそのソースの想定したSDKの バージョンとあってないとコンパイルできないよ
450 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 20:46:38 ] ごめん、コンパイルは通るけどオリジナルと挙動が違うってこと。。
451 名前:デフォルトの名無しさん mailto:sage [2008/05/15(木) 20:50:07 ] 引数とかも違うだろ?
452 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 12:45:26 ] >>450 exeがなかったので違いがわからないけどソースからビルドしたやつも普通に動作してるよ 挙動が違うとは具体的に何が違うの
453 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 16:21:26 ] 質問です。 Radeon 9600 series AGP 128MB(ドライバは ttp://ati.amd.com/support/drivers/2k/radeonx-2k.html )の環境にて、かなりおかしな挙動をしています。(OSはWindows2000) 何か情報ありませんでしょうか。 なお、その他の環境3個所くらいで試してみましたが、特に問題は見られませんでした。 ・テクスチャーの表示がおかしい 256x256サイズのテクスチャーを10枚程度読み込んだあたりから、一部のテクスチャーの表示がおかしくなります。 テクスチャはD3DXCreateTextureFromFileで読んでいます。 テクスチャーが張られているモデルは、Xファイルで読み込んだ板ポリや、立方体などの単純なものです。 テクスチャーが張られているところが全体的にRGB(0,255,0)な感じに色になり、ほんのちょっとだけ元のテクスチャーの名残が見られるような、なんともバグった感じになります。 読み込むテクスチャーの数を減らすと、さっきバグって表示されていたものも綺麗に表示されます。 描画はプログラマブルシェーダを使わず、固定機能のものです。 ・固定シェーダの挙動がおかしい pDev->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_CURRENT); pDev->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_TEXTURE); pDev->SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_MODULATE); pDev->SetTextureStageState(1, D3DTSS_COLORARG1, D3DTA_CURRENT); pDev->SetTextureStageState(1, D3DTSS_COLORARG2, D3DTA_TEXTURE); pDev->SetTextureStageState(1, D3DTSS_COLOROP, D3DTOP_MODULATE); と設定しているのですが、 pDev->SetTexture(0, NULL); pDev->SetTexture(1, pTexture1); としたとき、pTexture1の色が乗算されません。 pDev->SetTexture(0, pTexture0); pDev->SetTexture(1, pTexture1); ではきちんと両方の色が反映されるようです。 Radeon 9600は比較的新しいボードですし、むしろ超古いGeForce2MX400とかではまともに表示されます。何か原因が思い当たる方いらっしゃいますでしょうか。
454 名前:デフォルトの名無しさん [2008/05/16(金) 16:37:56 ] 伝説巨人RADEON
455 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 16:52:15 ] 使い方がおかしい
456 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 17:01:16 ] >>455 どこか、>>453 の中に使い方がおかしいことを示す情報があったでしょうか? ご教示願えればありがたいです
457 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 17:14:54 ] ATIとnVIDIAの違いなんじゃね
458 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 17:43:47 ] >>453 の追加情報です。 pIDirect3D9->CreateDevice(adapter, D3DDEVTYPE_REF, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING | D3DCREATE_MULTITHREADED, ¶m, &pDevice); REFモードならバグりようがあるまい。と思って試してみようとしたのですが、 RADEON環境だとこの生成に失敗しました。 …RADEONというものは、思いのほかDirect3Dと相性が悪いのでしょうか?
459 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:18:00 ] >>453 SetTexture(0, NULL)してるのに、ステージ0でテクスチャ参照したら駄目だろう。 When a texture stage has D3DTSS_COLORARG1 equal to D3DTA_TEXTURE and the texture pointer for the stage is NULL, this stage and all stages after it are not processed. ARG1にD3DTA_TEXTUREをしておいて、テクスチャにNULLを設定するとそのステージ 以降が無効になる仕様だが、ARG2については何も書かれていないので未定義かも。
460 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:27:31 ] >>459 なるほど。ARG2がテクスチャ、かつNULLなときに後のテクスチャを参照してくれていたのは GeForceが「たまたま」そう定義していたからであったわけですね。 気をつけます。 ちなみにそこに気をつけるよう改良してみましたが、1番目の「・テクスチャーの表示がおかしい」は相変わらずです。
461 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 20:04:30 ] >>460 それもなんかおかしいんじゃねぇの?w 基本的にnVidiaのボードは確かに未定義や おかしな部分を変な風に救っちゃう設定だからRADEONで開発したほうがいいぜ 俺も開発のときにnVidiaのボード使ってて苦労した
462 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 20:16:19 ] >>459 知らなかったw
463 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 20:24:29 ] 固定シェーダの恐怖だな nVidiaとその他一部のボードでは動くんだけど それ以外ではうんともすんとも言わないとかいう状況がありえる恐怖 (納期まで一週間とかいう状況ではじめてRADEONで動かして画面真っ黒になったときは血の気が引いたw) HLSL使うようになってからそういう苦労は一応消えた 固定シェーダ止めるとこの辺はグッと楽になる
464 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 20:27:22 ] >(納期まで一週間とかいう状況ではじめてRADEONで動かして画面真っ黒になったときは血の気が引いたw) > いやあああああああ
465 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 21:05:12 ] >>461 なるほど、とりあえずRADEONの購入は検討してみます >>463 それは血の気が引きそうですね 私も公開するゲームを作っているので、なるべくRADEONにも対応したいところです 全てHLSLで書くのも検討していますが、「・テクスチャーの表示がおかしい」の件は、HLSLを使った描画の部分でも発症しているので困ったものです…
466 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 21:47:12 ] DirectXの勉強をはじめたいのですがもう固定機能パイプライン?は無視してHLSLとかプログラマブルな シェーダーの勉強を始めたほうがいいのでしょうか?
467 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 21:55:47 ] 自分の開発環境がプログラマブルシェーダに対応しているなら、そっちのみでいいと思われる。 VertexShaderは最低でもソフトウェアエミュレートができるし、 PixelShaderにしてももう対応していないグラボなんて存在しないと思っていい。 でもオンボは対応してねーんだよなぁ('A`)
468 名前:466 mailto:sage [2008/05/16(金) 21:58:34 ] MSのカンファレンスでもらったVS2008スタンダードにGe7900gs、OSはXPです。 固定機能はさすがにいいですかね。
469 名前:466 mailto:sage [2008/05/16(金) 21:59:39 ] ありがとうございました。
470 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 22:03:59 ] 皆さんノートPCのことも考えてあげてください もしくはこの世から全てのオンボードPCを破壊してくださいマジでもう
471 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 22:15:54 ] >>452 vc++2008ではまんまではコンパイルとおらなかったので、DInput.cppの 63行目 ret = DirectInput8Create(hinst,DIRECTINPUT_VERSION,IID_IDirectInput8,(void**)&lpDInput,NULL); 115行目 ret=lpDInput->EnumDevices(DI8DEVCLASS_GAMECTRL,InitJoystickInput,lpDInput,DIEDFL_ATTACHEDONLY); に修正してコンパイルとおしたんだけど、126行目がfalseを返してくるの。
472 名前:453 mailto:sage [2008/05/16(金) 22:29:39 ] 色々アドバイスありがとうございました。 >・固定シェーダの挙動がおかしい この件ですが、RADEON上だけでなく、GF上でもREFモードだとうまく表示できませんでした。 >>459 さんのアドバイスがクリーンヒットだったようで、気をつけながら直したところ、REFでも綺麗に表示されるようになりました。 RADEON上でpTexture1が乗算されるようになったようです。 (ただし、pTexuter1自体がバグっているため、乗算はされたものの、おかしなテクスチャが乗算されています) 今後はREFモードでちょくちょくチェックしながらやっていきます。 現在は、RADEON使いと連絡がとれなくなってしまったため、 「・テクスチャーの表示がおかしい」については後日また調査して、報告します。 どうしても治らない場合はまた相談させていただくかと思いますが、その時はよろしくお願いします。
473 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 22:36:29 ] お疲れさん ちゃんと報告してくれる質問者は歓迎だぜ
474 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 23:08:47 ] ウホッここを覗いててよかった ラデオン買ってくる
475 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 07:41:55 ] >>471 DIrectX 7以下じゃないと動かないよ 8にするなら全部書き換えろ
476 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 07:49:36 ] >>448 Dinput.hに #define DIRECTINPUT_VERSION 0x0700 を追加
477 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 20:09:42 ] 関係ないけど、DirectInputってウイルスバスターが不正変更で〜って怒るとない? お兄さんたちはどうしてるのかな?
478 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 20:12:54 ] あ、あれってDirectInputのせいなんだ。。。 僕の作ったソフトも怒られるから気になってたけど。。。
479 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:32:53 ] ウイルスバスターはDirectInput使うと怒るのね 友人にテストしてもらったら 「不正な変更とか出る ウイルスだろこれ?」 とか言われたお ネットワーク対応ゲームでも作ろうかと思うんだが、 DirectPlay使うのとWinSock使うのとどっちがいいんだろ DirectPlyaはWinSockに比べるとダメだという話をよく聞くけど どこがどうだめだかよくわかんね 手軽に実装するならDirectPlayのほうが楽そうにも感じる そこら辺詳しい人いませんか?
480 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 17:25:02 ] あんま詳しくないが、TCP使えないらしいお。 そういった制限があるから、やっぱ「お手軽通信」なイメージはある。 Winsockは、アプリケーションが使うTCP/IPの基本かつ全てだから DirectPlayに出来てWinsockに出来ないことはない。 そういう意味だとオモ<Winsockに比べるとダメ 本当にTCPが使えないのなら、オンラインRPGには無理なだ。
481 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:00:21 ] 今右ドラッグで3Dオブジェクトを回転させるのをやっていて、とりあえず D3DXQuaternionRotationYawPitchRoll(&q,マウスのX変移,マウスのY変移,0); とやってそれっぽい動きにはなってるんですが、どうもメタセコとかと操作感が違うんですよね。 ドラッグ開始時にXYの回転軸を作って、それに対する回転てやりたいんですが 何使ったらいいですか?
482 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:11:10 ] >>481 RotationYawPitchRollは角度が非常に小さければ任意軸周りの回転に 近い動きをするが、本来は全く違うもの。 マウスの移動量とZ軸で外積を取って、その軸周りの回転を使う。
483 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:20:19 ] >>482 親切にありがとうございます。意味はなんとなく分かるんですが、頭がついて来れなくて・・・ で、それはZ回転が起こらない場合にのみ使えるんですよね?多分(今回はそれでもいいですが)
484 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:57:07 ] >>479 色んな通信に対応しすぎてて、初期化が遅いのが一番の不満かな<Play といってもPlay使ってたのはDirectX7の頃だから、改善されてるかもしれんが。 WinSockなら全ての通信を自分で把握できるのが強み。
485 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 20:27:13 ] >>484 DirectPlayは廃止されて久しい。 WinSockを叩くのが一番無難で楽しい。
486 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 20:32:54 ] WinSockだとセッションとかのゲーム的な概念がないから そこらへんも全部自分で実装しなきゃならないんだよね? WinSockのネットゲームで使えそうなお手ごろサンプルがあるといいんだけど
487 名前:デフォルトの名無しさん mailto:sage [2008/05/19(月) 03:08:12 ] 質問です。 DirectXを使って2Dゲームを作ってみようと思ってMSDNのリファレンスを見ていたところ、 CreateVertexBuffer()で頂点バッファを作ってLockとUnLockの中で頂点を処理していました。 ですが、別のホームページにはこれらを使わずに描画してるページもありました。 2Dの場合はCreateVertexBufferを使わずに描画したほうがいいのでしょうか? それともCreateVertexBufferを使わなくても描画出来るという解釈でいいのでしょうか?
488 名前:デフォルトの名無しさん mailto:sage [2008/05/19(月) 03:22:35 ] 別にどういうやり方しても構わないよ。 ただ、 ・頂点バッファをビデオメモリ上、AGPメモリ上に作ると描画が速い ・が、そういう場所に作った頂点バッファをLockするのは重い(ビデオカードの処理を止めるから) ・システムメモリ上に作った頂点バッファのロックなら遅くない(多分。)が、 それは頂点バッファ作らない方法と同じこと。ビデオカードから遠いので描画は遅い 毎フレーム書き換えるような頂点配列なら、システムメモリに置くか 頂点バッファ使わずにやるのがのがいいんじゃないかと。 検証とかしたことないので間違ってたら指摘ヨロ
489 名前:デフォルトの名無しさん mailto:sage [2008/05/19(月) 03:26:37 ] チラシの裏にでも書いてろ
490 名前:487 mailto:sage [2008/05/19(月) 03:43:14 ] >>488 なるほど、どっちの処理が重いかで使い分けるといいみたいですね。 ありがとうございます。
491 名前:デフォルトの名無しさん mailto:sage [2008/05/19(月) 10:26:00 ] >>488 追加⇒DYNAMICとDISCARDフラグを組み合わせると描画もLockも速いがメモリを食う。
492 名前:デフォルトの名無しさん mailto:sage [2008/05/19(月) 13:56:52 ] >>489 なるほど、チラシの裏ですね よくわかりました
493 名前:472 mailto:sage [2008/05/19(月) 19:22:45 ] 色々アドバイスいただいた>>453 です。 >>459 さんのアドバイスによる修正のおかげか、RADEON上でも綺麗に表示されたそうです。 ありがとうございました。 D3DTSS_COLORARG1 にTEXTURE D3DTSS_COLORARG2 にCURRENT なるべくこうするのが吉。というわけですね。 大抵の初心者サイトがこうしている一方、時々は逆も見かけるようです。 他の人が同じ失敗しませんように…。
494 名前:デフォルトの名無しさん mailto:sage [2008/05/19(月) 19:35:23 ] チェックしたら見事に失敗してたわ SDKをもう一回全部読み直したほうがいいかもなー・・・
495 名前:デフォルトの名無しさん mailto:sage [2008/05/19(月) 20:06:53 ] 演出について質問 キャラが地面に着地した際、演出として着地点のまわりに衝撃波を立てたいと思っています 例えるなら、牛乳の入ったコップに牛乳を一滴おとした時にできる、王冠のようなものです こういう演出はどのようにして実装するのが良いでしょうか? 今まではボーンアニメまでしかやったことがないのですが、モーフィングという技術のほうがより良さそうな気がしています
496 名前:デフォルトの名無しさん mailto:sage [2008/05/19(月) 23:56:15 ] >>495 スケーリングで十分
497 名前:487 mailto:sage [2008/05/20(火) 00:09:01 ] >>492 調べてみたら動的に確保したメモリを静的に確保したように見せるとのことだったんですが、 これはVRAMとAGPメモリに確保して同期させるという解釈でいいのでしょうか?
498 名前:487 mailto:sage [2008/05/20(火) 00:09:52 ] すいません>>492 ではなく>>491 でした
499 名前:デフォルトの名無しさん mailto:sage [2008/05/20(火) 01:53:49 ] >>497 昔はそうなんだが、現在のVGAだと諸々の理由でシステムメモリを介したコピーを 行っているものが多いので、動的な頂点バッファはほとんど意味を成さなくなっている。 経験で言うならシステムメモリよりも頂点バッファを使う方がパフォーマンスが高くなる 傾向があるのは確かだが、大半は大した性能差があるわけでもないし、 そもそも適切に扱うためのフラグ設定が頂点バッファはわかりにくいので、 個人的にはシステムメモリ(DrawIndexPrimitiveUP等)で実装することをお勧めする。 2Dスプライトの実装なんぞDrawPrimitiveのバッチ処理さえしておけば それ以上は深く考えんでも良いと思うぞ。
500 名前:デフォルトの名無しさん mailto:sage [2008/05/20(火) 08:28:59 ] AGPメモリを使うか否かで動的なデータは速度に大差が出るぞ