09/09/18 00:15:40 sY/rjaFg
>>698
うｐしてみました。 URLﾘﾝｸ(www.dotup.org)
>>697
半透明アルファ（抜き用）を持ったテクスチャは
上記のうち Cutin-fg-Char.png（キャラクター画像） と Char.png（カットイン画像） の二つです。
なぜか一緒に半透明で表示されるカットイン背景などは、もともと完全に不透明です。
701:689
09/09/18 00:18:26 sY/rjaFg
誤記失礼。
× Cutin-fg-Char.png（キャラクター画像） と Char.png（カットイン画像） の二つ
○ Cutin-fg-Char.png（カットイン画像） と Char.png（キャラクター画像） の二つ
なんか長々とすみません。
702:名前は開発中のものです。
09/09/18 00:38:40 svVZT8ru
＞＞device_->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_ARGB(0x00, 0x00, 0x00, 0x00), 0, 0);
ここだな。
->Clear( 0, NULL, D3DCLEAR_TARGET && D3DCLEAR_ZBUFFER && D3DCLEAR_STENCIL, D3DCOLOR_ARGB(0xFF,0x00,0x00,0x00), 1.0f, 0 );
で、ステンシルは無視してくれ。俺はこれで半透明の表示で問題は出てないな。
703:名前は開発中のものです。
09/09/18 00:41:43 NpRsNZ/U
フラグのBit指定なのに&&はおかしいだろ
704:名前は開発中のものです。
09/09/18 01:04:28 svVZT8ru
そうなんだ。勉強になりました。ども。
->Clear( 0, NULL, D3DCLEAR_TARGET ｜ D3DCLEAR_ZBUFFER ｜ D3DCLEAR_STENCIL, D3DCOLOR_ARGB(0xFF,0x00,0x00,0x00), 1.0f, 0 );
これでいいよな。
705:名前は開発中のものです。
09/09/18 01:07:47 NpRsNZ/U
指定の仕方はあってるけどステンシルバッファと
Zバッファ作ってセットしてないとエラーで乙るぞソレ。
706:名前は開発中のものです。
09/09/18 01:21:18 svVZT8ru
ステンシルはいらねぇな。
->Clear( 0, NULL, D3DCLEAR_TARGET ｜ D3DCLEAR_ZBUFFER , D3DCOLOR_ARGB(0xFF,0x00,0x00,0x00), 1.0f, 0 );
これで、＞＞６８９も解決だ！直ったか？
707:名前は開発中のものです。
09/09/18 09:05:05 NpRsNZ/U
つかー画面のクリアとポリゴン描画の半透明はまったく関係ねぇとおもうぞ
708:名前は開発中のものです。
09/09/18 23:14:54 svVZT8ru
そうか。最初から考えよう。
アルファ値付きPNGとアルファ値なしの画像という点で考えると、
最初の意図した描画を実現するには、
もや画像だけアルファ値付きのPNGにする。
他は通常のPNGにする。
ドローでのカラー指定はすべて、D3DCOLOR_ARGB(0xFF,0xFF,0xFF,0xFF)にする。
こうすれば、意図通りになるはず。
抜き色は普通、（０，０，０）だよな。キャラクター矩形で透明にしたいところはこれで塗りつぶしておけばいいんだよね。
709:689
09/09/19 00:06:43 u6/AjfDD
昨日はありがとうございました。
あれからいろいろ試した結果、
・アルファチャネルのブレンディングを有効にし、
・不透明度が大きい方を結果のアルファ値とする
このように設定すると期待通りの動作になりました。
device_->SetRenderState(D3DRS_SEPARATEALPHABLENDENABLE, TRUE);
device_->SetRenderState(D3DRS_BLENDOPALPHA, D3DBLENDOP_MAX);
URLﾘﾝｸ(dl6.getuploader.com)
例のごとくわかりづらいですが、
「不透明なカットイン背景が半透明になって、全体背景の街が透けて見える」
という現象が無くなりました。
710:名前は開発中のものです。
09/09/19 00:50:01 FpikGG53
＞＞７０９
なんか、もやの白が強くなって不透明に見えてるだけだね。＞＞６９２の画像と
表示のされ方は変化してないように見える。
711:689
09/09/19 01:29:44 u6/AjfDD
ではものすごくわかりやすい例を。
旧 URLﾘﾝｸ(dl3.getuploader.com)
新 URLﾘﾝｸ(dl3.getuploader.com)
どちらもR50%, G50%, B50% の３つのテクスチャ（不透明）をこの順に
color = D3DCOLOR_ARGB(0xFF, 0xFF, 0xFF, 0xFF);
color = D3DCOLOR_ARGB(0xC0, 0xFF, 0xFF, 0xFF);
color = D3DCOLOR_ARGB(0x80, 0xFF, 0xFF, 0xFF);
でそれぞれ重ねたものです。
ソースはSetRenderStateの部分以外差異なしです。
新版では不透明（0xFF）で描画したR50%のテクスチャが
正しく不透明で表示されてるのがわかると思います。
712:名前は開発中のものです。
09/09/19 01:39:52 ujIvvLBv
つーか単にステート関連の設定をちゃんと理解してなかっただけじゃねえの
713:名前は開発中のものです。
09/09/19 08:02:04 k3VoAMfC
ちゃんと理解してたら質問にこないわな
お前本当にコミュニケ－ションとか理解できないじゃねえの
714:名前は開発中のものです。
09/09/19 08:29:04 FpikGG53
＞＞７１１
分かった。意図どおりになってよかったね。謎は残されたままだが。
旧タイプは重ねるごとに透明になってるのか、不思議だね。先に
不透明で描いてるのに後から重ねると透明になっていくという謎。
最終的に合成段階でピクセルの色が決められるから、そういうことも
できるのかね。加算合成？減算合成？
g_lpd3dDevice->SetRenderState(D3DRS_SRCBLEND,D3DBLEND_SRCALPHA);
g_lpd3dDevice->SetRenderState(D3DRS_DESTBLEND,D3DBLEND_INVSRCALPHA);
こうやって普通の半透明じゃ、旧タイプみたいに不思議状態にはならないよな。
謎だ。
715:名前は開発中のものです。
09/09/19 08:45:39 T/T+IHq2
っていうか、ID3DXSpriteの描画の為に
レンダーステートをいぢるっておかしくねーか？
何だかなー
716:名前は開発中のものです。
09/09/19 08:49:26 Wmk2Wipy
素直にD3DXSpriteを捨てるとか
717:名前は開発中のものです。
09/09/19 10:14:11 hPS4eY5I
D3DXSpriteなんて使ったこと無い。
あれ、いらないと思う。
718:名前は開発中のものです。
09/09/19 10:45:14 wVuVk5OI
すみません。
画像保管専用用のテクスチャから、表示用のテクスチャに一部画像を送りたくて
双方をLockRect()→FillMemory()→１ピクセルずつ転送
としようとしているのですが上手く行きません。
もしかして両方LockRect()する必要なんて無かったりしますか？
BMP→テクスチャなら正しく書き込めるんですが、テクスチャ同士の書き込みは初めてなもので・・ orz
719:名前は開発中のものです。
09/09/19 10:49:27 ujIvvLBv
なんでFillMemory?
システムのサーフェイスからVRAMサーフェイスへDMA転送するメソッドあるだろ。
720:名前は開発中のものです。
09/09/19 11:09:55 wVuVk5OI
FillMemory・・pBits Pitchの準備でもする関数と思い込んでた。全域書き込みだったのか・・。（´・ω・｀）
DMA転送の意味はググっておおよそわかったけど
システムのサーフェイス VRAMサーフェイス・・色々理解してない事が多い悪寒。
DirectX勉強続けるならこれくらい読んでおけ 的なWebや書籍あったら何か教えて下さい（・ω・｀）
721:名前は開発中のものです。
09/09/19 11:09:57 8SLts9QF
「ウマクイカナイ」という奴は、その言葉を発することで、
どれだけ解決を先送りにしているか理解していないんだろうな。
「ウマクイカナイ」と言えば、どうなってほしいのかという希望と、
現状が具体的にどうなっているのかということを説明した気になっているんだから。
722:名前は開発中のものです。
09/09/19 11:33:38 T/T+IHq2
Direct3D9は、日本語ヘルプだけ読んでればいいよ。
D3Dのみならず、3Dグラの基本を学ぶにはとても良い資料なんで。
まずはここを全ページ読む
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
723:名前は開発中のものです。
09/09/19 11:46:24 wVuVk5OI
>>722
ありがとうございます。早速読み始めました。
書籍でも一応学んだ部分も有るので、知らないワードはググりながら読み進めて行こうと思います（｀・ω・´）
724:名前は開発中のものです。
09/09/19 14:50:51 8FaGBwcO
ヘルプは細かい事を調べるにはいいけど、
一連の流れをつかみにくいから
DirectX実践プログラミング読みなよ。
事実上、これから始めるのがスタンダードだと思うんだけど。
725:名前は開発中のものです。
09/09/19 17:22:47 AvRxeaE8
helpが教科書
googleが先生
726:名前は開発中のものです。
09/09/20 10:01:57 3Ar764Br
Googleは実際はただの仲介業者で、Google含めたWeb全体が先生
727:名前は開発中のものです。
09/09/20 17:22:38 ZCm9dBJK
>>726
検索ヒットの末尾の方とか読まんだろ？
728:名前は開発中のものです。
09/09/20 19:11:34 X77D+Jte
いやいや、実際の学校の先生も仲介役だろう
先生を含めた世の中全体が先生って解釈もあるが
729:名前は開発中のものです。
09/09/20 21:48:19 c7TwYnTe
URLﾘﾝｸ(ranobe.com)
URLﾘﾝｸ(ranobe.com)
DirectInputの勉強をしています。一応、入力した値の取得は出来たのですが、
「アナログ→デジタル」に切り替えると、なぜか「-8」が入力され続けてしまいます。
これはどうしてでしょうか？
730:名前は開発中のものです。
09/09/20 23:27:42 r4ZVigLq
>>729
アナログは細かい誤差が出るのである程度遊びをもって入力処理するのが基本。
731:名前は開発中のものです。
09/09/21 00:39:52 4AGk9N1+
>>730
そうなんですね、ありがとうございます
732:名前は開発中のものです。
09/09/23 12:50:50 V8wqdYIK
すみませんテクスチャまわりについて２点の質問なのですが、
SetTexture関数を多用すると処理がどんどん重くなると聞き、
「連続して使う256x256のテクスチャ９枚」を切り替えまわるより
「連続ならば768x768(3個ｘ3個)のテクスチャ１枚にした方が早い」という意味だと思うのですが
テクスチャのサイズが上がると切り替えの負担は増えるのでしょうか？
(例えば途中で1/9枚だけアクセスしたくて切り替えると無駄に重い など)
あと、水面を表現する時は「フレーム毎に別のテクスチャ」を使って表現しようと思っているのですが、
滝など流動的なものを表現する場合、テクスチャは１枚のままで
「UV座標を操作する事で表現する」なんて出来れば負荷も下がり滑らかなアニメーションが出来るかも
と思うのですが、UV座標の操作(というか抜き取りと再設定)は非現実的だったりしますでしょうか？
733:名前は開発中のものです。
09/09/23 15:25:12 3gqevorR
やってみて遅かったら考えろ
734:名前は開発中のものです。
09/09/23 15:45:24 nTo6CkVE
ハード次第なとこもあるから全て実測って訳にもいかないのがあれだけどな
735:名前は開発中のものです。
09/09/23 16:11:35 m/YblDRh
昔のイメージだと256x256に出来るだけ収めて
それの切り替え回数を出来るだけ少ないようにするってのが速かったと思うんだが
今でも底辺に合わせるならそれなんじゃねーのかな
256x256にして切り替え回数をまったく減らせないのであれば大きい方1枚がいいんじゃね？
736:名前は開発中のものです。
09/09/23 18:37:56 6iJxx7kT
キャッシュに入っちゃったときとキャッシュで出し入れしてるかでも違うだろ
単純に切り替えて「ああ、そうか」とか結論を出すのも駄目
つまり、シーン毎にやってみるしかない
737:名前は開発中のものです。
09/09/25 15:12:54 jyLx60BE
>>733-736
色々と知らなかった事情も知れて勉強になりました。
テクスチャを展開する場所も重要な訳ですね。
ありがとうございます。
738:名前は開発中のものです。
09/09/25 21:50:39 CaKKOxxc
展開する場所？
739:名前は開発中のものです。
09/09/26 18:16:15 aslwUzky
>>732
UVを変化させて水流などを表現する方法は、昔から標準的に使われていますよ。
(UVスクロールなどと呼ばれています。)
単純な技法ゆえに、一枚板ポリゴン上でおこなった場合は見た目があまり面白くありません。
しかし、グラフィックデザイナーの手によるポリゴンの繋ぎ合わせ・重ね合わせの妙のおかげで、
かなり見映えのする川や炎の表現になります。
740:名前は開発中のものです。
09/09/27 01:34:23 V6ttYBA5
少し疑問があったので質問を。初心者ですいません。
皆さんテクスチャの画像形式は何を使っていますか？
今のところ最初読んだ本に従ってbmpを毎回dds形式に統一して読み込んでいるのですが、容量ばかり多くてメモリを喰うもので。。
ついでにddsファイルの利点も教えていただけるとありがたいです。
741:名前は開発中のものです。
09/09/27 03:23:24 gpJIcbqR
多少色の再現度が落ちてもいいテクスチャーはJPGにしてる。
742:名前は開発中のものです。
09/09/27 04:12:58 jhWyqA9G
ファイル形式変わっても、メモリを食う量は一緒じゃないの？
テクスチャ圧縮とか使うならともかく。
743:名前は開発中のものです。
09/09/27 05:12:13 +LiXIQ5c
しかも読み込みの時間も延びる（ほんのわずかだけど）
744:名前は開発中のものです。
09/09/27 10:38:58 syUY7XWv
DXT、ミップマップ、キューブマップ、アルファチャンネル
このへんの機能を使うならDDSオンリーになるとおもうんだけど。
745:名前は開発中のものです。
09/09/27 12:25:33 ErInkGhk
>740
今のところddsで問題無いからddsでやってる。
まあ、テクスチャ合計で10MBくらいだから大丈夫なんだけど。
でも、圧縮かけてメモリ上に置いておくと、描画の度に展開すると速度が
犠牲になりそう。
シーンごとに必要なテクスチャを分けておいて、シーソ移動ごとに必要なものだけ
展開してメモリに置いとくとかすれば良さそう。面倒になるけど。
746:名前は開発中のものです。
09/09/27 12:29:36 cIkrjluV
っつか普通そうするだろ
747:名前は開発中のものです。
09/09/27 14:50:35 syUY7XWv
そもそも今時のGPUがつんでるメモリ量を考えての発言なのだろうか・・・。
748:名前は開発中のものです。
09/09/27 15:09:16 gpJIcbqR
困ったことに「フリゲは非力なマシンで動いて当たり前」と考えてるユーザーは少なく無い。
749:名前は開発中のものです。
09/09/27 15:09:58 gpJIcbqR
（JPGはあくまで配布の都合なんで関係ないけど）
750:名前は開発中のものです。
09/09/27 15:18:47 hp5UHszX
WindowsMeで動かないんですけど？
751:名前は開発中のものです。
09/09/27 15:19:38 syUY7XWv
WindowsMEとかサポートするのはただのオナニーだろ
752:名前は開発中のものです。
09/09/27 15:25:52 hp5UHszX
URLﾘﾝｸ(ja.wikipedia.org)
フリーゲームや同人の現実
753:名前は開発中のものです。
09/09/27 15:50:21 YaqXlW2n
フリゲや同人全般だと非力なスペックで動くゲームが一番人気あるからな、
その層を対象にするから中々スペック上げるのは難しい。
にしてもさすがにVRAM32ぐらいあれば家庭用ゲーには比べ物にならないぐらい潤沢ではあると思う。
よくある新しいPCなのに重いってのはノートだったりオンボだったりするのが原因だが、
これらの場合でもVRAMだけは多く取れると思う。
754:名前は開発中のものです。
09/09/27 16:07:57 HWAanpbA
極限までのメモリ節約を考えないマはただの生ゴミ
755:名前は開発中のものです。
09/09/27 16:20:30 PoOE52xi
すみません
D3DXLoadMeshFromX で読み込んだＸファイルから
「法線情報」「頂点座標」「ＵＶ座標」「マテリアルNo」
にアクセス(読み書き)する方法
を解説しているサイトをどなたかご存知ではないでしょうか？
756:名前は開発中のものです。
09/09/27 16:36:43 syUY7XWv
>>754
節約するのとサポートが打ち切られているようなOSで
動くようにするのは話が違う。
757:名前は開発中のものです。
09/09/27 16:46:12 gs3GrlUZ
いやお前こそ何の話してるんだといいたい
ファイルの容量を上手く扱うための流れから勝手にズラしてるようにしか見えん
758:名前は開発中のものです。
09/09/27 17:15:04 6supplBE
あまりに非力なスペックまで相手にするのは不毛だと思う
759:名前は開発中のものです。
09/09/27 18:12:24 GCjoC8mm
内容の割に不自然に重いって感じさせなきゃいいんじゃね？
たいした事やってないのに、異様に重かったり
異常にハイスペックを要求したり、こういうのこそオナニーだよね。
760:名前は開発中のものです。
09/09/27 18:33:23 +LiXIQ5c
メッシュの頂点フォーマットを設定して頂点バッファを取得すればいい
マテリアルNoはたぶんアトリビュートテーブル
761:名前は開発中のものです。
09/09/27 18:34:46 +LiXIQ5c
あ、760は>>755へのレスです
762:740
09/09/27 19:28:26 V6ttYBA5
なるほど。参考になりました。
やはりメモリ量を増やさないよう地道に努力するほかなさそうですね。。
とりあえずはddsで進めていこうと思います。
メモリ消費量に見合う処理を実現させたいですね。
763:名前は開発中のものです。
09/09/27 20:05:19 sIMIl1Dj
DirectXがダウンロード出来なくなっちまったが、どうしたの？
764:名前は開発中のものです。
09/09/28 00:41:50 PJwvbzf0
DirectXは終了しました。あしからず
765:名前は開発中のものです。
09/09/28 10:24:06 moqSVWKN
ＤｉｒｅｃｔＸってなかなかインパクトや説得力があってイカす名前だよな
誰が考えたのか知らんけど
766:名前は開発中のものです。
09/09/28 13:18:55 XG0JgWN6
Xファイルはドラマだか未知の謎だかで
バッドネーミングかと
767:名前は開発中のものです。
09/09/28 13:27:20 1dxmQUI2
Directダメ、必ずデバイスドライバを通せってことだよな
768:名前は開発中のものです。
09/09/28 15:48:36 iNj0Bwp/
マイクロソフトのX好きはMSXの昔の頃かららしいよ
769:名前は開発中のものです。
09/09/28 15:53:43 kBbiwz2h
XWindow
770:名前は開発中のものです。
09/09/28 16:25:24 dKxmzM/8
XNA使ったらあれほど手が出なかったゲームループが一瞬でできました
771:名前は開発中のものです。
09/09/28 17:51:23 moqSVWKN
Xファイルからメッシュを読み込んでDirectional Lightで照らそうとしているのですが、
なぜかライトが反映されません。
アンビエントライトおよびDirectionLightのAmbient値だけは反映されますが、Diffuseはチュートリアル通りに設定しても適用されません。
ライトの方向が間違っているのかと思い、ためしにライトの方向ベクトルを回してみても変化がありませんでした。
何が悪いんでしょうか。
DXViewerでは正常にグローシェーディングで陰影がつく形で表示されました。
772:名前は開発中のものです。
09/09/28 18:53:02 AKxVarcw
Attenuation とかの値は設定したかい？
773:名前は開発中のものです。
09/09/28 18:55:49 xoHW67fY
>>771
そのｘファイルに法線ついてる？
法線無い場合はD3DXComputeNormalsとか使わないと駄目
774:名前は開発中のものです。
09/09/28 21:58:30 moqSVWKN
>>772
>>773
解決しました。
今回DXUTILのDXUTMeshクラスを初めて使ってみましたが、
SetFVＦだけでなくSetVertexDeclで頂点データを定義することを知りませんでした。
設定すると無事ライティングが機能しましたが、DXUTMeshを使っていたことを記述するべきでしたね。
すみませんでした。
775:名前は開発中のものです。
09/09/28 22:15:42 MVcbCkFc
>>760
ありがとうございます。情報を探してみます。
776:名前は開発中のものです。
09/09/28 22:45:30 iTnMmDRC
今現在、3Dオブジェクトとスプライトの２つの当たり判定を取りたいと思っています。
そこで3Dオブジェクトのワールド座標をスクリーン座標に変換したいのですが、そういう変換関数ありますか？
777:名前は開発中のものです。
09/09/28 23:17:59 RzfBxwC3
D3DXVec3Project
778:名前は開発中のものです。
09/09/29 00:44:24 dMyVg2nC
>>777
ありがとうございます。
なんとかさっきその関数を見つけることができ、実現することが出来ました。
779:755
09/09/29 17:40:07 jAN25eYD
すみません。
D3DXLoadMeshFromX関数 から頂点/法線/ﾏﾃﾘｱﾙ関連 の情報を取り出す為に
「ID3DXMesh インターフェイス」URLﾘﾝｸ(msdn.microsoft.com)
これを利用したいのですが
ID3DXMesh型の変数(？)を宣言しようとすると
＞'ID3DXMesh' : 抽象クラスをインスタンス化できません。
とゴッソリエラーと警告が出てしまいます。
D3DXLoadMeshFromX関数の第８引数に渡したLPD3DXMESH型では当然「ID3DXMesh インターフェイス」は
使う事が出来ないのですが・・・どうすれば良いのでしょうか。
私はどこら辺を勉強して来ればこの辺の仕組みが解るのでしょうか orz
780:名前は開発中のものです。
09/09/29 18:57:23 dqeDC0z0
インスタンスはポインタのアドレスを生成してくれる関数に渡してもらうんだよ。
781:755
09/09/30 03:34:42 Bg91gg+z
>>780
ありがとうございました。
すみません、メンバって言葉に反応してピリオドを使ったミスでした orz
すぐ下でOptimize()でアロー演算子使って動いてるのに気付かず；
失礼しました orz
782:名前は開発中のものです。
09/10/01 23:58:42 LIkPTtwl
すみません、3D地面とキャラクターの衝突判定についてなのですが、
距離計算(内積)と反映までは出来たのですが、
１．衝突判定の処理軽減(判定対象の絞込み)にはどういうパターンが有るのか？
２．頂点と法線 どちらで判定すべきなのか？
３．内側にめり込む事の回避方法（尖っているポリゴンの境目からや処理落ちで等の）
これらの疑問でどう作れば良いかイメージができず困っています。
基本地面を歩きまわる軽いアクションゲーなのですが、
定番の方法などが有れば教えて頂けると幸いです。
783:名前は開発中のものです。
09/10/02 00:11:29 xaTOFVmz
どういう地面かによるけど
当たり判定取りたいキャラの真下の高さを取得してそれと当たりを取るのが最低限だろう
784:名前は開発中のものです。
09/10/02 00:18:49 z1JLtZk6
>>782
絞込みには、そっちには4分木が有効だろう。ちょっと敷居は高いが。
URLﾘﾝｸ(marupeke296.com)
後は境界球の作成から始めればいいんじゃない？
785:名前は開発中のものです。
09/10/02 09:26:28 /niBMC9g
>>783
そうですね、今は数段階の判定対象の絞り込みで軽減をしてみようかと思います。
ありがとうございます。
>>784
ありがとうございます。4分木・・今はキツいですが、いずれは勉強して取り込みたいと思います。
＞境界球
なるほど。点じゃなくて立体で判定すればめり込み難そうですね。 試してみようと思います。
786:名前は開発中のものです。
09/10/07 22:53:27 1OGUvk7S
すみません
プレイヤーの数倍のサイズの敵への攻撃の衝突判定をする場合
１．円柱やボックスを大まかに中心座標から置いてそれを判定する
２．頂点数を減らした透明モデルを一緒に動かして、その面から外積(？)で判定する
この２つが思いつくのですが、
「低負担でそこそこの衝突判定」をする方法や理論が有れば助言頂けませんでしょうか？
787:名前は開発中のものです。
09/10/07 22:56:56 GxNoKgMb
当たり用の小さい球をたくさん敵につける
788:名前は開発中のものです。
09/10/07 23:06:45 1OGUvk7S
>>787
なるほど・・低負担でそこそこを楽に実現できそうですね。 ありがとうございましたっ
789:名前は開発中のものです。
09/10/12 14:26:14 puTlDpxR
WindowsへDirectX 9 と10を両方インストールして
場合に応じて切り替えることはできますか？
790:名前は開発中のものです。
09/10/12 16:22:18 hQMoF6vn
DirectXには下位互換があるんだから10をインストールすれば9も使える
791:名前は開発中のものです。
09/10/12 17:21:34 YdYmTdmP
それを言うなら上位互換
792:名前は開発中のものです。
09/10/12 21:22:38 rJ16+euJ
_ASSERT と assertって同じ？別物？
定義を見ると違うっぽいので違うのだろうけど、どう使い分けるの？
793:名前は開発中のものです。
09/10/12 21:34:24 AjxFbh57
>>789
そもそもOSに標準搭載されているのでインストールする必要性が無い。
794:名前は開発中のものです。
09/10/12 21:37:57 yXQZI7v6
>>789
SDKの話？
795:名前は開発中のものです。
09/10/18 10:52:06 lUEbzDrT
頂点ﾊﾞｯﾌｧをD3DPOOL_DEFAULT、
インデックスﾊﾞｯﾌｧをD3DPOOL_MANAGEDで描画して
私のビデオカードでは問題ないようですが、このようなﾊﾞｯﾌｧの運用は
一般的ですか？
796:名前は開発中のものです。
09/10/18 19:50:42 lUEbzDrT
普通だよね？
797:名前は開発中のものです。
09/10/18 19:56:21 gH5KDL3H
別に変なことじゃないだろ
798:名前は開発中のものです。
09/10/18 22:08:31 lUEbzDrT
>>797 thx
frequency設定して別ストリームから合成描画する
２つの頂点ﾊﾞｯﾌｧを別々の設定でプールしたら
バグッたんで、色々気になっていました。
799:名前は開発中のものです。
09/10/19 12:59:47 7jM4tM9s
すみません
DirectInputでマウスのボタン操作を取得してるんですが
「マウスボタンが押されっぱなし」の状態を安全(確実)に取得する特別な方法は有るでしょうか？
変数で操作の取得毎にフラグをひっくり返し続けるだけでも
大丈夫なものなんでしょうか？(外部ソフトの負荷で処理落ちして逆さになったりしないか怖くて・・)
800:名前は開発中のものです。
09/10/19 13:09:07 TPHZOR5g
マウスを扱うならWin32APIの方が確実
801:名前は開発中のものです。
09/10/19 13:34:42 7jM4tM9s
>>800
そうなんですね。ちょっと調べてみます。
ありがとうございました。
802:名前は開発中のものです。
09/10/19 16:46:13 ChZNl820
>>799
逆さになるって意味が分からんのだが。
ボタンが押されたときと離されたときで、異なる値になるんだが。
803:名前は開発中のものです。
09/10/19 21:14:06 qZo3qR1P
男女男男女ですね
ちがうわー
ってことだろ
804:名前は開発中のものです。
09/10/20 14:48:31 K18Q7LH0
嬲嫐か
805:名前は開発中のものです。
09/10/21 20:20:52 7NIJVQVY
表示された3Dモデルをクリックやオンマウスする事で
情報を表示できる様にしたいのですけれど、
・D3DXComputeBoundingBox()でバウンディングボックスを生成
・その各頂点からD3DXVec3Project()でカメラ(2D)座標にする
↑の方法で合ってるでしょうか？
D3DXComputeBoundingBox()が上手く行かず合ってるのか心配に。。
806:名前は開発中のものです。
09/10/21 22:39:00 c4Loyn9X
>>805
まあ、それで間違ってはいない。
でも俺なら、ワールド座標系で
レイを飛ばしてボックスと当たり判定をするな。
807:805
09/10/21 23:26:05 mh4+7PPm
>>806
合ってはいるんですね。ありがとうございます。
＞ワールド座標系で
＞レイを飛ばしてボックスと当たり判定
レイが何なのかわからず利用法がわかりませんが、
ベクトル計算を省けそうでこちらの方が軽く済みそうな予感がしますね・・。
ちょっと調べてみますが、少しヒントを頂けるとありがたいです。
808:名前は開発中のものです。
09/10/21 23:40:44 Hv8xs2nw
ヒント？ググレよ
809:805
09/10/21 23:48:28 mh4+7PPm
あー・・ググっててなんとなくおっしゃってる意味が解りました。
失礼しました。
やはりなるべく今の自分にできる程度の事でやった方が良さそうです；
ありがとうございました。