DirectX総合スレ (Part9)

**名前は開発中のものです。** · 2009/02/11(水) 05:00:58

**名前は開発中のものです。** · 2009/09/19(土) 11:46:24

>>722
ありがとうございます。早速読み始めました。
書籍でも一応学んだ部分も有るので、知らないワードはググりながら読み進めて行こうと思います（｀・ω・´）

**名前は開発中のものです。** · 2009/09/19(土) 14:50:51

ヘルプは細かい事を調べるにはいいけど、
一連の流れをつかみにくいから
DirectX実践プログラミング読みなよ。
事実上、これから始めるのがスタンダードだと思うんだけど。

**名前は開発中のものです。** · 2009/09/19(土) 17:22:47

helpが教科書
googleが先生

**名前は開発中のものです。** · 2009/09/20(日) 10:01:57

Googleは実際はただの仲介業者で、Google含めたWeb全体が先生

**名前は開発中のものです。** · 2009/09/20(日) 17:22:38

>>726
検索ヒットの末尾の方とか読まんだろ？

**名前は開発中のものです。** · 2009/09/20(日) 19:11:34

いやいや、実際の学校の先生も仲介役だろう
先生を含めた世の中全体が先生って解釈もあるが

**名前は開発中のものです。** · 2009/09/20(日) 21:48:19

http://ranobe.com/up/src/up397377.jpg
http://ranobe.com/up/src/up397378.jpg

DirectInputの勉強をしています。一応、入力した値の取得は出来たのですが、
「アナログ→デジタル」に切り替えると、なぜか「-8」が入力され続けてしまいます。
これはどうしてでしょうか？

**名前は開発中のものです。** · 2009/09/20(日) 23:27:42

>>729
アナログは細かい誤差が出るのである程度遊びをもって入力処理するのが基本。

**名前は開発中のものです。** · 2009/09/21(月) 00:39:52

>>730
そうなんですね、ありがとうございます

**名前は開発中のものです。** · 2009/09/23(水) 12:50:50

すみませんテクスチャまわりについて２点の質問なのですが、

SetTexture関数を多用すると処理がどんどん重くなると聞き、
「連続して使う256x256のテクスチャ９枚」を切り替えまわるより
「連続ならば768x768(3個ｘ3個)のテクスチャ１枚にした方が早い」という意味だと思うのですが
テクスチャのサイズが上がると切り替えの負担は増えるのでしょうか？
(例えば途中で1/9枚だけアクセスしたくて切り替えると無駄に重い　など)

あと、水面を表現する時は「フレーム毎に別のテクスチャ」を使って表現しようと思っているのですが、
滝など流動的なものを表現する場合、テクスチャは１枚のままで
「UV座標を操作する事で表現する」なんて出来れば負荷も下がり滑らかなアニメーションが出来るかも
と思うのですが、UV座標の操作(というか抜き取りと再設定)は非現実的だったりしますでしょうか？

**名前は開発中のものです。** · 2009/09/23(水) 15:25:12

やってみて遅かったら考えろ

**名前は開発中のものです。** · 2009/09/23(水) 15:45:24

ハード次第なとこもあるから全て実測って訳にもいかないのがあれだけどな

**名前は開発中のものです。** · 2009/09/23(水) 16:11:35

昔のイメージだと256x256に出来るだけ収めて
それの切り替え回数を出来るだけ少ないようにするってのが速かったと思うんだが
今でも底辺に合わせるならそれなんじゃねーのかな

256x256にして切り替え回数をまったく減らせないのであれば大きい方1枚がいいんじゃね？

**名前は開発中のものです。** · 2009/09/23(水) 18:37:56

キャッシュに入っちゃったときとキャッシュで出し入れしてるかでも違うだろ
単純に切り替えて「ああ、そうか」とか結論を出すのも駄目
つまり、シーン毎にやってみるしかない

**名前は開発中のものです。** · 2009/09/25(金) 15:12:54

>>733-736
色々と知らなかった事情も知れて勉強になりました。
テクスチャを展開する場所も重要な訳ですね。
ありがとうございます。

**名前は開発中のものです。** · 2009/09/25(金) 21:50:39

展開する場所？

**名前は開発中のものです。** · 2009/09/26(土) 18:16:15

>>732
UVを変化させて水流などを表現する方法は、昔から標準的に使われていますよ。
(UVスクロールなどと呼ばれています。)
単純な技法ゆえに、一枚板ポリゴン上でおこなった場合は見た目があまり面白くありません。
しかし、グラフィックデザイナーの手によるポリゴンの繋ぎ合わせ・重ね合わせの妙のおかげで、
かなり見映えのする川や炎の表現になります。

**名前は開発中のものです。** · 2009/09/27(日) 01:34:23

少し疑問があったので質問を。初心者ですいません。
皆さんテクスチャの画像形式は何を使っていますか？
今のところ最初読んだ本に従ってbmpを毎回dds形式に統一して読み込んでいるのですが、容量ばかり多くてメモリを喰うもので。。
ついでにddsファイルの利点も教えていただけるとありがたいです。

**名前は開発中のものです。** · 2009/09/27(日) 03:23:24

多少色の再現度が落ちてもいいテクスチャーはJPGにしてる。

**名前は開発中のものです。** · 2009/09/27(日) 04:12:58

ファイル形式変わっても、メモリを食う量は一緒じゃないの？
テクスチャ圧縮とか使うならともかく。

**名前は開発中のものです。** · 2009/09/27(日) 05:12:13

しかも読み込みの時間も延びる（ほんのわずかだけど）

**名前は開発中のものです。** · 2009/09/27(日) 10:38:58

DXT、ミップマップ、キューブマップ、アルファチャンネル
このへんの機能を使うならDDSオンリーになるとおもうんだけど。

**名前は開発中のものです。** · 2009/09/27(日) 12:25:33

>740
今のところddsで問題無いからddsでやってる。
まあ、テクスチャ合計で10MBくらいだから大丈夫なんだけど。
でも、圧縮かけてメモリ上に置いておくと、描画の度に展開すると速度が
犠牲になりそう。
シーンごとに必要なテクスチャを分けておいて、シーソ移動ごとに必要なものだけ
展開してメモリに置いとくとかすれば良さそう。面倒になるけど。

**名前は開発中のものです。** · 2009/09/27(日) 12:29:36

っつか普通そうするだろ

**名前は開発中のものです。** · 2009/09/27(日) 14:50:35

そもそも今時のGPUがつんでるメモリ量を考えての発言なのだろうか・・・。

**名前は開発中のものです。** · 2009/09/27(日) 15:09:16

困ったことに「フリゲは非力なマシンで動いて当たり前」と考えてるユーザーは少なく無い。

**名前は開発中のものです。** · 2009/09/27(日) 15:09:58

（JPGはあくまで配布の都合なんで関係ないけど）

**名前は開発中のものです。** · 2009/09/27(日) 15:18:47

WindowsMeで動かないんですけど？

**名前は開発中のものです。** · 2009/09/27(日) 15:19:38

WindowsMEとかサポートするのはただのオナニーだろ

**名前は開発中のものです。** · 2009/09/27(日) 15:25:52

http://ja.wikipedia.org/wiki/NScripter
フリーゲームや同人の現実

**名前は開発中のものです。** · 2009/09/27(日) 15:50:21

フリゲや同人全般だと非力なスペックで動くゲームが一番人気あるからな、
その層を対象にするから中々スペック上げるのは難しい。
にしてもさすがにVRAM32ぐらいあれば家庭用ゲーには比べ物にならないぐらい潤沢ではあると思う。
よくある新しいPCなのに重いってのはノートだったりオンボだったりするのが原因だが、
これらの場合でもVRAMだけは多く取れると思う。

**名前は開発中のものです。** · 2009/09/27(日) 16:07:57

極限までのメモリ節約を考えないマはただの生ゴミ

**名前は開発中のものです。** · 2009/09/27(日) 16:20:30

すみません
D3DXLoadMeshFromX　で読み込んだＸファイルから
「法線情報」「頂点座標」「ＵＶ座標」「マテリアルNo」
にアクセス(読み書き)する方法
を解説しているサイトをどなたかご存知ではないでしょうか？

**名前は開発中のものです。** · 2009/09/27(日) 16:36:43

>>754
節約するのとサポートが打ち切られているようなOSで
動くようにするのは話が違う。

**名前は開発中のものです。** · 2009/09/27(日) 16:46:12

いやお前こそ何の話してるんだといいたい
ファイルの容量を上手く扱うための流れから勝手にズラしてるようにしか見えん

**名前は開発中のものです。** · 2009/09/27(日) 17:15:04

あまりに非力なスペックまで相手にするのは不毛だと思う

**名前は開発中のものです。** · 2009/09/27(日) 18:12:24

内容の割に不自然に重いって感じさせなきゃいいんじゃね？
たいした事やってないのに、異様に重かったり
異常にハイスペックを要求したり、こういうのこそオナニーだよね。

**名前は開発中のものです。** · 2009/09/27(日) 18:33:23

メッシュの頂点フォーマットを設定して頂点バッファを取得すればいい
マテリアルNoはたぶんアトリビュートテーブル

**名前は開発中のものです。** · 2009/09/27(日) 18:34:46

あ、760は>>755へのレスです

**740** · 2009/09/27(日) 19:28:26

なるほど。参考になりました。
やはりメモリ量を増やさないよう地道に努力するほかなさそうですね。。
とりあえずはddsで進めていこうと思います。

メモリ消費量に見合う処理を実現させたいですね。

**名前は開発中のものです。** · 2009/09/27(日) 20:05:19

DirectXがダウンロード出来なくなっちまったが、どうしたの？

**名前は開発中のものです。** · 2009/09/28(月) 00:41:50

DirectXは終了しました。あしからず

**名前は開発中のものです。** · 2009/09/28(月) 10:24:06

ＤｉｒｅｃｔＸってなかなかインパクトや説得力があってイカす名前だよな
誰が考えたのか知らんけど

**名前は開発中のものです。** · 2009/09/28(月) 13:18:55

Xファイルはドラマだか未知の謎だかで
バッドネーミングかと

**名前は開発中のものです。** · 2009/09/28(月) 13:27:20

Directダメ、必ずデバイスドライバを通せってことだよな

**名前は開発中のものです。** · 2009/09/28(月) 15:48:36

マイクロソフトのX好きはMSXの昔の頃かららしいよ

**名前は開発中のものです。** · 2009/09/28(月) 15:53:43

XWindow

**名前は開発中のものです。** · 2009/09/28(月) 16:25:24

XNA使ったらあれほど手が出なかったゲームループが一瞬でできました

**名前は開発中のものです。** · 2009/09/28(月) 17:51:23

Xファイルからメッシュを読み込んでDirectional Lightで照らそうとしているのですが、
なぜかライトが反映されません。
アンビエントライトおよびDirectionLightのAmbient値だけは反映されますが、Diffuseはチュートリアル通りに設定しても適用されません。
ライトの方向が間違っているのかと思い、ためしにライトの方向ベクトルを回してみても変化がありませんでした。
何が悪いんでしょうか。

DXViewerでは正常にグローシェーディングで陰影がつく形で表示されました。

**名前は開発中のものです。** · 2009/09/28(月) 18:53:02

Attenuation とかの値は設定したかい？

**名前は開発中のものです。** · 2009/09/28(月) 18:55:49

>>771
そのｘファイルに法線ついてる？
法線無い場合はD3DXComputeNormalsとか使わないと駄目

**名前は開発中のものです。** · 2009/09/28(月) 21:58:30

>>772
>>773
解決しました。
今回DXUTILのDXUTMeshクラスを初めて使ってみましたが、
SetFVＦだけでなくSetVertexDeclで頂点データを定義することを知りませんでした。
設定すると無事ライティングが機能しましたが、DXUTMeshを使っていたことを記述するべきでしたね。
すみませんでした。

**名前は開発中のものです。** · 2009/09/28(月) 22:15:42

>>760
ありがとうございます。情報を探してみます。

**名前は開発中のものです。** · 2009/09/28(月) 22:45:30

今現在、3Dオブジェクトとスプライトの２つの当たり判定を取りたいと思っています。

そこで3Dオブジェクトのワールド座標をスクリーン座標に変換したいのですが、そういう変換関数ありますか？

**名前は開発中のものです。** · 2009/09/28(月) 23:17:59

D3DXVec3Project

**名前は開発中のものです。** · 2009/09/29(火) 00:44:24

>>777

ありがとうございます。
なんとかさっきその関数を見つけることができ、実現することが出来ました。

**755** · 2009/09/29(火) 17:40:07

すみません。
D3DXLoadMeshFromX関数　から頂点/法線/ﾏﾃﾘｱﾙ関連　の情報を取り出す為に
「ID3DXMesh インターフェイス」http://msdn.microsoft.com/ja-jp/library/cc372520.aspx
これを利用したいのですが

ID3DXMesh型の変数(？)を宣言しようとすると
＞'ID3DXMesh' : 抽象クラスをインスタンス化できません。
とゴッソリエラーと警告が出てしまいます。

D3DXLoadMeshFromX関数の第８引数に渡したLPD3DXMESH型では当然「ID3DXMesh インターフェイス」は
使う事が出来ないのですが・・・どうすれば良いのでしょうか。

私はどこら辺を勉強して来ればこの辺の仕組みが解るのでしょうか　orz

**名前は開発中のものです。** · 2009/09/29(火) 18:57:23

インスタンスはポインタのアドレスを生成してくれる関数に渡してもらうんだよ。

**755** · 2009/09/30(水) 03:34:42

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

すみません、メンバって言葉に反応してピリオドを使ったミスでした orz
すぐ下でOptimize()でアロー演算子使って動いてるのに気付かず；
失礼しました orz

**名前は開発中のものです。** · 2009/10/01(木) 23:58:42

すみません、3D地面とキャラクターの衝突判定についてなのですが、
距離計算(内積)と反映までは出来たのですが、
１．衝突判定の処理軽減(判定対象の絞込み)にはどういうパターンが有るのか？
２．頂点と法線　どちらで判定すべきなのか？
３．内側にめり込む事の回避方法（尖っているポリゴンの境目からや処理落ちで等の）

これらの疑問でどう作れば良いかイメージができず困っています。
基本地面を歩きまわる軽いアクションゲーなのですが、
定番の方法などが有れば教えて頂けると幸いです。

**名前は開発中のものです。** · 2009/10/02(金) 00:11:29

どういう地面かによるけど
当たり判定取りたいキャラの真下の高さを取得してそれと当たりを取るのが最低限だろう

**名前は開発中のものです。** · 2009/10/02(金) 00:18:49

>>782
絞込みには、そっちには4分木が有効だろう。ちょっと敷居は高いが。
http://marupeke296.com/COL_2D_No8_QuadTree.html

後は境界球の作成から始めればいいんじゃない？

**名前は開発中のものです。** · 2009/10/02(金) 09:26:28

>>783
そうですね、今は数段階の判定対象の絞り込みで軽減をしてみようかと思います。
ありがとうございます。

>>784
ありがとうございます。4分木・・今はキツいですが、いずれは勉強して取り込みたいと思います。
＞境界球
なるほど。点じゃなくて立体で判定すればめり込み難そうですね。　試してみようと思います。

**名前は開発中のものです。** · 2009/10/07(水) 22:53:27

すみません
プレイヤーの数倍のサイズの敵への攻撃の衝突判定をする場合
１．円柱やボックスを大まかに中心座標から置いてそれを判定する
２．頂点数を減らした透明モデルを一緒に動かして、その面から外積(？)で判定する
この２つが思いつくのですが、
「低負担でそこそこの衝突判定」をする方法や理論が有れば助言頂けませんでしょうか？

**名前は開発中のものです。** · 2009/10/07(水) 22:56:56

当たり用の小さい球をたくさん敵につける

**名前は開発中のものです。** · 2009/10/07(水) 23:06:45

>>787
なるほど・・低負担でそこそこを楽に実現できそうですね。　ありがとうございましたっ

**名前は開発中のものです。** · 2009/10/12(月) 14:26:14

WindowsへDirectX 9 と10を両方インストールして
場合に応じて切り替えることはできますか？

**名前は開発中のものです。** · 2009/10/12(月) 16:22:18

DirectXには下位互換があるんだから10をインストールすれば9も使える

**名前は開発中のものです。** · 2009/10/12(月) 17:21:34

それを言うなら上位互換

**名前は開発中のものです。** · 2009/10/12(月) 21:22:38

_ASSERT と assertって同じ？別物？
定義を見ると違うっぽいので違うのだろうけど、どう使い分けるの？

**名前は開発中のものです。** · 2009/10/12(月) 21:34:24

>>789
そもそもOSに標準搭載されているのでインストールする必要性が無い。

**名前は開発中のものです。** · 2009/10/12(月) 21:37:57

>>789
SDKの話？

**名前は開発中のものです。** · 2009/10/18(日) 10:52:06

頂点ﾊﾞｯﾌｧをD3DPOOL_DEFAULT、
インデックスﾊﾞｯﾌｧをD3DPOOL_MANAGEDで描画して
私のビデオカードでは問題ないようですが、このようなﾊﾞｯﾌｧの運用は
一般的ですか？

**名前は開発中のものです。** · 2009/10/18(日) 19:50:42

普通だよね？

**名前は開発中のものです。** · 2009/10/18(日) 19:56:21

別に変なことじゃないだろ

**名前は開発中のものです。** · 2009/10/18(日) 22:08:31

>>797 　thx
frequency設定して別ストリームから合成描画する
２つの頂点ﾊﾞｯﾌｧを別々の設定でプールしたら
バグッたんで、色々気になっていました。

**名前は開発中のものです。** · 2009/10/19(月) 12:59:47

すみません
DirectInputでマウスのボタン操作を取得してるんですが
「マウスボタンが押されっぱなし」の状態を安全(確実)に取得する特別な方法は有るでしょうか？
変数で操作の取得毎にフラグをひっくり返し続けるだけでも
大丈夫なものなんでしょうか？(外部ソフトの負荷で処理落ちして逆さになったりしないか怖くて・・)

**名前は開発中のものです。** · 2009/10/19(月) 13:09:07

マウスを扱うならWin32APIの方が確実

**名前は開発中のものです。** · 2009/10/19(月) 13:34:42

>>800
そうなんですね。ちょっと調べてみます。
ありがとうございました。

**名前は開発中のものです。** · 2009/10/19(月) 16:46:13

>>799
逆さになるって意味が分からんのだが。
ボタンが押されたときと離されたときで、異なる値になるんだが。

**名前は開発中のものです。** · 2009/10/19(月) 21:14:06

男女男男女ですね
ちがうわー

ってことだろ

**名前は開発中のものです。** · 2009/10/20(火) 14:48:31

嬲嫐か

**名前は開発中のものです。** · 2009/10/21(水) 20:20:52

表示された3Dモデルをクリックやオンマウスする事で
情報を表示できる様にしたいのですけれど、

・D3DXComputeBoundingBox()でバウンディングボックスを生成
・その各頂点からD3DXVec3Project()でカメラ(2D)座標にする
↑の方法で合ってるでしょうか？
D3DXComputeBoundingBox()が上手く行かず合ってるのか心配に。。

**名前は開発中のものです。** · 2009/10/21(水) 22:39:00

>>805
まあ、それで間違ってはいない。
でも俺なら、ワールド座標系で
レイを飛ばしてボックスと当たり判定をするな。

**805** · 2009/10/21(水) 23:26:05

>>806
合ってはいるんですね。ありがとうございます。

＞ワールド座標系で
＞レイを飛ばしてボックスと当たり判定
レイが何なのかわからず利用法がわかりませんが、
ベクトル計算を省けそうでこちらの方が軽く済みそうな予感がしますね・・。
ちょっと調べてみますが、少しヒントを頂けるとありがたいです。

**名前は開発中のものです。** · 2009/10/21(水) 23:40:44

ヒント？ググレよ

**805** · 2009/10/21(水) 23:48:28

あー・・ググっててなんとなくおっしゃってる意味が解りました。
失礼しました。
やはりなるべく今の自分にできる程度の事でやった方が良さそうです；
ありがとうございました。

**名前は開発中のものです。** · 2009/10/23(金) 16:44:43

ライン描画にもインデクスって使うもん？

**名前は開発中のものです。** · 2009/10/23(金) 18:28:09

好きにするよろし

**名前は開発中のものです。** · 2009/10/23(金) 20:20:24

>>811
一般にどっちが高速か知ってる人がいたら押して欲しいっす。
自分の環境だけじゃ何とも言えないからね・・・
いや、マイナーなビデオカード使ってるわけじゃないし、
自分の環境だけでいいのかもう・・

**名前は開発中のものです。** · 2009/10/23(金) 20:31:04

自分の環境だけじゃ何ともいえないというのなら、
自分でテストプログラムを作って、他の人に試してもらえばいいだろう。

**名前は開発中のものです。** · 2009/10/23(金) 23:47:41

ラインで何書くのかしらんが、共有頂点少なくてLINESTRIPで書けるなら
インデックスバッファなんぞ逆に無駄になるだろ

**名前は開発中のものです。** · 2009/10/24(土) 02:10:48

>>812
場合によるからその都度測るしかない
これだけ覚えておけ
な？人に聞く要素ないだろ？

**名前は開発中のものです。** · 2009/10/24(土) 11:36:54

>>813
なるほど・・その時にはよろ
>>814
頂点を共有しないバラバラの線分を多数書きます
>>815
うんまぁ、でも一般的にindex使ったほうが早いみたいだよね。
ＨＥＬＰにもindexがあればデバイスは内部でキャッシュを最適化するので
高速になります・・・みたいな事書いてあったし、ネット上の話題でも
index使っとけばＯＫみたいな常識があるように感じました。
その常識が線分的にはどうなのか、線分描画に通じている人がいたら
教えて欲しいと・・・

**名前は開発中のものです。** · 2009/10/24(土) 11:56:24

だからごちゃごちゃ書き込んでいる暇があるなら、
自分の条件設定通りのテストプログラムをとっとと作れ。
怠けようとするな。

**名前は開発中のものです。** · 2009/10/24(土) 12:12:16

>>816
だから色々そういう要素がありすぎてわかんねぇの
そういう要素同士がかちあったときにそれのどっちがより
その場面において早くなる要素となりうるのか？
っていうのは人間の脳みそで考えるより絶対にやったほうが早いの

**名前は開発中のものです。** · 2009/10/24(土) 14:56:33

>>816
頂点を共有しないバラバラの線分にindexを使っても意味がないだろう。
何のためにindexがあると思っているんだ。
頂点を再利用しなきゃ負荷が増えるだけだし、その頂点キャッシュも
16頂点分くらいしかないから、考えて並べないと意味がない。

**名前は開発中のものです。** · 2009/10/24(土) 17:15:26

>>819
>その頂点キャッシュも16頂点分くらいしかないから、考えて並べないと意味がない

なるほど・・indexバッフアァによるキャッシュの効率化って、そういう意味でしたか・・。
確かに重複する頂点がないとキャッシュの存在意義そのものがないですね。
良く分かりました。ありがとうございました。

**名前は開発中のものです。** · 2009/10/25(日) 15:30:56

すみません
複数のメッシュから、オンマウスしたメッシュ情報を表示する仕組みを作っているのですが、
その処理方式をどうすべきか悩んでいます。
１．普通に全対象をチェックして、ヒットした中から距離が最小の物を選ぶ
２．距離順にソートして１つヒットしたら処理を終了する

最初は２でやろうと思ったのですが、下手にソートした方が重い気がして来ました。
対象の数は多くてせいぜい200と言った所です。
１と２、どちらの方が良いでしょうか？

**名前は開発中のものです。** · 2009/10/25(日) 16:24:59

両方試して軽い方を利用すればいい。