鬱だ氏のう DirectX (Part 15)

DirectXについて、にいさま達がマターリと
技術情報交換＆雑談するためのスレッド。
初心者用相談室では扱わないような少し高度な話題も受け持つ。

ちなみに、言語はC++がメイン。
C# / VB.NET 使いは、専用スレの方が話がスムーズに進むと思われ。

2

// 外部
- MSDN > DirectX
http://www.microsoft.com/japan/msdn/directx/default.asp
- DirectX Home Page
http://www.microsoft.com/japan/windows/directx/default.mspx

- DirectX Info Lib (デバイス情報のデータベース。すばらしい！)
ttp://www.netsphere.jp/dxinfo/
- BBX(掲示板)
ttp://isweb8.infoseek.co.jp/computer/bbx/
- spin
ttp://spin.s2c.ne.jp/
- 宇治社中改(3D基礎講座) のミラー
ttp://web.archive.org/web/20020607052151/http://www.cc.rim.or.jp/~devilman/

// 関連スレ
【C++】 DirectX初心者質問スレ 【C++】
http://pc5.2ch.net/test/read.cgi/tech/1084765853/
Managed DirectX vol.2
http://pc5.2ch.net/test/read.cgi/tech/1061285378/
- DirectShowと戦うスレ
http://pc5.2ch.net/test/read.cgi/tech/1026666092/
- Direct3D
http://pc5.2ch.net/test/read.cgi/tech/1011762546/
- OpenGL VS Direct3D
http://pc5.2ch.net/test/read.cgi/tech/1044308707/

DirectX総合スレ (Part2)
http://pc5.2ch.net/test/read.cgi/gamedev/1095863432/
Direct 3D
http://pc5.2ch.net/test/read.cgi/gamedev/1005293179/
２Ｄ！！のDirectXをやってみるかもな
http://pc5.2ch.net/test/read.cgi/gamedev/1005133911/
【Collision Detection】
http://pc5.2ch.net/test/read.cgi/gamedev/1015484028/
衝突力
http://pc5.2ch.net/test/read.cgi/gamedev/1012852070/
各種ライブラリ紹介スレ
http://pc5.2ch.net/test/read.cgi/gamedev/1008220559/

// 過去スレ
Part 1: http://piza2.2ch.net/tech/kako/966/966655286.html
Part 2: http://pc5.2ch.net/tech/kako/997/997101556.html
Part 3: http://game.2ch.net/gamedev/kako/1005/10051/1005119775.html
Part 4: http://game.2ch.net/gamedev/kako/1016/10162/1016276254.html
Part 5: http://pc5.2ch.net/gamedev/kako/1027/10273/1027351925.html
Part 6: http://pc5.2ch.net/gamedev/kako/1033/10339/1033920036.html
Part 7: http://pc5.2ch.net/gamedev/kako/1039/10395/1039509250.html
Part 8: http://pc5.2ch.net/gamedev/kako/1046/10466/1046676308.html
Part 9: http://pc5.2ch.net/tech/kako/1054/10545/1054553472.html
Part9.5:http://bbs.gamdev.org/test/read.cgi/gamedev/1054109966/
Part10: http://pc5.2ch.net/tech/kako/1061/10614/1061420660.html
Part11: http://pc5.2ch.net/test/read.cgi/tech/1069376986/ ※
Part12: http://pc5.2ch.net/test/read.cgi/tech/1076651336/
Part13: http://pc5.2ch.net/test/read.cgi/tech/1083313796/
Part14: http://pc5.2ch.net/test/read.cgi/tech/1088594869/
※「いや〜、ごめんなさい」により紛失っぽ

3Dエンジンの技術について語ろう
http://pc5.2ch.net/test/read.cgi/gamedev/1023414393/

祝！復活

>>1
乙

　　　　　　　。 ◇◎｡ｏ.:O☆οo.
　　　　　　　。:゜ ◎::O☆∧_∧☆｡∂:o゜
　　　　　　 ／。○。 ∂（*ﾟーﾟ ）O◇。☆
　　　　　／　　◎|￣￣∪￣∪￣￣￣|:◎:
　　　 ／　 　 ☆｡|..　　新スレおめ　　.|☆
　 ▼ 　 　 　 。○..ｉｏ.｡◇.☆＿＿＿＿| 。.:
∠▲―――――☆ :∂ｉo☆ ゜◎∂:.

DX9について質問です。
D3DXLoadMeshHierarchyFromX関数で読み込んだ、モーションつきXファイルの
FVFを変更することは、可能なんでしょうか？

普通のメッシュ操作のようにCloneMeshFVFみたいな関数があるのかと調べた
のですが無いようです。

スポーツ選手のメッシュに、TEXの項目を増やして、服のテクスチャと
背番号のテクスチャの２枚を描画したいと考えているんですが。

ID3DXMesh::CloneMeshFVF

>>10
無理っぽい気がする。
選手と背番号を別のXファイルにして
それぞれをレンダリングすればいいのでわ

>>1
乙

D3DXLoadMeshHierarchyFromXで読み込んだとき、
自前のID3DXAllocateHierarchyで、どこかにMeshをロードしたっしょ。
それをCloneMeshFVFで変えるだけかと。

sample通りなら、ルートフレームの子のフレームのメンバである
pMeshContainer内にあるはず。

と、即死回避レス。しかしこの板でスレ即死なんて本当にあるのかね。

座標a敵(x,y,z)から座標b自機(x,y,z)に弾を発射するとき
フレーム毎増加値（x,y,z)はどのように求めるのが一般的ですか？

>>15
そもそも弾はどういう軌道にしたいのよ？
発射したときから直線？
目標を追跡するホーミング？

>>15 書き忘れました直線です。

|b-a|*速度

18嘘。
(b-a)/|b-a|*速度にしようとしたの

>>16
>>19でいいかな（多分）
ベクトルがわからねぇと理解できない式だけど。ＯＫ？

間違え
Ｘ>>16
○>>17

レスサンクス
（b-a）を求めて例えば１０で割ったら１０フレーム後
に衝突するということ？
|b-a|が分からないから違うかもしれないけど。
|b-a|の意味を教えてください。

>> 22
// d = |b-a|
D3DXVECTOR3 d = b - a;
D3DXVec3Normalize(&d, &d);

じゃなくて
// d = |b-a|
float d = D3DXVec3Length(&D3DXVECTOR3(b - a));

>>23か、atan2でも使いたまえ。

>>22
やっぱりベクトルがわからねーと話にならねぇなｗ
図がないとおそらく説明は不可能。

これができないと他色々なことができなくなるから、ベクトルはどうしても覚えてほしいのよ。

>>19の式でやってることは、
弾を発射したときの自機の位置と敵の位置から、
自機から敵への「方向」を求めて、「速度」で掛けることによってスピードを調節している。

これはベクトルの知識無しで>>19の式を今ある知識で理解しようと思っても（多分）無理。（絶対とはいわんけど）

だから、ベクトルを勉強してくれないかな。

【努力しない質問厨】厨房王国BBX【素人に教えて自己満足厨】

BBXはもういいよ。そんなに気になるならヲチスレでも立ててくれ。

October 2004で何が変わったの？と話題を振ってみる。

ドキュメント、HLSL3.0、D3DX

ドキュメントは日本語があるといいな

前のが日本語化されてるから見比べればだいたいわかるかと。
ところでDirectInputを市販品レベルでまともに処理したいと思ってるんだけど
標準的な使い方ってどこぞで考えられてないのかな。

アクションマップもあんま使われてないみたいだし、全部のコントローラ網羅するのも
大変ダー。

PCでパッド重視してるのって、日本のゲームくらいしかないんじゃない。

DirectInputは放置プレイしようぜ。
トラブルの話しょっちゅう聞くし、アクションマッピングのジャンル分けも意味不明だし。

フォースフィードバックとか対応するのでなければ、普通にWin32 APIで読んで、
MAMEみたいにユーザに勝手にボタン割り当ててもらうのが一番良心的だろう。

あと、まともなPCゲーマーでPC用のコントローラ使ってるやついないよ。
ろくなコントローラないもん。通はUSB変換機でPS用コントローラを接続する。
変換機もクソな製品がかなりあるのでどっかの板にゴー。

ag

>>34
ゲーム機用のコントローラはアナログ軸が使い物にならん

PSのコントローラでばりばりPC版のFFXIをやっているが

ようは使いようなんだよね。バカ正直に渡される数値をまるまるそのまま使うとハマるのは目に見えてる。
というかDirectXでも無効範囲や渡される数値の範囲とか設定できるようになってる意味を考えないとね。

センターはしょうしょうぶれるから５％〜１０％は無効にしといたほうが無難だし、最大も９０％以上は同じ値として
使うようにしておけば思ったような操作ができるようになるかと。

DX 9b は一旦削除して（SDKも）、そのあとにDX 9c SDK（下のURL）のを入れるのがベストだよね？
http://www.microsoft.com/downloads/details.aspx?FamilyId=B7BC31FA-2DF1-44FD-95A4-C2555446AED4&displaylang=en

できればそう判断した理由を書いてくれるとみんなが参考にできると思う

DirectX3の頃からDirectXには理不尽な目に遭わされてきたので
もう何も考えずにそうしてます････

だったらHDDをフォーマットした後、
OSを再インストールしてから入れるのがベストだろう。
何を中途半端なことをしてベストなどとほざいているのだ？

2004octoberはサンプル少ないぞ、なんとかしてくれ
つーか、昔のサンプルも最新のSDKに移植してくれ
ヘルプも7.0時代のDirectXの概念から説明するようなのが無くなってるし
しかも古いヘルプはダウンロードできなくなってる

ビデオカードをRadeon9600XT に変えたのですが
DrawPrimitive関数やD3DXEFFECTのBeginPass関数で
CPUが激しくブロックされてしまいます。
交換前のGeForceFX5200では全くブロックされなかったのですが・・・
同じ症状で困っている人いませんか？
DX9.0ｃを使っています。

XPでDirectSoundを使用したプログラム作ってますが、どうもPlayしてから音が送れて
出ます。
どんな原因があってそうなるのか・・・不明なんで質問。
DirectX9.0です。

送れて出るのなら何の問題もないだろ。
送れなかった方がよっぽど困る。

ミス。
送れて→遅れて
です。

サウンドボードが骨董品（ヘルプにこの辺のことが書いてないか？）
音声データ自体に、先頭に無音部分がある
音声データをWAVEファイルから読み込むときに変な位置を指定した
音声データをバッファに書き込むときに変な位置を指定した

ありがとうございます。
なんとかやってみます。

ﾟ　　　　　　　　　　　　　／￣￣￣￣￣￣￣￣￣＼
　　　／ ￣/＼　　　　 | 　　　　　　 　緊急浮上！ |
｡　　|＿ ／＼　＼　　　＼＿＿　＿＿＿＿＿＿_／
　〃,|　 ＼　　＼./＼　　　　　 ∨
　　　|＿.　＼.／＼：　＼　　　　∠⌒∧　　　��
　〃：＼ ￣ ＼　　 ＼./　＼＿(´∀｀ ||）　　　|__|∴
　：　　　＼＿　＼　／＼　　＼￣＼ゝ) ）　／／∴∵
　　：　　〃＼ ￣ ＼　　：＼ /　＼　＼/／／　　∵　∴
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

>>43
Oct2004バージョンは前のサンプルないんですか？
入れようと思ったけどちょっとやめた。バックアップとらねば。
そういえば８→９のときも以前のサンプルなくなってたな。

↓を参考にがんがれ。
ttp://www.microsoft.com/japan/msdn/directx/japan/dx9/Update04.asp

素朴な疑問なんだけど、D3DXQuaternionSquad。
ヘルプでは球面二次補間となってるけど、これ球面三次補間
あるいは四次？じゃないのかなぁ。詳しい人どうなんでしょうか。

最大次数が2

>>54
三次と紹介している書籍があったので混乱してました
合ってましたか、ありがとうございます

なんかここ、めちゃくちゃペース遅いよね。

>>56
DirectX質問はDirectX初心者質問スレ・すれ立てるまでもない質問スレ
DirectShowはDirectShowスレ
Direct3DはDirect3Dスレ
細かく分かれてるから、あえてココで取り上げる話題が少ないんじゃない？

昔はここが一番盛り上がってたんだけどなぁ
往年のBBXより有用だった気が

つか今見たらDirect3Dスレも書き込み間隔が半月単位じゃねぇかｗ

んじゃ、DirectX初心者本として最適な書籍はありますか？
どれ見ても、なんだか中途半端な感じがしてならないのですが。。

と聞いてみたものの、総合スレで既に話題になってて
結論出てしまってるような・・・('A`)

DirectX9実践プログラミングが良いのな。

最近、エフェクトにテーマを絞った本がでててうれすぃ〜
こういうのは似たような本が同時期に出るけど裏で画策されてるの？

どうなんだろ？
むしろ、似たようなのがいっぱい出るより、色んなのが出る方が嬉しいけど

行列をコータニオンに変換する計算を教えてください。
軸と角度でもいいです。

＞コータニオン
コータ、あんたちょっとニオンわよ？

あまり面白くないね。

自己解決しました

定期age

December2004が出たのに、全然盛り上がってないな
どんな機能がついたか教えてくれよ
前計算済み放射輝度トランスファーは何となく分かったけど、俺には使えそうにないな…

また出たんかい。いろいろ忙しくてSummer 2004で一度もコンパイルしてねー。
つーか、なんかDirectXのアップデートの戦略変わったんか？

DirectX 9.0 SDK Update (December 2004) 日本語版リリースノート
http://www.microsoft.com/japan/msdn/directx/dxreadmej.asp

Photoshop Pro
このプラグインを Paintshop Pro 8 で使うとき、



？？？Photoshop Pro？？？

しかしあまりに見事な機械翻訳ぶりだ。

VC6の次はWindows2000切りか
XPなんか使いたくないな…

>>62
本の名前おせーてー。

http://www.amazon.co.jp/exec/obidos/ASIN/4777510581/qid=1103098683/sr=1-2/ref=sr_1_2_2/249-4111053-0505909
http://www.amazon.co.jp/exec/obidos/tg/detail/-/books/4839912475/249-4111053-0505909
このあたりじゃないか？

ありがとー

>>74
>>75ｿﾚﾀﾞ！
あとこれも。さらにあと1冊あったハズなんだけど名前わすれた。
DirectXゲームグラフィックスプログラミング Ver. 2.0
http://www.amazon.co.jp/exec/obidos/ASIN/4797329807


ついでに1冊オススメしていきます。入門者向け
本屋めぐりしてたら見かけたんだけどコレいい本だったよ
ゲームループの作り方等DirectXのAPIだけじゃない解説が萌え
説明が論理的で某社のような前後のつながりのない本に飽きた人はどぞー
古い本だけどこの時代は２ちゃんなかったよね？
http://www.amazon.co.jp/exec/obidos/ASIN/4894712601/

もう通信のサポートを辞めるってこと？


DirectPlay は不適切となり、旧式のものとみなされています。
DirectPlay ランタイム コンポーネントは、オペレーティング システムで
サポートされていますが、ヘッダー・ライブラリ・ドキュメントは将来の
リリースの SDK で削除されるでしょう。既存のアプリケーションを
修正するとき、このコンポーネントへの依存性を削除することを強く推奨します。

DirectX 9.0 SDK Update (December 2004) 日本語版リリースノート
http://www.microsoft.com/japan/msdn/directx/dxreadmej.asp

winsockのサンプル作って載せて欲しいね。つーか探せばいろいろあるか・・・。

GamDevPukiWiki - MMORPGを作ってみたい
http://gamdev.org/w/?%5B%5BMMORPG%A4%F2%BA%EE%A4%C3%A4%C6%A4%DF%A4%BF%A4%A4%5D%5D

ここの「MMORPG製作に使えそうな通信ライブラリ」に使えそうなのがいくつかある。
向こうのスレでレビューも出てた気がするけど・・・・MMORPGのスレが多すぎてどれかわからんｗｗｗ

頂点バッファってやっぱり、頂点インデックスと比して、
なるべく隣接していた方が描画が速いんですかね？

つまり頂点インデックスが
0 1 2 3 4 5 6
と
0 119 21 52 91 2
じゃ
前者の方がよかですか？

実験が下手で、ほとんど差がでないですよ。

何やっても変わらないなぁ、差はないのかな
どっちが速いというより、後者でも遅くならないって保証されるだけで嬉しいんですが

配列のランダムアクセスが、順番によって速度が変わるなんて
聞いたことないし大丈夫ですかねぇ

同じインデックス値が連続してるとかだと、また違うとは思いますが

>>80
結局どれがいいの？

>>82
確かキャッシュの中に入ってたら速度は変わらんかったと思う

>>84
ありがとうございます、どうも明確に結果の出ない事だと、一人じゃ不安で
これで隣接ランダムのままGo出せそうです

>>83
winsock

サーフェスへ文字を描画するやり方教えてください。
sf(サーフェス)->GetDC(&hdc);
hdc=BeginPaint(hwnd(ウィンドウ),&ps(PAINTSTRUCT));
TextOut(hdc,250,250,"hoge",strlen("hoge));
EndPaint(hwnd,&ps);
sf->ReleaseDC(hdc);
こうやっても何も出力されないんです。
と思ったら数回に一回なぜか出力されますが、peekmessageループの中で上のように書いて
時間経過で文字の出力位置が変わるようにしても全く文字が動かないのでやはりどこかおかしいようです。

サーフェースのDCを取ってるなら、それに描画してしまえばいいのでは？
BeginPaint とかの出番は無い気がするぞ。


つか、環境ぐらい書いとけや。
DirectXのバージョンが無ければ、
DxDrawなのか Dx3Dなのかもわからんし。

おっと

×サーフェース
○サーフェス

( ´,_ゝ｀)

>>89
サーフィス

どうでもいい

イエッサー

すみません、DirectX5のDirectDrawです。

sf->GetDC(&hdc);
TextOut(hdc,250,250,"hoge",lstrlen("hoge"));
sf->ReleaseDC(hdc);

ほんとだ、Begin&Endpaintって要らないんですね。

dxtex.exeやnVidiaのddsプラグインで、
R8G8B8でサイズ1x1のテクスチャをセーブするとヘッダ128バイト＋ピクセル3バイトの131バイトになります。
2x1や1x2でMIPMAPありにすると137バイトであり、ピッチが3バイト単位であることが分かります。
D3DXのテクスチャ関数もこの形式を正しく読めています。

しかし、DirectX9 Dec2004のヘルプを見ると、明らかに「ピッチの値は DWORD に整列する
必要があります」と書いてあり、あちこちの表もこの規則に則っています。

これは一体、「ヘルプには使われていない仕様が書かれてる」のか、
それとも他に何か理由があるんでしょうか

ファイル上の表現とDirectX APIたたくときの値をごっちゃにしてる？

RGB888が１バイトに収まるとおもってんの？

>>99
BMPファイルのようなDWORDアラインメントの話じゃないの？

読み込んだ関数がＤＷＯＲＤのピッチに合わせてくれてます。

DecemberってVC6サポートしてないのかよorz
2005早くでないかな

2005expressだとvc6で作ったlibファイルをリンクしたらなんかリンクできねー

仕方ないよ。貧乏人はいらないから

あけましておめでとう
今年も頑張って鬱になろう！

.NETの場合、DXAppwiz.awxはどこにコピーすればいいのですか？
古い説明しか見当たらず困ってます・・・。

ああすみません。DirectX8と.NETではテンプレート無理みたいですね。

新しいDirectX入れたらDLLも一緒に配布しないとダメなの？まんどくせー。

それは市販ソフトだけでいいだろ

イヤ、駄目なんだろ？　ReadMeまで見てないからよくわかんねーけど。
ランタイムの方のバージョン表記変えてくんねーと混乱する……。

ttp://www.microsoft.com/downloads/details.aspx?FamilyID=77960733-06E9-47BA-914A-844575031B81&displaylang=en
DirectX 9.0 SDK Update - (February 2005)

Sample Browser で Documentation を選ぶと英語版のヘルプが起動します。
日本語版を起動するようにするためにはどうすればいいですか？

>>112
http://pc5.2ch.net/test/read.cgi/tech/1101931660/

ここもそういうスレになったか_|￣|○

そういうスレ云々の前に、4ヶ月半で114レスってどうよ
かといって他スレが賑わっているわけでも無いんだよなぁ

２月号はWindowsXPじゃないとダウンロードできないというデマが流れている件について。

月刊誌かよｗ

Oh! Xみたいに季刊

D3DXがDLL化してユーザーに要求するのに
本体のバージョンは9.0cのままだから、
ユーザーに最新版のインストールをスキップされそうだね。

もうそろそろ 9.1 としてリリースしてほしいなぁ…
と思ってみる。

SoftImageのファンクションカーブをゲームで再生してるんだけど
モーションデータを圧縮するいい方法ない？
キーの数自体は少ないんだけどtime,value,lslope,rslopeをそのまま出して
３軸分のカーブを再生ってのをもっと効率化したい。
何か近似式を使うのもいいだろうけど誤差は極力小さくしたい。

キーの値をADPCMにするとか
あとGems3になんかそんなテーマが載ってたが立ち読みなんでよく覚えてない

>>120
以降、SDKは9.xxで終わりなんだから、今9.1出したら今後困るでしょ。

>>120
9.1は出さないとどこかで言ってたような……。

そういえばOh!Xは完全に死んだとですか。

ものすご基本的な質問で申し訳ないのですが、
今ダウンロード出来る、DirectX9.0c SDKを使用して
DirectX7.0の関数等は使用可能ですか？

VB6.0で、ちょっぴりいぢってみたくて・・

>>122
情報サンクス。Gems3かぁ。アキバ探せばあるかなぁ。

>>126
VBはどうだろ・・・パラメータの数が変わってエラーかも？

何のためのQueryInterfaceなんだか

DirectX9になってからいくつもバージョンがあるみたいだけど、
遊ぶ人（開発しない人）ってどのくらいのバージョンいれてんだろうね。
WindowsXPでは標準で8.1が入ってるらしいから未だにそれを基準に作ってるけど……
皆さんどうですカ？

>>130
>Yea, DX9.x Hardware-Shader is Human-Sacrifice :)
( :D )

>>130
そんな事気にするならOpenGL使え。
いまやDirectXより高速らしいしな。

>131
( :D )|￣|＿

>132
なるほどそういう選択肢もあるのね。
ちょっと勉強してみます、ありがとう。

#どういう条件で「高速」になるんだろうか…ｗ

>>132
Windows95時代からOpenGL(miniGL含)のほうが高速なんだがいつ逆転されたんだ？
DirectX8でほとんど差はなくなったが……。

プログラムの内容やドライバの出来次第でいくらでも状況が変わるのに、
前提条件を明示せず、どちらの方が高速とか逆転とか、
いったい何を考えてそういう発言が出来るんだろう？

というか実行環境気にしたくないならOpenGL使えってのが、そもそもおかしいような
ある意味DirectX以上にシビアだ

ある意味って？

OpenGLはDirectX以上にビデオカードのドライバによって使える機能がまちまち。
たとえばDirectXのようにソフトウェアで頂点シェーダを実行するとかできない。

あまり特別な事しなければOpenGLのほうがよっぽど動く環境多いのだが。
それからLonghornになったらDirectX載らないから今からOpenGLってのは
悪くない。もしWinXPユーザーターゲットなら8.1と言わずに9.0でいいだろ。

動けばいいってもんでもなかろうに。

>>139
そりゃDirectXだって5や6なら、よっぽど動く環境多いわな

5や6はもう無理だろ。

>>142
っ[ 上位互換 ]

>>139
名前がDirectXじゃ無くなるだけでLonghornにも乗るって。
あと今だとDirectX APIのオーバーヘッドはOpenGLよりだいぶ酷いが
>・ユーザーモードで動作するLonghornのドライバモデルの導入により、
>描画コールのオーバーヘッドを減らす。Direct3D9の場合の10分の1を目標。
らしいんで期待しましょう。

>名前がDirectXじゃ無くなるだけでLonghornにも乗るって。

じゃあDirectX8.1で作られたソフトは動くのか？
3DAPIならWGFってみんな知ってるけどそれはDirectXじゃないだろ。
いまからDirectX覚えても意味ねぇーよ。

動かなくなるとは考えにくい

>>145
もちろんLonghorn上でDirectX/OpenGLどっちも動くよ。
というか動かなかったら大変だよ。

ならDirectXとWGFの2つのAPIが載るのか?
ドライバ的にはWGFでDirectXのサポートは無理だろ。
というか>>147の自信満々の根拠は?関係者?

WinHEC2004のスライドで既存のDirectX/OpenGLのサポートと
次バージョンのDirect3DとしてWGFが載ることが明言されてる。
逆になんで動かないと思うのか知りたいよ。
既存のDirectXソフトが一切動かないOSなんてユーザーが乗換えないだろ。

以下それの抜粋
>Legacy API Support
>All legacy DirectX Graphics APIs fully supported
>And will continue to be hardware accelerated

>OpenGL
>Continue OpenGL support

>Windows Graphics Foundation
>WGF is the “next Direct3D”

DirectX3を使ったゲームが、
DirectX9をインストールしたWin2000上で
普通に動く訳ですが…

何で下のバージョンが動かなくなるって思うんじゃろ…。

釣りなのかなぁ…

DirectXが分からなかったから学ぶ意味がないと
思いたいだけなんだよ

ゲ製作技術板はOpenGL派が多いな。
元々3Dが皆無だから誤差だろうが。

OpenGLってグラフィックライブラリだから音楽とか入力とかはできないよ☆

DirectMusicは使い物にならんしDirectInputはマウスやキーボードで使う意味ないし。

>>151
認知的不協和の心理ってやつだね。

そもそもMSがどれほど互換性の維持にリソースを割いてるかは
某氏の日記でも紹介されているところだが。

>>153-154
そこでOpenALですよ。

OpenGL+SDLがメジャーじゃね？

日本の同人やフリーゲームだとほとんどDirectXだよ。
自分のHDDでは検索したらKenta Cho氏の一連の作品しかなかった。
技術デモの類は別なんだけどね。

つまり、ゲ製でOpenGLって言ってる奴は口だけ野郎。

市販ゲームもほとんどDirectX、エロゲーはGDIしか使ってないのもけっこうあるけど。

>>155
某氏の日記ってどこ？

>>159
ここぢゃないかな。
ttp://www.radiumsoftware.com/diary.html

>>160
最後の「Microsoft 製品の品質の高さ」にわらた

M$とか書かれまくってた時代はともかく、ここ数年は普通に高いと思うんだけど。
ユーザがどう思ってるのかは知らんが。

DirectX9で立体的な文字を表現したいのですが、
ステータスみたいな画面側に張り付いたような、
２Ｄの文字についてしかサンプルが見つかりません。
立体的な文字の表現をするにはどんな関数を使うんでしょうか？

D3DXCreateText
あるいはGetGlyphOutlineでパス取得して自分でポリゴン化

>163
文字を貼り付けたポリゴンを
少しずつ奥から手前にずらしながら
たくさん表示する

>>157
うん、だってうごかねぇもん＞ＯｐｅｎＧＬ
マジでマジでマジで。
うごかねぇもん。
やってみて損した俺が言ってんだから間違いないよ。

>>165
それ(・∀・)ｲｲﾈ!!

>167
さらに各ポリゴンを少しずつ縦とか横にずらして波打たせりするのもあり

>>166
ひょっとしてATI使ってないか。ｗ

>166
glut.dllがないのにglutを使ってたんだろ

>>166
ほとんどの3DCGツールはOpenGLとDirectXの両対応を実現してる。
つまりおまいがバカ

>>171
3DCGツールなんてリアルタイムでうごかねーし、
機能使えなかったら使わなきゃいいんだから対応自体は楽なんだよ。
だいたいRadeon9600だってロクな機能使えないじゃん。
俺が設定の仕方を知らないのかデフォでそれなりにやってくれる機能が無いのか
それとも本当にリアルタイムで使えないのか知らないけど、
ＣＧツールって基本はショボイ動作しかしないじゃん。
ちなみに俺の会社のＰＣにはライトウェーブ、ソフトイマージ、３ＤＳＭＡＸ、ＭＡＹＡが全て入ってる。
でも、使い方知らないし宝の持ち腐れｗ

全角英数字を使うやつは放置の方向で。

>>173
うはｗｗｗｗおｋｗｗｗｗ

ｗｗｗｗ
↑
厨房の証

ゲームを作りたいのですがＤｉｒｅｃｔＸが入りません。
どうしたらいいですか

>>176
まずパソコンを買いましょう。Windowsというのが載ってるやつを買えばDirectXは
入っています。

http://www.theinquirer.net/?article=21409

NV40の次はG70?

ふと思ったんですけど、Present 時に WM_PAINT が発行されないことって保障されてますか？

そんな保証はどこにもない。

GF6600GTなんですが、サンプルのSkinned Meshで、
Vertex ProcessingがD3DCREATE_MIXED_VERTEXPROCESSINGだと、
明らかに、頂点演算の異常でポリゴンが時々チラつくんだけど、
そんな事無い？
ハードウェアモードやソフトウェアモードだとチラつかない。

FF11でもポリゴンがチラついてる。

うちのGF6600GTが壊れてるのかなー
ドライバは色んなバージョン試したけど変わらず・・・

Mixed使わなきゃいい。
ハードとソフトだけで十分だろ。
Skinningはシェーダでやれ。ポイントスプライトいらねえし。

MIXEDの利点ってなんだっけ？

ハードじゃ対応してない部分をソフトでやってくれるってやつじゃなかったか？

シェーダで書くとファイルが増えてイヤなんだよなー
ソースに埋め込むと見えちゃうし。
それに一昔前のGPUだとFPSが激しく落ちる

ふーん

http://pc5.2ch.net/test/read.cgi/gamedev/1018255106/l50
スゲー物理デモ登場

Direct3D.Font.DrawText でスプライトに描画した後、Flash() しないと
以降そのスプライトでの Draw2D がうまく動かないのって有名なことなんですか？

D3DXSprite使ったこと無いので分からんが
みんな妙なところでつまづくんだな。
スプライトクラスくらいなら、いっそのこと自分で作っちまえばといつも思う。

車輪の再発明

だから車輪という程のものかっての
ただのカメラ方向を向く４頂点に過ぎないだろ

この場合は頂点じゃない。
クラスの内部の実装を想像できない奴が泣きを見るという、よくある落とし穴さ

191とかそれっぽいな

普通にviewの逆行列をかけるのは・・・・メンドイですか。

まぁ使う人だっているんだし、>>188みたいな情報は貴重だろ。ケチ付けることは無い。

ちなみにスプライトの自前実装ってどんなのがあるんだろ。
・TLVertexを使う
・ビルボードにする(viewの逆行列をかける)
・スプライト描画時のみviewを(例えばXY平面向きになるように)調整する
くらい？

ふつうは行列掛けた後のスクリーン座標をぐりぐりするVertexShader書かないか？

3Dが必要なければ
普通はトランスフォーム済みの頂点使うだろ。

意見が分かれまくりだなｗ

トランスフォーム済みは、ターゲットバッファからはみ出したときに
描画される保証がないので、自分でクリップするのが面倒くさくて使えない。
Matrox系なんかでは、はみ出した場合、見事に表示されなくなる。

>199
何かその書き方だとMatrox全般みたいに聞こえるけど
古いものとかじゃないの？
最近のでもそうなの？
トランスフォーム済み頂点といってもシェーダ使えば
普通の頂点もトランスフォーム済み頂点も扱いは
最終的には変わらないから、シェーダつかっても
クリッピングが保障されなかったらトランスフォーム済みとか
関係なくクリッピングに問題があることになるけど、どうなの？
それともシェーダ使えばＯＫで固定機能の場合だけ問題あるとか？
とりあえずそのカキコだけでは納得できない
詳しい状況plz

Matroxで3Dやったことないから知らんけど、クリッピングも自分でやるビデオカードなんて
いくらなんでも使い物にならんだろう。
トランスフォーム済み頂点を直接渡すときだけの制約じゃない？

WGFで全部解決ですかね。

WGFは昔のグラフィックカード切り捨てだからね

わざわざ、答えられませんってレスをつける意味があるのかね

Game Developers Conference 2005現地レポート
LonghornのグラフィックサブシステムはWGF1.0と2.0からなる
〜テッセレータ導入はキャンセルに〜

http://www.watch.impress.co.jp/game/docs/20050308/wgf.htm

Matroxなんて持って無いから実験できんけど、
D3DFVF_XYZRHWじゃなくて、
D3DFVF_XYZWでも使ったんじゃないかな。

MSの伝統通り、使えるのはVer3からってことでMSからVerをあわせてくるよ。
つまり製品出荷時にはWGF3.0がサポートｗ

・Matroxを切り捨てる
・D3DFVF_XYZRHWを使わない
・はみ出さない
選択肢は上記のいずれか。

つか、皆 Matrox 持ってないんだな…。

うちはG450を持ってはいるけど…押入れの中で眠ってら。

ジオメトリシェーダなんて作る前に
統一してください>MS

→・D3DFVF_XYZRHWを使わない
逆。
D3DFVF_XYZWがクリッパースキップ。

あ、トランスフォーム済みを使わないって意味かな・・・

でも、HTnL以前は
ゲームソフト側でジオメトリ変換するのも普通だったし、
本当にMatroxはクリッピング駄目なのかね。

俺のスプライトはSurfaceLockして直接ｶｷｺ。
あはははははｈ鬱死んでくる

ここ２，３年のCPUだと、DirectX7以前では
もうスプライトもシステムメモリのバッファに書いてから全体をブロック転送しかないんじゃない。

GeForceFX以降、D3DCAPS9のMaxVertexBlendMatrixIndexの値が0になってるけど、
これって本当にサポートしてないって意味なんでしょうか？

インデックス付き頂点ブレンディングが使えないとなると
スキニングを分割しなくちゃいけないので面倒・・・

張り忘れ
http://www.netsphere.jp/dxinfo/query.asp?source=gr_90_caps

追加で質問。
こういった問題を回避するためには
スキニングは自前で計算するのって常套手段でしょうか。

シェーダを使えばその値は無関係だし、
固定機能を使うにしても、アクセラレーションが得られないだけで、
何故自前という話になるのか意味不明。

>217
ありがと。この数字って固定頂点機能の制限だったのね。

久々にDirectX SDKのバージョンうｐでもしようかと思ったら
最新版VC++6.0対応してないし

MSすざけんな

Win2000にも対応していませんわよ奥様

VC6使いはDX8でちんたら作っているのか
既に切り捨てて.netな世界に逝ってしまったのか。

未だにVC6使ってるってことは新しいものが嫌い、または古いのが好きなんでしょ。
そんな香具師はSDKも古いのを使っとけばいいじゃないかと思うのだが。

最近のＣＰＵなら、アルファブレンディングもｎ角形ポリゴン描画も実用的な速度で動くから
ダイレクトＸ９なんか使わなくてもハーフライブ２くらい作れるよ。
ライティング光源数なんか６５５３６いける。

金がないだけじゃｺﾝﾁｸｼｮｳ!!

アルファブレンディングやＮ角ポリゴンを動かしてる程度で「実用的」とか
「ＨＬ２くらい作れる」とか言うなよ（プ
せめてスキニングとダイナミクス、ハーフシャドウを実装してから家。

>>224
ｽﾏﾝｶｯﾀ

>>225
熱くなんな、ほっとけよ
「ライティング光源」とかどー見てもド素人じゃないか

>>225
作れるのはHL2じゃなくてハーフライブ２なんだろ。

どうみても釣りだからスルーしてたのに・

OpenGLなら、VC6でも行けるんだろうか

>>230
いける

OpenGLはDirectXと違っていろんな環境で使えます。
携帯やゲーム機もOpenGLの独占状態です。

そうなのか、二人ともサンクスです

それなら弄ってみたいなぁ。でもなんだか色々細分化されている
イメージで取っつきづらいんだよなぁ…シェーダとか＞OpenGL

一部のDXライブラリから離れられないって言うのもあるけど

OpenGL+Cgとやらを触ってみたけど
…つくづくDirectXは親切だな

>234
激しく同意。
反発多いかもしれんけど。

>>221
「DirectX 9.0 SDK Update - (Summer 2003)」までなら対応してるからそれ使ってる。

>>222
いや、欲しいけど高い訳よ。

>>236
> いや、欲しいけど高い訳よ。

Visual C++.NET Standard 2003 って１万６千円くらいでしょ？
高いと言われちゃしょうがないけど VC6 を買った人の言葉とは思えないんだよなぁ。

7万ぐらいしたけど今は安いのかな？

そんなあなたに
Microsoft Visual C++ Toolkit 2003 質問箱
http://pc8.2ch.net/test/read.cgi/tech/1109618655/l50

>>237
最適化かけられないじゃん。

VC++だけでいいのに変なもんつけないと買えないし、
.netとかすげぇびみょ〜って思ってここまで来ちゃったし
2005でるまでがまんがまん。

直前の書き込みぐらい嫁。
Std版に上書きすれば最適化も可能になる。

vctkってでたの去年だろ
それを見越してStd版買った奴いるのか？

今の話をしているのに何故去年云々の話が出てくる？

>>240
自分の作ったアプリのどこにどうやってどのくらいの最適化がほどこされるのかも知らずに
最適化が無いから嫌って、１００００００ぺんぐらい死んだほうがいいと思うよ。

たぶん244も言うほどは知らないだろうなと、全角数字を見ながらなんとなく

最適化が無いから嫌って、1048576ぺんぐらい死んだほうがいいと思うよ。

スタンダードなんて使ったことないから気持ちがわからん。
だいたい貧乏ならバイトでもしろ

ところでID3DXLineのアンチエリアシングってどうやってるんだろ…
真似てテクスチャ作ってポリラインストリップの描画しても
あんなに綺麗に映らんorz

Visual Studioで新規プロジェクト作ったら、まずアセンブリの出力をオンにするのが通
しないやつはシロウト

また馬鹿がわいてる。

>>248
あれは24bitグレースケールでやってる

1人1回しか死ねないだろ

おい、まだ4月じゃないだろ・・・

明日リリースしたら、誰も信じないからだろう

ゲイツに翻弄されっぱなしの今日この頃、皆様いかがお過ごしでしょうか。

DirectX 9.0d(April 2005)

＞Microsoft DirectPlay は不適切となっており、新しいアプリケーションを開発する際それを使わないことを、
＞Microsoft は強く推奨します。その代わり、拡張された Microsoft Windows ネットワーク テクノロジを、ゲーム開発者は使うべきです。

この「拡張された Microsoft Windows ネットワーク テクノロジ」ってなに？

>>257
winsock

レスのない>>258の為にage

>>249
どこでオンにできるのですか？

プロジェクトのプロパティ、C/C++ > 出力ファイル のアセンブリの出力を/FAcsにしたまえ。
.objファイルと一緒にアセンブリャーコードを出力してくれるようになる。

>>257-259
WindowsNTのことだろ？

あれ、ゲ製板のDirectXスレ落ちた？
総合スレが落ちる程度の勢いなのか・・・

>>263
無事1000までいきました
誰か次スレ・・・といってる間に

>>264
勘違いだったか、ありがとん
立てても良いけど、ログないからテンプレわからないや…

>>265
DirectX総合スレ (Part3)
http://makimo.to/2ch/pc8_gamedev/1105/1105333209.html

>>266
俺の予想に反して、Apacheのドキュメントが見えている件について

俺の予想に反して、次はＭａｙ２００５

>>265
テンプレ、過去ログはここで見られる

GamDevPukiWiki - DirectX総合スレ
http://gamdev.org/w/?%5B%5BDirectX%C1%ED%B9%E7%A5%B9%A5%EC%5D%5D

最新のＳＤＫに MFCFog サンプルが含まれていないってのは
ＭＦＣとの共存にはやっぱいろいろと問題あるってことすかね。

>>270
つか、たかがFogにあんなサンプルいらんｗ
ビジュアル的におもしろいものか本当にサンプルの役割をはたしてくれるものか
どっちかにしぼれよって感じのツッコミくらったんじゃねぇの？

Fog のサンプルって何がやりたかったんだろうな
付属のヘルプの方が簡潔にまとまってて100倍分かりやすい感じだったし

シェーダでいろんなフォグの実装と紹介で何種類も出せば初心者には十分有益だが

今日びのゲームは、遠景(空とか)もしっかり描かれてるから
特定の色へしか補間できないハードウェアフォグでは
うまく馴染ませにくい希ガス。

>>274
へー（´･∀･`）
じゃあ君のやり方どんなん？

>>274じゃないが、
フォグの色のアルファを０にするとか。現実じゃありえないけどね。

ドラクエ８の船とかラーミアのシーンみたいな。

へー（´･∀･`）

Reset したら DrawPrimitive が失敗する...というバグに悩まされていたが、
単に FVF を再設定し忘れてただけというアホなミスだった...　orz

開発ツールでDirect3Dを使ってます。
ツールバーにカーソルを乗せてツールチップを出だけでとフレームレートが極端に落ちます。(7FPSくらい)
メインのOnPaintのタイミングで描画、BeginScene〜EndSceneの間なにも描画せずに普段は75FPSです。
解決法ありますか？

すごい開発ツールですな

理解不能

>>279
MFCつかってっからだ。

ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと

もういいよバカどもめ。
DirectX Mailing List Archiveの"Layered windows and full-scene antialiasing"によると
XPでマルチサンプルだと起こるってさ。

レスのない>>284のためにage

このスレの話題でいいのか微妙ですが、
nVidia SLIたんとDirectXプログラムについて気になったことがあるので、教えてエロイ人。

1.
「計算量の多いピクセルシェーダを使って、それなりに広い範囲への描画を行う
（=ピクセル数が多く、しかもそれぞれのピクセルでのシェーダ演算量が多い）」
なんて場合、SLIを使っていると高速化されやすいんでしょうか？
SLIによってシェーダユニット数が増えた状態になると考えると、
かなり高速化されやすい問題だと思うんですが、どうなんでしょう？

2.
SLIをOFFにした状態だと、DirectX Graphicsから二枚のビデオカードをちゃんと弄れるんでしょうか？
CreateDeviceの第一引数をちゃんといじってやれば、
それぞれのビデオカードを個別にコントロールできるような気がするけど、どうなんですかね？

SLIなマシンを持っていればさくっと実験できるんですが、
持っていないのでわかりません。

そもそもPCI Expressなんてものがあることすら知らなかった。
俺に説明は不可能。
AGPも無くなるのか・・・。

エロイ人パス。

昨日ふと思ったんだけど、>>188 の原因は DrawString or スプライトじゃなくて更新のタイミングだったのかも……

わるい。今回 Font.DrawString 使ってなかったから全然違ってたみたい。
っていうか MDX は微妙にスレ違いな気分ですが勘弁です m(_ _;)m

======

// TextMetrics はココで取得しておく
Graphics g = owner.CreateGraphics();
IntPtr hdc = g.GetHdc();
IntPtr hFont = font.ToHfont();
IntPtr bHObj = NativeFunction.SelectObject(hdc, hFont);
NativeFunction.GetTextMetrics(hdc, ref tm);
NativeFunction.SelectObject(hdc, bHObj);
NativeFunction.DeleteObject(hFont);
g.ReleaseHdc(hdc);
g.Dispose();

======

今回のは、Device.BeginScene 〜 EndScene の間、Sprite.Draw2D の直前に↑が入っていると起きました
…… これから家帰ったら、詳しい原因調べときます

判明

Graphics g = owner.CreateGraphics(); 
NativeFunction.GetTextMetrics(hdc, ref tm); 
g.Dispose(); 

この３行のコメントアウトで正常動作

……大本の原因、やっぱり判らんから、とりあえず描画に直接関わる物以外は
BeginScene 〜 EndScene 外で行うようにするよ

スレ汚しｽﾏｿ

CreateAdditionalSwapChainでフルスクリーンとウィンドウを共存させる事は不可能？
D3DERR_INVALIDCALLで作成失敗してしまいます。

ヘルプ見ると、
「どのようなデバイスでも、サポートできるフルスクリーン スワップ チェーンは 1 つだけである。」
と書いてあるが、これはフルスクリーン一つとウィンドウでも駄目って事かな・・・。


具体的には、ツール用途でスワップチェーンを使った複数のウィンドウを表示して、
ゲーム開始時にだけフルスクリーンに切り替えたいのですが、
この場合はデバイスを作り直すしか無いのでしょうか？

>>291
フルスクリーンとウィンドウェドの共存は無理。

そのルーティンなら、ゲーム開始時には
それまでのスワップチェーンを全て開放したあと、
フルスクリーン用のパラメータでデバイスをリセットするべし。

D3DXUVAtlasCreateのサンプルってどこかにない？ ぐぐってもでないよ

SetDisplayModeで解像度を変更し、アプリケーションを終了すると
デスクトップに最大化しておいておいたプログラムのWindowが
SetDisplayModeで変更した大きさになったままになってしまいます。
さらに一度それを最小化してもとにもどしてみるとタスクバーを無視して
(つまりWindowの枠がタスクバーの下まで入り込む)広がってしまいます。

一応googleで検索してはみたものの解決策は見つかりませんでした。
解決策があれば教えてください。

GetWindowPlacement

はぁ？それだけじゃわかるわけないだろ。
小学生の時習わなかったか？
単語を言うだけじゃ会話は成立しねぇの。

ものすごい悪質な悪戯を思いつきました
http://etc3.2ch.net/test/read.cgi/entrance/1116269436/

>>295
つまりどうしようもないと…

EnumWindows()？

つまり起動時に全部Windowを列挙して状態を保存して
終了時に全部元に戻せと？

それで何か不都合があるのか？

>>300
難しそうに聞こえるかも知れんが、結構簡単に書けるよ。
ちょっとつまづくのは、ディスプレイには表示されていないけど
内部ではハンドルだけ存在するように見えるウィンドウがかなりあるから、
そいつらをどうやってふるい落とすか、くらいかな。

>>295とか>>299のキーワードで少し調査すれば資料はまあまあ見つかるからがんばれ。

>>301
いや特に不都合は無いけれどDirectXさんが
勝手にやってくれないのかなぁと思っただけです。

>>302
thx。適当に調べてやってみます。

http://www.sankei.co.jp/news/050523/kei085.htm

以前このスレで冗談扱いされたDirectSmellが
とうとう現実となるのか？ｗ

ウンコの匂いを出すウィルスとかできそうだな。

SPAMスメル

>>305-306
以前話題になったときと全く同じ反応の仕方だな
このｽﾚ住人の視野の狭さが覗えるよ

実は中の人が同じだったとか

>>307
以前話題になったときと全く同じ反応の仕方だな
このｽﾚ住人の視野の狭さが覗えるよ

AddDirtyRect……なんとなくｶｯｺｲｲ感じがした漏れは病んでるのだろうか……
なんに使うのかは知らないが

>>305
次は　DirectTaste である、に一票。

DirectX9のテクスチャーの使い方に関して質問します。USAGE, FVF(Format), POOLの指定の中で、特に POOL(メモリクラス)
に関して、xx_MANAGED(管理してもらえるテクスチャ) と、xx_DEFAULT(動的!)
をよく使うPOOLとして指定するのですが、その使い分けに関して、一つ疑問があります。

動的、といった場合、度のレベルから動的で、どこまでは静的な使い方などでしょうか(特に時間的な意味で...)。
例えば、起動時に画像ファイルから作ったテクスチャーをそのまま
使い続けるのは、a)静的な使い方だとして、他に

b)ポップアップメニューとかダイアログとかで、ユーザーの指定があって
初めて、画像の一部に書き込みをする場合
:: 大雑把に見て、数分ー数十分に一回の書き込み。

c)数秒ー数十秒くらいに一回、マウスイベントとかで光らせたり 色を少し変更するために、画像の一部に書き込みをする場合

d)フレーム毎、つまり、例えば 60fips/sec の場合、毎秒60回も
書き込みをする場合
Lock/Unlockとか、頂点/ピクセル シェーダ経由の書き込みで、
これだけは、動的であると、私も認めているのですが

b),c)の書き込み頻度では、コード作成を少しでも楽にすることを
考えると、できれば xx_MANAGED で作っておきたいのですが
(...ウインドウ リサイズ毎に作り直さなくてもいいため。)

ただし、xx_DYNAMICのテクスチャーは、ほぼ必然的に xx_RENDERTARGET
として使われることになり、そうすると、::GetDCがつかえないため、
不便だな、と思うのです。
( GetDC や、::GetDC は、DirectXの使いづらさを補填する、といった意味で
利用価値はある、と思っていますので。)

MANAGEDで作ったテクスチャーは ::GetDCが使えます。
従って、GDIを使って描画ができ、後でそれをテクスチャとして
使うことができます。
但し、SetRenderTargetでレンダリングターゲットに指定できないため、
DirectXでの描画はできません。

他方、DYNAMIC(動的) であり、RENDERTARGET指定した動的な
テクスチャは、::GetDCができないため、GDIでは描画できません。

GDIはBltさえしなければ、そんなには遅くないと思うのです。
(日本語)文字描画とかは、比較的楽にできます。

DirectXなら、グラディーションのかかった２Dボタンを描画
するのは簡単ですが、GDIだと、MoveTo / LineTo で色を変えつつ
描画するのが面倒です。

(MANAGED と、DYNAMICを )
両者を、使い分けたいのですが、どうやら、排他的な制約が
あるようです。GDI描画 vs DX9描画 としてとらえた場合...

一度 DX9で描画し、Present した直後に、Win32APIのGetDC は、
フロントバッファー部に対して使えるので、それでメモリ上の
デバイスコンテキストに転送後、DirectXでテクスチャーに再設定
し、以後はそれをしばらく使う...と言うような方法は、考えても見ました
が、どうも面倒で...

すいません、誰か返事をしてくれると思っていたのですが、
どなたも書き込んでくれないようなので、少し時間を開けたいと思い
ます。
というのは、私のPCが、どうやらだいぶ熱っぽくなってきて、
もうすぐ CPUが60度以上になって使えなくなりそうなので...
一度、Web接続を切り、しばらくPCも電源を落として、休ませよう
と思います。
(オーバーヒートで)ケースがピーピー鳴りだすのも、時間の
問題のようですので。
せっかく初めて2chanに書き込めたのに、今日は私は運が悪かった
ようにおもいます。
後でまた覗いてみます。

一文字目から読んでないが
とにかく必死なのはよく分かった

あ、返事してくれたヒトがいる、ありがとう。

象形文字が上に描かれている２Dグラディーションボタンを、画像として１０個くらい保持しているとします。
画像タイプは.bmp, テクスチャ作成時の指定サイズは、256x256
とします。
それらのボタン上の文字の色は、一つ一つ違い、背景色も
少しずつ違うとします。
そのようなボタンをマウスでフォーカスして背景のグラディーション
だけ、少し色を変え、象形文字部は色を変えたくないとします。

そのようなケースでは、α合成で別ポリゴンを使って加算合成
による描画というわけにはいきませんから、画像のサーフェス
自体に描画したいわけです。

画像のサーフェスを何らかの方法で描画可能な状態にし、
次に少し色の変化したグラディーションボタンを一個上から
描画し、
最後に、文字部分以外はα=0(透明)な 象形文字スプライトを
そのボタンの上に重ねたいわけです。

なおかつ、それを１秒間に60回もやるのは、面白くないため、
更新された画像としてまとめて更新し、以後は一枚の矩形として
１０数個のボタンをもったフレームのようなものとして
描画するようにしたいわけです。

それ以後も、イベントのあった時だけ描画を切り分けて対応し、
描画処理を最小限に押えたいわけです。

象形文字が上に描かれている２Dグラディーションボタンを、画像として１０個くらい保持しているとします。
画像タイプは.bmp, テクスチャ作成時の指定サイズは、256x256
とします。
それらのボタン上の文字の色は、一つ一つ違い、背景色も
少しずつ違うとします。
そのようなボタンをマウスでフォーカスして背景のグラディーション
だけ、少し色を変え、象形文字部は色を変えたくないとします。

そのようなケースでは、α合成で別ポリゴンを使って加算合成
による描画というわけにはいきませんから、画像のサーフェス
自体に描画したいわけです。

画像のサーフェスを何らかの方法で描画可能な状態にし、
次に少し色の変化したグラディーションボタンを一個上から
描画し、
最後に、文字部分以外はα=0(透明)な 象形文字スプライトを
そのボタンの上に重ねたいわけです。

なおかつ、それを１秒間に60回もやるのは、面白くないため、
更新された画像としてまとめて更新し、以後は一枚の矩形として
１０数個のボタンをもったフレームのようなものとして
描画するようにしたいわけです。

それ以後も、イベントのあった時だけ描画を切り分けて対応し、
描画処理を最小限に押えたいわけです。

何故か、二重にかかれてしまいました。
Linuxから書き込んでいます。以前は、Windows(98)の方から
Webアクセスしていたのですが、"WebSiteViewer"とかいう
ワームだかウイルスにやられてしまい、一度システムを事実上ダウン
させられてしまいました。それ以後、(デュアルブートしている)
Linuxの方からWebアクセスしているのですが、文字入力
の使い勝手が良くありません。そのためか、手違いしたようです。

＞レンダー ターゲットの IDirect3DSurface9::GetDC は、ターゲットがロック可能でない限り
＞(バック バッファの場合は D3DPRESENTFLAG_LOCKABLE_BACKBUFFER フラグを指定して作成されていない限り)
＞失敗します。
ヘルプでは使えるみたいなことほざいてるけど。
試していないんでなんとも言えんが。

つーか、D3DPOOL_DEFAULTリソースとD3DPOOOL_MANAGEDリソースを混合して
使う場合、DEFAULTを先に確保して次にMANAGEDを確保しなきゃならないっつー
なんだかよくわからない決まりがあるんだろ？
でも実際こんな管理不可能だよな？MANAGEDをひとつでも作ったら、
次にDEFAULT作れなくなっちまうんだから。
逆に言えば、ひとつでもDEFAULTを使うようなプログラムなら、自前でロスト管理する
機構は必ず必要になる訳で、MANAGEDが使えなくて困るっつー状況にはなりにくいとも。
ツー訳でMANAGED使わない方向を俺は支持する。

>DEFAULTを先に確保して次にMANAGEDを確保しなきゃならない
...そうなのですか？ 知りませんでした。

MANAGED な管理可能テクスチャーは１０数枚くらい、2D/3D用に確保し、
DYNAMIC な動的テクスチャーは、後で必要になった時に 3D用に
一つだけ後から確保しよう、とか考えていたのですが...

>MANAGEDをひとつでも作ったら、次にDEFAULT作れなくなっちまう
...仮に、DEFAULT を１つ そしてその後でMANAGEDを１０枚の順序で
作成したとして、実行時にDEFAULTテクスチャーが、とりあえずしばらく
必要なくなったから、Releaseし、またしばらく後で必要になったから
再び、DEFAULTテクスチャーを作成したいと思ったとしても、
できないことになるのですか？

ttp://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/directx9_c/directx/graphics/programmingguide/usingdirect3d/devicesandresources/applicationmanagedresources.asp
＞Microsoft Direct3D とアプリケーションの両方で管理するリソースを使うときは、
＞アプリケーションが管理するリソースを D3DPOOL_DEFAULT メモリに割り当ててから、
＞Direct3D が管理するリソースを作成する。
＞これにより、メモリマネージャは利用可能なメモリの正確なカウントを維持できる。
これが何を言いたいのかは、はっきり言ってわかりかねる。
正確なカウントを維持出来ないとしてどの程度の影響があるのか？
多少効率が落ちるだけで済むのか、メモリリークが起こるのか、
俺は不確かなんで避けることにした。

また、YOUの象形文字なんたらは
俺だったらマルチテクスチャの加算合成で処理するな。
毎フレーム無駄ってのは、例えばpresentを減らすとか。

DEFAULT(Usage) というか、DYNAMIC(Pool)と、ほぼつながっている
動的なテクスチャーに関しては、DX9の日本語マニュアルを読んだ
限りでは、アプリケーションあたり一つが望ましいというような
ニュアンスがありました。
..すなわち、いくつも確保するような使い方ではなく、ピンポイント
で、本当に動的に作成する必要があるときだけ使う、というような
ニュアンスです。
他方、MANAGED(管理可能な)テクスチャーは、どんどん使ってください
、但し、動的には扱いづらいですから...というような。

事実、MANAGEDでは、サーフェスロックとかは(CD3DFontでもやっている
ように)できるけど、描画サーフェスとしてのロックは、
RENDERTARGETに指定できないため、できない。だから、
::GetDC してBlt転送するか、あるいは、別のポリゴンに読みこま
せる、という方法くらいしか、画像を実行時に書き換える方法が
ないのではと、思います。

DYNAMIC + DEFAULT な動的テクスチャーは、描画ターゲットに
できるが、手軽に ::GetDCでロックする、と言うわけにも
行きません。
動的なリソースは、多分、ビデオカード上のメモリに保存される
のでしょうが、既に頂点バッファーとか、インデックスバッファー
でたくさん使っているので、そうたくさんは使えない、という
イメージがあるのですが。

管理リソースなら、ビデオカードとPC上のメモリ上とを
行き来できるから、そんなに負担にはならない、と思うのです。

>また、YOUの象形文字なんたらは
俺だったらマルチテクスチャの加算合成で処理するな

..実は、そのことなのですが、
FinalColor = [ SrcColor*Alpha + DstColor*(1-Alpha) ]

としてしまうと、象形文字(テキスト入力できない文字)の文字の色
が、少しだけ変化してしまう はずなのです。

もし、象形文字がボタン１０個とも、例えば黒なら、カラーキー
を D3DXCreateTextureFromFileEx(...); の１０番目の引数に
0xff000000 // 黒 を指定して画像を読み込めば何とかなる
のですが、１０種類のカラーキーは指定できないため、
α合成すると、少し象形文字に他の色が付いてしまいます。
...それをできれば避けたいのです。

そういう次第で、画像に直接、服数回に分けて部分描画したい
のです。

>
無駄だと言っているのは、毎秒６０フレームの描画回数のことでは
なくて、描画に必要なポリゴン数のことなのです。

もし、フレームにボタン１０数個が収まったひとつのテクスチャなら、
一つの矩形ポリゴン、したがってトライアングル一枚分で描画は
終ります。頂点バッファーの大きさも少なくて済みます。
...仮にそれが、任意分割ウインドウのサブメニュー矩形だとすると、
ビュー枚数分の矩形をビューポートを切替えて描画するだけで済みます。

..もし、フレーム１枚＋中身のボタン１０数個*2(レンダリングパス)
を、分割ウインドウ分行うとすると、例えばアプリケーションのビューが
５分割されているとするなら、5*(1+10*2) =110 個の２D矩形を
描画しなければなりません(トライアングル数では、その２倍)。
..大した数ではないと言えば、そうかもしれませんが、αを有効に
したままであるし、２ー３回のレンダリングパスを使います。


はっきりいって、２D描画にあまり描画エネルギーを割きたくないのです。
本命は、(各任意分割ビューポート上)３Dオブジェクト群の描画
であると考えていますので、２Dコントロールは、簡単に描画を
してしまいたいのです。

仮に、ユーザーがおもしろがって、２０個位にビューポートを分割しても、
サブメニューへの描画回数を少なく(各２ー３矩形くらい)に
したいのです。

>5*(1+10*2) =110 個 ...105個でした。

>ビュー枚数分の矩形をビューポートを切替えて描画するだけで済みます
...じつは、2Dでは、ビューポート切替えはしません。
Hole(全)クライアント座標を基準に２D頂点座標を ビューポート分保持しています。
...3Dオブジェクトは、ビューポート毎にカメラと射影行列を
切替えます(もちろん、ローカル／ワールド行列も)

結論から言うと、PCからすれば
出来れば描画サーフェイスはロックして欲しくないんだよ。
D3Dは描画サーフェイスはロックにやさしくない。
だから、まずやらないで済ます方向で検討するのがいい。
どうしてもやりたければ>>323で挙げられたどれかでやるしかない。
俺なら別ポリゴンで間接的に描く方法を選ぶね。
VRAM的に難しいなら、D3Dをやめるよ。

＞管理リソースなら、ビデオカードとPC上のメモリ上とを
＞行き来できるから、そんなに負担にはならない、と思うのです。
管理リソースといえど制限は同じ。
内部的にシステムメモリとVRAM上の両方にテクスチャを作って
自動的に転送するってサービスをしてくれるだけ。
UMAならもっと効率のいい管理をしてくれるかもしれない。

>>324
意味がよくわからないが、正しいやり方をしてないっぽい。
背景色だけのテクスチャの上に文字のテクスチャを上塗りするってイメージで出来ない？

>結論から言うと、PCからすれば
>出来れば描画サーフェイスはロックして欲しくないんだよ

..私も、そうではないか、と思います。

..但し...問題は、ロックの頻度によって事情が変わる、と言うことです。
"D3DPRESENTFLAG_LOCKABLE_BACKBUFFER"
という、使えそうにないフラグがありました。
使えない、と言うか、MSが推奨していない、と言うか...
だから、私は、これまで一度も使ったことはありません。
CopyRect系の処理に関しても、DX8-DX9では、使いません
(使えないようなデバイスしか作成していません)
例外は、文字描画のために GetDCを DX9から、あるいはDX9を介さない
で呼び、Blt だけはなるべく行わないでうまく処理することぐらいです

他方、テクスチャーのロックに関しては...
もしフレーム毎に(一秒に数１０回も)ロックをするとしたら、これもやはり
適切な使い方ではないのでは、と思います。

でも、数秒 ー 数１０秒に一度のロックなら、大きな負担には
ならないのでは、と思います。

>俺なら別ポリゴンで間接的に描く方法を選ぶね

..私の方法も、一応別ポリゴンによる方法です。但し、
頂点色だけで描画できる部分と、どうしてもテクスチャー
(透明部分を持った象形文字などや、そのままイメージボタンのもの)
をセットして描画しなければ行けない部分との 組合せを
処理することになっているので、
個別描画 か 一括描画か、という問題を考えると、結局

"ボタン毎のテクスチャー矩形を、ボタンイメージ列から
それぞれテクスチャー座標を指定し、ボタンの数＊フレームの数
だけ、一個ずつ ポリゴンに張り付けて描画する"

よりは、

"一つのテクスチャーにまとめておいて、(一つのポリゴンに
張り付けて)一括描画"
という方法が好ましい、と思うのです。

どうやら、私が、ごちゃごちゃとまとまり無く書き込んだのが
行けなかったかも知れません。
...たびたびの返答に関して、感謝しています。

要は、DEFAULT(ないしはDYNAMIC)の画像データと、
MANAGED(管理リソース)の画像データとを、
お互いにやりとりする、効率のよい方法が知りたいのです。

今までの私の知識では、
一度フロントサーフェスに Present したイメージを、
"PrintScreen" 的な方法でゲットし、
管理テクスチャーを::GetDCし、やむを得ずBitBltでイメージを
転送したうえで、::ReleaseDCし、更新したテクスチャを使って
ポリゴンを描画する
、と言う方法です。
１０数秒に一回しか行わないなら、全体としてのフレームレート
にも影響しませんし、
第一、アプリケーションが 終日 連続描画モードであり続ける
わけでもありません
(メニューボタンが光ったり、サブメニューを出すときとか、
３Dオブジェクトを動かすとき以外は、ワンフレーム描画です)

余談ですが、私の使っているPCは、CPU冷却環境 が良くないためか、
夏場は１時間以上使えません。
これで、CPU使用率100%の DirectXを使ったゲームでもしようものなら、
15分で、PCが(温度が設定限度を越えたために)ピーピーなり出します。
そんなわけで、連続描画は、ゲームでは仕方が無いのかも知れませんが、
ゲームではないアプリケーションでは、なるべく控えたい、と
考えているのです。

>328::どうしてもやりたければ>>323で挙げられたどれかでやるしかない
..それも、私です。

正直行って、はじめて 2chanのような掲示板システムに書き込んで
いるため、ハンドルネームは、名乗りたくないのです。
私は、今まで、オンラインの双方向システムに書き込んだことは、一度しかあり
ません。そのときは、チャットシステムであり、Windows98からの
アクセスでした。
掲示板に関しては、ReadOnlyでした。
正直行って、Webシステムを信頼仕切っていないのです。
...OSといい、httpアクセスの仕組みと言い、...無限のバグやウイルスといい..
...便利なのは間違いないのですが。

でも、どうしても書き込んで質問したかったので、書き込んでみました

>328
>>324
意味がよくわからないが、正しいやり方をしてないっぽい。 背景色だけのテクスチャの上に文字のテクスチャを上塗りする
ってイメージで出来ない？

...背景色だけのテクスチャには、グラデーションボタンの
イメージが１０数個並んでいますが、そのうちの一つの領域を
マウスでセレクトしたため、グラディーション色を少し明るくする必要ができました。

したがって、まず、そのボタン領域に新しいグラディーション
を、別に用意したポリゴンで Add描画します。

次に、その上から、スプライト形式に透明度を持った象形文字
のポリゴンを、αで補間して加算描画します(当然象形文字部
以外は、α=0 なので、グラディーションに象形文字を重ねた
ボタンが一個描画完了です。)

以上の手順が、私のいう "(A)一個一個、いちいち描画する"という、ポリゴン数の多い手順のことです。

その手順は、一度っ切りにして、presentした直後に、
ボタン１０数個のはいったフレーム[0..n]毎、どこかの
テクスチャへ読み込み、こんどは、それを使って一括描画したい
、と言うのが、私のいう "(B)一括描画" の方法です。

(A)の方法では、フレーム枠＋ボタン数*(グラデーション+象形)
を、そのメニューバーの数だけ繰り返すので、
描画矩形(トライアングルが２枚)の総数は、メニューバー＝５本
とすると、 5 * ( 1 + 10*2 ) = 105 枚の矩形数です。

(B)の方法だと、 5枚 の矩形数で済みます。

誤り >したがって、まず、そのボタン領域に新しいグラディーション
を、別に用意したポリゴンで Add描画します

正確 >したがって、まず、そのボタン領域に新しいグラディーション
を、別に用意したポリゴンで 上塗り描画します

私の考えでは、今のところは、
テクスチャーに、３つの私的リソースクラスを用意するのです。

1) ボタンを一個一個描画するための、ボタン領域を並べたテクスチャー
2) メニューバー一本を更新描画するときに、仲介のために使う
テクスチャー
サブメニュー矩形領域とかも、置いておく
3) メニューバーを本数単位で描画するための、テクスチャー

1)は、DirectXでポリゴンに張り付けるために使用しますが、
GDIからもアクセス可能です。

2)のイメージは、BitBltの Dstであり、Srcでもあります。
DirectXからも、アクセス可能です。

3)は、最も効率の良い、メニューバー単位の描画のためのテクスチャー
ですが、何らかのイベントがあるたびに、イメージを更新する必要があります。
DirectX用のポリゴンに張り付ける前に、2)のイメージからBitBltの
Dst(転送先)になることもあります。

xx_SYSTEMMEM や、xx_SCRATCH のようなメモリクラスを使い、
xx_DYNAMIC なメモリクラスにUpdateSurfaceする、という使い方
は、以上の２点で、問題があると思っていました。
したがって、最初から考慮外なのです。

1) ( SYSTEMMEM, SCRATCH は、)
転送がかなり遅い。おそらく、描画もスムーズでない。
ドライバ側からの管理もしてもらえない
それならGDI描画とかわらないではないか？

2) DYNAMIC な 動的テクスチャーを 転送先として、
2D描画用に作らないと行けない。それなら、直接
レンダリングターゲットにして描画してしまった方が
いいのでは？

誤
>は、以上の２点で、問題があると思っていました
正
>は、以下の２点で、問題があると思っていました

DirectX初心者質問スレでまともに答えが返ってこなかったのでこちらでも質問させてください

諸事情でWin32APIを使うことが禁止されています
DirectInputの機能だけでマウスの現在のクライアント座標を調べる方法はありますでしょうか？

ない

無いのですか
ありがとうございました

頂点バッファーや、インデックスバッファーの最適なサイズは、
どのくらいのものでしょうか？
例えば、
頂点ストライドは、 sizeof(myVERTEX_t) が４０バイト、
インデックスに関しては sizeof(WORD) で ２バイト
だけをつかうとします。

頂点バッファーを、65536*sizeof(myVERTEX_t) で１０本割り当て、
インデックスバッファーは 65536*sizoef(WORD)でやはり１０本
割り当てます。

頂点バッファーは、いくつかのクラス(身分)で扱います。
1) 4096頂点までのサブエリア * 16 を格納するVBを一本
2) 8096頂点までのサブエリア * 8 を格納するVBを一本
3) 4096*4 頂点までのサブエリア * 4 を...(同上)
4) 4096*8 頂点までのサブエリア * 2 を...(同上)
5) 4096*16 頂点、つまりVBまるごと一本あつかう
6) VB*2本を、virtualに一本のVBとして、アプリケーションで扱う
= VB １本＊２
7) 以上のいずれかを、必要なときにサポートするリザーバーVBを数本

以上のようなかんじで、(IBも同様に)頂点バッファー/インデックス
バッファーを扱おう、と考えていたのですが、

65536というユニット数は、妥当なのでしょうか？
それとも、多すぎて、描画速度に描画速度に影響するのでしょうか？
あるいは逆に、もう少し(もう数倍くらいまでは)まとめてしまって
、つまり、n=3ー4 として, 65536*n*siziof(myVERTEX_t)
でそれぞれのVBを作ってしまっても良いのでしょうか？

VBをサブエリアに分けたのは、そのサブエリアが、一体のオブジェクト
( より正式には、シェル(殻) ) に相当するからです。

オブジェクトあたりのトライアングル数(と言うか、頂点数)が少ない
内は、最高4096頂点 まで格納できるサブエリアとして領域を確保します。
( あらかじめ65536頂点の領域を空データで割り当て、オブジェクト生成
ごとに、Lock / Unlockしてデータを4096vtx ずつ割り当てる)
そして、数対のオブジェクトを 一本のVBにまとめ、描画のときは、
DrawIndexPrimitive の引数のうち、開始インデックスや 必要頂点総数
をオブジェクト毎に調整して 描画します。

そのようにするメリットとしては、同一の VBであるため、
SetStreamSource(...); をオブジェクト分呼ぶ必要は無く、一回で
済むことです。
私の恐れるのは、反対に、むしろSetStreamSourceで
オブジェクト分切替えて(むろんVBをオブジェクト毎に作成して)
描画した方が 処理が早くなるかも知れない？と言うケースです。

後者の場合、サブエリアをまとめるべき最適なVB長(65536より低い値)
を模索することになるのですが...
あるいは、VBは、オブジェクトごとに割り当てるものだと割り切る
ことになるのですが...

少ない頂点数のオブジェクトでも4096頂点ものサブエリアを割り当てる理由
は、それが動的に変更されるからです。とくにIB(インデクスバッファー)
は、かなり頻繁に(数秒ー１０数秒位に一回くらい)変更されます。

場合によっては、サブエリアのクラス(身分)が上昇し、別の
VBにエントリ(収まるサブエリア)を変更するケースもあります。

特に、最も頂点数の多くなるオブジェクトのケース
(ex. CatMull-Rom法 などで 再帰分割されたオブジェクト)では、
VBを跨いで使うため、一体のオブジェクト描画にもかかわらず、
２回くらいSetStreamSourceします。

>344
かなり頻繁に変更されるのは、VB(やIB)の サブエリア内部での
"内容(データ)" であって、もちろん VBやIBを作り直すのではありません。
VB/IB を 1)部分Lock して 2)直接１頂点を書き換えたり、あるブロック
に対して更新データをmemcpy(dst, src, k); し、3)部分Unlock
...そのあとにはDrawIndexPrimitive を読んで描画し、Presentする
と言う手続きが、アプリケーションのステート次第では、数秒くらいに
一度行われる、と言うことです。

DirectPlay使うなって書いてあるが
それは要するにWinSock使ってフルスクラッチで書けよﾊﾞｰﾔってことか。

GetCursorPosもScreenToClientも禁止な諸事情って何よ

サブエリアとかなんて君のエンジンの独自仕様だろうから、なんとも分からんなあ。

頂点バッファのパフォーマンスが高ければそれに越したことはないけど
最終的なパフォーマンスに絶対的な影響をするとは限らないから、エンジンとしては
柔軟になんでも放り込める設計で、65536使えることは使えるけど、
データを作る側にどれくらいの分量にするかという指針に従わせれば？

経験的には、staticなバッファでシェーダ以外で弄らない地形で、
視野クリッピング・同属性ソート・優先度ソートを経るとして、
1描画単位は4096頂点に収まることがほとんどだけどね。

ゲームのためのオブジェクトでしたら、確かに
最終的には少ない頂点で、なおかつ現実感溢れるLook & Feel を得る
のに、4096頂点以上使うことは、まれだと思います(あっても数個以内)

私は、モデリングソフトウエアのようなものを想定しているのです。
最初は格子(立方体：正味８頂点)で始まるオブジェクトも、
モデリングを繰り返すたびに、頂点やカーブやサーフェスを編集するため、
更に、ある程度形のまとまったオブジェクトに対し、再帰分割を
分割レベル＝２、３ くらいでやった場合、ソリッド面として使われる
トライアングルは、あっと言う間に１０万頂点位を必要とするレベル
までに増加します。
上記の再帰分割とは、DirectXの NパッチやRTパッチ以外の、ソフトウエア
による実装であり、Cat-Mul Rom とか、Nurbs や B-Spline 等の
その他いくつかの再帰分割手法によるものです。ゆえに、アプリケーション
側で、頂点とインデックスを管理し、生成、追加、削除する必要が
あります。

もっとも、基本プリミティブのような物体(球、立方体、コーン、円柱
、トーラス, etc...) などは、分割や変形が極端に行われない限り、
(そもそも、和規約として使われているため ) 4096頂点ですら越える
ことは無い、と見ていますが。

要は、UINT_MAX + 1 ( = 65536 ) もの要素サイズだと、ひょっとして
VertexBuffer9 や、IndexBuffer9が、保存する頂点配列が
大きすぎるために、GPUエンジンにとって負担となるのではないかなあ？
と危惧しているわけです、(GPUエンジンで内部的に使用する
キャッシュ効率 とか、メモリ同士の転送とか 、ハードウエアの実装は
あくまで、想像レベルに留まらざる終えないのですが。)

頂点シェーダも、インデックスシェーダも、しょせん
エフェクトに過ぎないと私は考えています。
私のもつ、VS / PS に対する評価は、
ネオンのきらめく繁華街に遊びにいって、帰って来た後のむなしさ
のようなものです。
確かに、ヒト昔まえまではハイエンドのグラフィックスワークステーション
でしか、用いられなかった技術が、そしてそれ以上の技術が、
一般のプログラマーや、一般大衆に開放されたことは、多いに評価
してしかるべきだとは、おもいます。
商業上でも、おもにゲーム業界では、多いに活躍していることでしょう

でも、肝心のことは何もできない、扱わない、それが VS / PS
だと私は考えています。

SGI や MS や Nvidia などが言っている、グラフィックスパイプラインとか、
レンダリングパイプラインと言うものは、私にとっては、一本では
ありません。後３本くらいあります。
そのうちの、最初の一本がほとんどハードウエア化され、高速化されても、
しょせん "エフェクト"なのであるから、
残りの３本のパイプラインは、アプリケーション側でソフトウエア的に
実装する必要があります。

>>350
もうちょっとちゃんと勉強しようね。

間違えました。
X> 頂点シェーダも、インデックスシェーダも
O> 頂点シェーダも、ピクセルシェーダも

つうかVertexBuffer使わなきゃ万事OKじゃん。

decl[]で宣言し、D3DXMESHでやる、ということですか？

D3DXMESHは、トライアングルを扱うのに、あるいは xファイルを
扱うのに、最適化されたオブジェクトです。

トライアングルに関して、隣接構造を持っていますが、それは
(少なくとも、私の扱う分野においては)不完全な隣接構造です
もちろん、継承元の親クラスのソースコードは公開されてませんから
想像でモノを言っていますが、すくなくとも位相変形ができない
(幾何変形は、コーディングしだいでできるが、位相変形を扱うと苦しい)
と言う意味で、不完全な隣接構造です。

頂点バッファーを扱わず、さらに、メッシュを扱わない場合、
GPUにとって最適な頂点格納を扱えるオブジェクトを考えた場合、
(動的な)頂点バッファーとインデックスバッファーのセットを
扱うことしか、私は方法を知りません。
むろん、GPUマシンコードや、CPUのマシンコードを バイナリコーディング
で扱うことは、今のところ断念しています。
それは、単に時間との戦い、と言う問題を含むだけで、主要な問題
ではないし、とりあえずいくつかのプラットフォームに対応できれば
いいからです。

HAL(ハードウエアアクセラレーションレイヤー)というものは、
ビデオチップ/ボードを供給する企業の業界団体を束ね、その中の
非営利的かつ研究的な人的集団を一つ作り、
その集団が構築するべきだった、と考えています。
そうすれば、
少なくとも、ビデオボードには依存しないコードが簡単に書けるし、
API群も統一されるわけですし、アセンブリコードも書くことが
できるわけです。
残念だな、と思います。

バカｷﾀｰ

まぁあまり相手にしないのが吉だな。そのうち去るだろ。

>356へ
いやしくも人を公的な場所で非難するなら、怨みを残すような
捨てゼリフだけ吐くのではなく、
どのようなところがこれこれの理由で"バカ"なのだと、むしろ
はっきりと述べる、あるいは述べる用意をした上でするべきだと
おもいます。
...正直、あまり気にはしていませんが。
明示的にかつ具体的に中傷された方が、私としてはありがたいし、
むしろ、その人に感謝するであろうし、中傷された方としても反省し視点を
変えるきっかけになるのです。

そのような記述を用意した上で、私のことをもう一度バカよばわり
してくれませんか？

>>358
えらそうなこと言う前にもうちょっと勉強しろ。なぜ馬鹿呼ばわりされるか考えろ。

359へ
>あなたが、私のもつ知識の全てを上回る知識をもってして、
私を諌める、あるいは非難しているとは、どうも考えられません。
あなたが、私が尊敬したくなるほど、学びたくなる程の知識や技術を
もっているとも、考えられません。
むしろ、ある種の偏見に固まった論理的思考のセットをもってして、
私に悪い感情をもった、と解釈しています。

また、私は、偉そうなことを言っているのではなく、単に
私の見方を披露しているのであって、それにたいする論理的な反論を
(あるいは、できれば共感を)期待しているのです。

それなら、それでもいいし、もしそうでなく、あなたが私を非難するに
だけの人物であるなら、何をどのように勉強するべきかを、
述べてくれませんか？

>>360
で、おまえは誰？３５５？
もしそうなら、客観的に見て馬鹿って言われても仕方ない意見しか書いてないのだが。

>>360
内容に対して文章が冗長
もっと短くまとめろ、読み飛ばされていることに気づけボケ

つーか意見を発するならblogなりを立ち上げるのが最善
コメント，アクセス数が全てを物語ってくれるはずｗ

ちゅーかモデリングソフト想定してるなら、
ハードの能力を使う場合と使わない場合と両方作ったほうがいいよ。
ハードによって結果が変わっちゃうなんて駄目商品以外なにものでもないからね。

ゲームみたいに直でハードのメモリにおいちゃわないで、
システムメモリにいつもおいておいて、ユーザーから変更があったらまずシステムメモリにおいてある
頂点を変更して、それからビデオメモリに流すようにしなきゃ駄目だよ。
DirectXが関係するところはビデオメモリに流すところだけ。
つまり、アプリケーション側の処理にはなんの影響も与えない。
これはゲームでも同じだと思うんだけどね。

つまりDirectXの使用可・不可を切りかえられるようにすれば万事ＯＫ。

バカ過ぎて笑える

>少なくとも、ビデオボードには依存しないコードが簡単に書けるし、
>API群も統一されるわけですし、アセンブリコードも書くことが
>できるわけです。
>残念だな、と思います。

>少なくとも、ビデオボードには依存しないコードが簡単に書けるし、
>API群も統一されるわけですし、アセンブリコードも書くことが
>できるわけです。
>残念だな、と思います。

>少なくとも、ビデオボードには依存しないコードが簡単に書けるし、
>API群も統一されるわけですし、アセンブリコードも書くことが
>できるわけです。
>残念だな、と思います。

文体が同じ罠

中途半端な知識だけでDirectXのコーディング経験がいかにも少なそう。
まずはいろいろと実践して確認してみたら？

とりあえずモデリングソフトに>>342みたいな手法はかなりナンセンスだと思う。

>>367
同意。
こんなちゃちな最適化は意味をもたない。
ハードのパワーごり押しのほうがいい。
変な最適化によって高スペックのマシンを使ったときに
パフォーマンスが落ちてしまっては元も子もない。

>364氏 および 不特定多数の人へ
わたしは、以前、デバイスドライバ(のコード)の構成と言うものは、
分類の一方法として、
大きく分けて２つにわかれる、ということを学びました。

1)物理的デバイスに依存する(dependent)ドライバ
2)物理的デバイスに依存しない(independent)ドライバ

ビデオカードに対するデバイスドライバに関して言えば、
前者(Device dependent driver)は
NVIDIAとかATIといった会社が供給するカードないしはチップの、
デバイス単体に対して直接インターフェイスをもつドライバです。
端的に言えば、デバイスに対し、ネイティブなマシン語コード
レベルでアクセス可能です

後者(Device independent driver)は、一例をあげると、皆さん
ご存知のDirectXにおけるHALの部分です。
直接のインターフェイスは、通常、各デバイスの依存ドライバ
に対してもっています。複数のインターフェイスを持っている、と言う
ことになります。
DirectXのHAL(ハードウエアの機能を複数のビデオカードデバイスを
ヒト括りにするために抽象化した仮想物理デバイスというのが私の解釈)
は、Microsoftという会社が供給するものであって
したがって、すべての物理デバイス(ビデオカード/チップ)に必ずしも
対応する必要はなく、純粋に経済的な理由で、どこには対応し、どこは
DISCARD(?)する、と、決めてしまっています。
更に言えば、Windows系のOS上で動くプロセスから呼ばれることを
強制している HAL であり、その意味では、デバイス非依存ドライバ
あるいは、それを司るAPIセットとしての機能は、Microsoftと言う会社
の営利的判断に制約されたものなのだ、と私は考えます。

Windows系のOSで、GPUを扱うプログラムを組むのなら、DirectXが
最善で、他の特殊ケースとしては、ビデオカードをNVIDIAのモノや、
ATIのモノに一種類決めた上で、専属のAPI(実質的には、アセンブリ
レベルでのアクセス)を使う、と言う方法位しか、選択肢はありません
(後者の場合は、UNIX系のOSでも、動くと思います。)

以上の状況(私が勝手に解釈しているだけかもしれませんけど)を
踏まえて、純正なHAL(純正なデバイス非依存ドライバ部)が
OSやカードやCPUなどに依存しないような形で提供されていたらな、
と私はため息を付いて、それを言葉にしたのです。

思いこみの激しい長文厨はスルーが吉

>>371
読んでないが、もしかして312から延々語ってるのは同一人物ジャマイカ
スルーされても

＞純正なHAL(純正なデバイス非依存ドライバ部)が 
＞OSやカードやCPUなどに依存しないような形で提供されていたらな、 
＞と私はため息を付いて、それを言葉にしたのです

マジレスすると OpenGL がそれに近い
DirectX 使う以上 Windows 限定にキメ打ちしないと手間がかかりすぎる

>>369
>>363も読んでよ。
モデリングソフトならハード使わなくてもキチンとした結果だけ欲しいって場面あるでしょ？
それにDirectXに依存する部分なんて最後の描画だけで
君の考えてるような悩みは普通に設計してればおこらないんだよ。
現に使用中にOpenGLとDirectXを切りかえることができるモデリングソフトも結構あるでしょ。

>>373
OpenGL使ったことないでしょ？
環境依存に関してはOpenGLの方が大変。（使ったことがある人ならわかる）

ID 非表示だと誰が誰だか分からんな

わたしは、DirectXに関して、死のうとは思いませんでしたが、
このスレッドのタイトルに似たような(核爆発のような)気持ち
を味わったことは、一度や２度ではありません。その副次的利益と
言うか、苦しみつつも、バージョンアップに悩まされつつも
とにかくDirectXを使うことに執着した結果、次のことが判明したのです。
.
...OpenGL切替えコードを実装したときのことです
"OpenGLって、なんて、わかりやすくて、かんたんなんだろう？"

DirectXと比較していったのです。
最初扱ってみて、知識が不足していて困ったこともいくつかあります。
1)wgl系の関数で、初期化をする手順
2)右手座標系(私はそれを、正当なる座標系と呼んでいますが)なこと
3)マトリックスを扱う構造体が無く、gldouble[k]とかglfloat[k]
でやること、テクスチャーに関しても、３次元配列っぽいものを使う
4)テクスチャー座標に関しても、左下が原点であること

対して困ったと言う程でもないですが、初回にてこずったのは、
おもにそんなケースです。

たぶん、DirectXに苦労しつつも、(数バージョンに渡って)
使い続けてきた人達は、私と同じ感想を持つのでは、と思っています。
ただし、条件つきですが。

インターネット初期の香りがするスレはここですか

< DirectX環境から OpenGL環境に移って、Happyになれる条件 >

a)Unix系OSでOpenGLを扱うことは、また別の問題である。
それは、むしろ、kernelとか、ウインドウマネージャーとか、と
どうつき合うかの問題が大半だからである。

b)少なくとも一度位は、一連の座標変換とか、スキャンコンバージョンとか、
(できれば、ソフトウエアZバッファーリングとか、)、あるいは、
さまざまな観点からのシェーディング処理を、あるいは
テクスチャー座標を扱う処理を、自前で実装してみたことがある事。
...実装したこと無いないとしても、論理的にはきちんと理解していること

3)大学教養過程レベルか、もしくは高校受験クラスの数学を
ある程度自分で納得して扱えること

そんなところが、幸せになれる条件かと、私は思います
条件に当てはまらない人は、それなりに苦痛を感じるかも
知れません、が、必ずしもOpenGL環境移行を阻むほどのものでも
無いと、思います。

>>379
ちげーよ。
OpenGLで一番ムカツクのは環境依存だ。
バカタレ。

>374さんへ、
DirectXを敢えて使うのは、それが、ハードウエア直アクセスに
ある程度近い効果を持つからです(それでいて、ある程度は
環境依存性の問題を解消できる)。

その代わり、DirectXの提供するデータ構造や処理経路を使うことが、
ある程度暗黙の了解となります。
その例が、頂点バッファー、インデクスバッファー
さらにはメッシュオブジェクト
処理経路に関しては、頂点シェーダとピクセルシェーダを幹と
した処理経路(レンダリングパイプライン)に会わせることになります

ですが、DirectXは、どちらかと言うと、ゲーム系のアプリケーション
を作成するのにいろいろな意味で(偏って)最適化されたAPIセット
である、と私は見ます。

そのような設計しそうによって作られたAPIセットを使い、
そのような分野とは、ある種相容れないデータ構造を扱いたいとき、
まず悩むのは、どこまでが許容されるのか、という、見切り
ラインをどこにひいたらいいか？ということです。
具体的にいうなら、頂点バッファー/インデックスバッファーは
どのようなアラインメントやユニット数で複数のメモリデバイスを
言ったり来たりするのか、ということです。
そのような実装についての解説は、DirectX9Helpには、どこにも
ありません。なぜなら、ゲーム系のオブジェクトを扱うのなら、
頂点バッファーの内容は変更されないで固定されているほうが
ふさわしいからです。

で、結論なんだけど
頂点はソフトウェアで管理して。
IDirect3DDevice9::DrawIndexedPrimitiveUP使ってさ。

UP系は、遅い、と言うイメージを持っています(用途にもよるでしょうが)
ソフトウエア管理、と言うのは、レンダリングパイプラインにセットする
ということに関しては、ハードウエアで扱える方がベターだと考えて
います。ただし、最適なユニット数がしりたいな、ということです。
むろん、MIXEDで頂点を作っているため、ある状況では、ソフトウエア
に切替えたりもします。
大量の頂点を持つ３Dオブジェクトを高速にレンダリングしたいなら、
できるだけ、DirectXの処理系統に従う、というのが王道だという
にんしきは、もちろんもっています。只、その範囲で、どこまで
逸脱することが可能なのか、という観点なのです。

最も、最近の傾向はピクセル処理に傾いている、というのも
認識はしています。
ビデオチップ部のトランジスタ部が、ピクセル処理部にたくさん
リソースを傾けている、ということも。

ここはひどいインターネットですね

天然なのか新手の荒らしなのか

>>383
マジレスするとドライバで勝手にやってんじゃねーの？
って気がするけどね。
アプリ側でどんなに頑張っても触れないんじゃない？
パイプラインとかいってるぐらいだからハードが自分に最適な動きをするために
パイプラインに送る命令しか俺等にいじらせないわけだし。

前はDrawPrimitiveの一発で描画されてた気がするけど
頂点ストリームとか入ってきてからDrawPrimitive前後にあるBeginとEndが怪しいと思うようになった。
結局、どんなデータ構造で持つとか渡すとか問題があるようには思えない。

UP系が遅いってのはそれこそ先入観だね。
たいして変わりゃしないよ。

>386さんへ
BBSの(特に2chに関しての)暗黙の了解を、私が良く認識していない
せいだとおもいます、
荒らしとは、どのようなケースをいうのですか？
(自分では、そうではないつもりでいますが)

>388さんへ、教えてください
描画されるオブジェクトを(特に、その頂点データを)どのように保持していますか？
1)メッシュ(D3DXMESHのような)
2)自分で作ったクラス、ないしはstructure
3)頂点バッファー系
4)その他

環境依存に不満をもつのなら、TRON をお勧めするよ

>389さんへ
BBXとかいう掲示板を、いぜんロムったことがあります。
DirectXに関する話題を扱っているようですが、
2ch と違って読むのが辛いです(スレッドの表示方式に関して)
でも、読んだり、検索したことがありましたが、しきりに
"DrawPrimitiveUP"という識別子が 話題として使われていました
(と言う、印象を持ちました。)
そして、その理由は、おそらく、彼らが(彼女らが)、おもに
２D系のゲームを作りたい人が多いからだな、と、私は推測
してしまったのです。
２D系のゲームなら、必ずしも１フレーム毎に全画面書き換える
必要はない、パーシャル(部分的)描画で対応した方がむしろ、
パフォーマンス的にも利益になるケースが多い(ようだ)。
例えば、例をあげると、WindowsのOS自体も、ロングホーンに
なるまでは、以前として２D描画である。
メニューバーのメニューがマウスフォーカスを持つとき、描画
されるのはボタンの周りのライン一周か２週分である。
全体のボタンを再描画するより効率的だからである。
３Dでは、多くの場合、そのようには行かない。

>>390
モデリングソフト作ってるんでしょ？
だったら２つ用意するしかないでしょ。

１つはシステムメモリ側にアプリケーションで触る頂点データ（これは自作のクラスもしくは構造体のが都合がいい）。
もう１つはビデオメモリにおく頂点データ（これはあくまで描画用、描画するときにシステムメモリのデータをコピーするだけ）。

ゲームではビデオメモリにおいて終わりだね。（頂点バッファ）
モデリングソフトはデータを変更されるたびに　システムメモリ→ビデオメモリ　をいちいちやらないとね。

>387さんへ
ドライバーで勝手にやっていることは前提条件としても、
十分に公開されているやりかたがあるケースと、無いケースが
あるとおもうのです。
公開されているケースとしては、テクスチャーの幅と高さを
２の累乗で作ってくださいとか、以前なら 256x256のテクスチャが
一番(ドライバにとって)効率がいいですよ、とかいうものです。
無いケース(あるいは、なかなか気が付きにくいケース)にかんして、
このスレッドでだれか答えて欲しいものです

>393さんへ
もしかしたら、私は、"動的な"頂点バッファーとか、DYNAMIC
な使いかた、という意味を吐き違えているのかも知れません
ですが、
今のところの方針としては(WRITEONLYでないとかなりおそくなる
、とのお言葉があったとしても)、
３Dオブジェクトは 常に動的なVB/IBで管理し、幾何変形(端的に
いうと頂点バッファーやインデクスバッファーのLock/UnLock /数秒間隔 ) と位相変形(これは、V-E(hf)-Lの内部データ
も扱うため、それらにかんしては必然的にシステムメモリ)を、
終止DYNAMICなリソースへのアクセスとして扱うのがいい、
と考えているのです。

>>394
いまのところそういうのは無いと思うけど？
汎用性を重視すると３Ｄ関連のそういうのは全部消えるんだよｗ
選択肢としてとっちゃ駄目なのが多い。

三角形のストリップ化もいまとなっては扱い難いだけだしな。
DrawPrimitiveの回数を減らそうなんて余計な手間考えるのも無駄だし。
テクスチャなんて無駄にまとめたって速いかどうかなんてわかんね。
テクスチャ切り替えだってやんなきゃそもそもシェーダつかえないじゃん。
マテリアルでまとめて描画なんてシェーダ使ってたらやってらんない。
と、まあ、最適化の類はだいたい消えたけどね。（俺はもうやってないけど？まだみんなやってるの？）

それともＺバッファ使ったときの前から描画とかそういう初歩的なものが知りたいの？

つまり、確かにLock / Unlockは、最速のフレームレートを
えようと思えば、できるだけ避けた方がいいのでしょうが、
それよりも、大量のデータ転送を伴う処理(あるメモリリソース
エリアから、別のメモリーリソースエリアへの大量転送)
は、もっと避けなければならない処理だ、という認識からです

>>395
モデリングソフトつくってるんじゃないの？
ビデオメモリがロストしたらユーザのデータもろともあの世逝き？

>396さんへ
あんまり気にするな、実装してみて、まずそうだったら
またやりなおせ、と言う趣旨に受け取ってよろしいですか？

…結局何がしたいんだ？
うんちく述べてるだけで、何したいんだかサッパリ分からん。

いまってそういう最適化の類って気にする必要ないし、できないもん。
適当にクリッピングして遅いなら、もう駄目だよ。
打つ手無し。

>400さんへ
1)頂点バッファーとインデックスバッファーを動的なリソースとして
結構たくさん確保したい
2)頂点バッファー一本あたりに、複数のオブジェクトセットを
詰め込みたい、オブジェクト毎に頂点バッファー一本割り当てる
のでなく
3)頂点バッファー一本, インデックスバッファー一本の
これ以上バイト数増やすとまずいんでない？という
ある程度の目安が知りたい!!
私の予想(根拠は特に無いけれど)としては、UINT_MAX + 1
つまり、64k(65536)サイズあたりが、境界線ではないかと
予想しているが、果して正しいのかどうか？!!

...気になるのは、気にそんなところです。

>>402
つーか、それは描画毎に頂点バッファを再確保することが前提なの？

もし、描画毎に再確保するなら再確保するから遅いと思う。
描画前に再確保しないなら、ビュークリップされないから遅いと思う。

>398さんへ
どっかのOSみたいに、３０秒くらいに一回、システムメモリ領域に
、ないしはさらにハードディスクへ(一時的ファイルとして)書き込む、
と言う方法をとりあえず考えています。
30秒は、フレームレートから見ると、かなり長い時間間隔なので、
あまり問題は無いと思います。

それと、頂点バッファーに置くのは、あくまで、表示用データ
(私は、DisplayListとかよんでいますが)であって、以下のものです
Surface(ループ上の面)... Solid描画用
Curve(エッジを表示するためのラインのリスト) ...稜線描画用
Point(編集用頂点ないしはコントロールポイント) ... 頂点描画用
...上記のものには、マテリアル系のデータが含まれます
他方私が再優先に扱いたいデータ構造である、
Vertex, Edge(+ halfEdge*2), Loop の位相構造に関しては
常にシステムメモリ側で管理します。というのは、描画用の
プリミティブを構成するものではないからです。隣接関係を
記述するデータだからです。Solidモデラーと呼ばれるモデラー
が必要とするデータ構造です

最悪の場合、ROSTして、その日に編集していたオブジェクトデータが
全て失われたとしても、少なくとも位相構造データは最終的な編集の
終りまで確保され、なおかつ、マテリアル系データの一部に関しては、
確かに失われますが、やむ終えない、という方針です
もちろんそれは、バグでしか無く、いずれ何らかの方法で解決しないと
行けないでしょうが、
OpenGLなら、immモードでないかぎりそうなら無いから、OpenGLでいこう、
とは、あっさり割り切れないのです、私。

なんかえらい勘違いしてるな

又バカ発言ｷﾀｰ

>私の予想(根拠は特に無いけれど)としては、UINT_MAX + 1
>つまり、64k(65536)サイズあたりが、境界線ではないかと
>予想しているが、果して正しいのかどうか？!!

>403さんへ
頂点バッファーを作成する処理は、まだ一つも3Dワールド空間に
オブジェクトが置いてない段階で行います。
ちょうど、D3DXDevice9とかいう名前の"デバイス"インターフェイス
を作成した直後にです。５本から１０本位ずつ
C++風にいってみれば、バッファー管理クラスのインスタンスを割り当てる
過程で、コンストラクタ呼びだし時におこなわれます
( 私は現在、main(int, char**) をつかい、C言語を使って実装して
います。以前はC++でしたが、現在は明示的なthisポインタとか、
->lpVtbl-> を使って、デバイスの諸関数を呼び出しています
でも、実質的に Winmain(...) や、_wWinmain, _tWinmain と
殆んどかわりありません。)

オブジェクトをユーザーが指定したとき、頂点バッファーをロックして
必要な頂点データを、インデクスバッファーに対してはインデクスデータ
を随時書き込みます。

リサイズとかリセットの処理は、フレームワークの処理と同様の
経路を実行できるようにしてあります

私は、一見すると、いろいろと保守にかかわることをべらべらしゃべる
ように写っているのかも知れません。
でも、白状しますが、本当に重要なことは、一つも述べていません
し、いままでの状況を判断すると、多分述べないでしょう。
2chは、これだけのスレッドを抱えていて、ものすごい印象を以前は
持っていたのですが、
"もったいないものだ..."
というのが、現在の心境です。外国のスレッドと比較して、どうしてこうも
ことなるのでしょう？

ある程度の一般論を言うが

・普通そういうレベルの最適化はほとんど効果がない
・もっと効果が明確に出る高速化手法がいくらでもある。
　(OcTreeなどを利用した視錐台クリッピング、Zソートして手前から描画など)
・DrawPrimitiveの最適値は環境によって違うしMS公式では1000ポリとかなんとか書いてあった事がある
・DrawPrimitiveUPは結構速い。

まさにスレタイどおりの展開だな

>410さんへ
ありがとうございます
3000個の頂点、ということですか？
私が考えていたより、かなり少ないユニットなのですね
メモリ間データ転送とか、キャッシュを扱う上で、そういう数値に
なるのでしょうか...?
ところで、もしよろしければ、データの出処を教えてくれませんか？
(できれば、そのデータが発表されたときのおおよその日付も)
私も、GoogleやAltavistaで 何度か懸命に探したのですが、とうとう
見付けることができませんでした。

>>412
効果がもっとも薄い最適化にそんなに必要に拘る理由はないだろｗ
もう、いじっていうか意味はないんだよね・・・ｗ

だから何頂点までなら〜とか
何バイトまでなら〜とか
そんな検証殆ど意味ないんだって。
どうしてもやりたいんならコンフィグダイアログボックスに
VertexBufferキャパのスライダでも付けとけ。
それか常に時間計って動的に容量を変えるとか。
しかし、そんなもん付けたって
素で組んだのと大して変わらなくてm9（^Д^）ﾌﾟｷﾞｬー

でも、疑問に思うのですが、現在のある程度ハイパフォーマンス
をもつビデオカードを使った場合、頂点処理は、そんなに負担では
ない、あまり遊ばせない方がいいからピクセルシェーダをもっと
使った方がいい、という記述を、本でみました。
また、スペックからみると頂点数では、フレームあたり
400万頂点か、その２倍位(一秒あたりには、その６０倍として)
はほぼ問題なく扱える、と私には読めました
つまり、4000回もDraw処理を繰り返すのですか？
それとも、メッシュオブジェクトとかは、頂点バッファーとか
とは、まったく別の経路で処理されるのですか？

そのように処理してなおかつベストだというのなら、
Draw系の処理は、かなりの回数呼んでいい、と言う解釈
になってしまうのですが。

>
ディスプレイリスト管理クラスのstructureの使いかたおよび、
メンバ変数や、メンバ関数(に相当する関数)が、
私のこだわっている判断材料のいかんによって、がらっと
代わってしまうからです
最適化自体とはとらえていません、クラスの設計上の問題
としてとらえています
でも、いままでの印象からわたしの得たものは、大勢は
別の最適化に注意を払っているのだな、という仮説です

>>412
すまん、1000頂点と書いてあった。
http://www.microsoft.com/japan/msdn/directx/techart/directx9devfaq.asp
あとメモリ間データ転送、キャッシュだけではない。
他にも色んな要素が絡んでこういう数値が出てくるんだろ。

400万頂点…ピクセルより多い頂点数で何を描画するんだ？ｗ

>>415
つーか、もう誰もその辺を最適化かまして速くしようなんて人いないよ。
シェーダが絡んでくると信じられないぐらい複雑になっちゃうし。
現実的じゃないね。
大体、ドライバ側・ハード側で何をどういう処理してるかだって理解してないのに
なんでそんなところにこだわろうと思ってるのかね。

メッシュオブジェクトってなんだと思ってんだよｗ

パフォーマンス云々とか考えすぎて、何も作れないって手合いだな。
ベストが得られるまで議論するっていう理想主義者。
現実的解決は妥協で日和だっていう原理主義者ね。

>>419
つーか、自分の考えた方法を否定されたくなくて無駄なこと駄弁ってるだけだろコイツｗ
もう、なんも考える必要ないからさっさと作れって感じｗ

こういう奴の方がただの無能よりたち悪いよな。
こんなトンチンカンな話延々とされてもなー

>417
ディスプレイあたりのピクセルの数 =1000*1000 =１００万
大雑把な例
確かに、うっかりしていましたが、知らないわけではありません
理論値から計算すると、そう(４００万頂点)なります。
でも、逆にいえば、それは、現行に置いて頂点処理にかなり余裕がありすぎる、ということ
でもあります
ついでにいえば、ビューフラスタム外部にある、最終的には描画
されずにカリングされたりする頂点も、途中までは処理される、と
いうことです。
...いずれにしても、400万とか100万頂点は現実的ではない、とは
認めます。ですが、数１０万頂点頂点くらいなら、実際生成される
ケースはあり得ます
(もちろん、一ピクセルとしても認識されないようなトライアングル
も多数含めて )

>>421
折角、最適化なんて無駄なこと考えなくていいような時代になったのに変な奴いるねー。

>>422
お前はもうしゃべんなくていいよｗ

>>416とかを見ても明らかにダメっぽい。
最適値がなんでクラスの設計上の問題になっちゃうの？

で、数百回 Drawがフレームあたりに呼ばれるとして、
それでも、多いんだな？という印象です。
数１０回くらいなら、納得できるのですが(少ないに越したことは
ないとも思いますが)
DirectX は、ソフトウエアOpenGLとは異なり、そんなに
たくさんの描画処理関数を Begin / End ブロック内では
呼ばないものだ、まとめて描画するのがいいのだ、
とは、私がヘルプを読んで得た印象です

バカの印象なんてどうでもいいよ…

>417
"パフォーマンス チューニング" にかんして、
読んでみました。
情報の提供、どうもありがとうございます
これからは、microsoftのホームページももうちょっと
さがしてみようとおもいます。おさわがせしました。

ここまでスレ荒らして作ってるのが２Ｄシューティングだったら死なすｗ

まあ、なんていうか

　早すぎる最適化は諸悪の根源

の典型的な例、というか

　Try & Error

を理解した方が良い、というか

まあ毎フレ400万頂点なんてアホなこと言ってないで
さっさと八分木なりLODなりの効果の偉大さを理解しろと

>>429
スプライト1個につき4頂点の計算で毎フレ100万個の弾幕かよ！？ｽｹﾞｰﾖ!!w

ところで、彼は結局なにが言いたかったの？
っていうか 「UINT_MAX + 1 = 65536」 ってどんな環境よ

>>432
凄いなそれは

人間的には、弾は一画面に 1000 個が限界だ orz

虫姫基板の限界が物理的に2000発くらいなんだってね。
まあ2000発も打たれたらたまったもんじゃないが…

嵐も過ぎ去ったところでﾏﾀｰﾘ

右手座標系と左手座標系ってどっちが多く使われてますか？
これから勉強始めるので、多く使われてる座標系で学ぼうと思いまして…

>>436
…？DirectXスレでその質問の意図不明
というより、左手⇔右手系変換など基礎中の基礎だしどっちも勉強しとけ

左手右手の逆転よりもＸＹＺが違ってるのとかモデリングソフトによって色々だなｗ
法線もひっくり返さなきゃなんねーし面倒だったなｗ

Handle H = _Tex(3D"Wire);

　昨日、ここのスレッドの 328..428 で書き込みをしたものです。

先日、諸兄方から、多大なるお叱りを頂、また、度重なる非難を
浴びたことに関し、いろいろと自分でも考えてみました。

思慮が足りなかった....
それが、私の得た結論です。具体的には、PS / VS を根幹にして行われて
いる、DirectX9(or etc..)の使用方法に関して、"エフェクト!"とさげすんだ
(..つもりでは さらさらなかったのだが、どうやらほぼ間違いないようだ)
ことに関して、誤りたいと思います。

せめて、"華麗なる"エフェクト　と、正直に言うべきだった...
そして、こんな私は、現行の３ＤＣＧ(スリーディーシーディー)のメジャー
な状況に対して、心の中で ３Ｄ"２Ｄ"(スリーディーツーディー)などと
毒づくこともります。
でも、自分はといえば、いまだに、"ワイヤーフレーム命" とたびたび勘違いされ
るほどの、WireFrame-Mode 支持派　なのです。だから、冒頭に示したように、
ハンドルネームをここでは、3D"Wire"(スリーディーワイヤー)と名乗ることに
いたします。

もう書かなくていいって

H=3D"Wire"
>439
X>ことに関して、誤りたいと思います。
O>ことに関して、謝りたいと思います。

>>439
変わった芸風の人だな。ｗ
ちなみにワイヤーフレーム命ならOpenGLのほうがちょっとだけ幸せかもしれん。

DirectXも、ZBIASがまともならなぁ

3D"Wire"

先日、オクトリ・ツリーや、Zソート、LOD(レベルオブディテイル)
などの事について、再三聞かされました。正直、私としては、
オクトリツリーとかの効果に関して、疑問を感じてたため、あまり積極的に
使おうとは、今まで思っていなかったのに、ちょっと考えを改めようと
思ったからです。

ちょっと、Octreeの構造体の一例を挙げ、感想を伺いたいと思いましたので
...しばらくお待ちください、入手してきます。

いやいいよ、マジで

こんな奴と仕事したくねぇなぁ

どこの機械翻訳システムを使ってんだ？

読点を入れすぎて文章が読みにくくなる典型。

お前らいい加減スルーすべし

>>444
適当に鳥かコテつけてくれんかね？
あぼーん設定したいから

そうだな、3D"Wire" （は、恥ずかしい）を名前欄に書いてくれればOK
あぼ〜ん可能に

>3D"Wire"
仕事してる人？もう引退した？何か文体がものものしいというか、
60年ぶりに発見された日本兵のような印象を受けるのだが(;´∀`)

>3D"Wire" 
っていうか自分の独り言は自分のブログでも作って、そっちに書きなさいな
ここは公共の場

別にこんな死んでるスレがどうなろうと構わないので
好きに暴れてくれて良いよ＞Wire

ここで暴言吐いてる奴らも、本心では君のことが大好きなんだよ

ほら、こいつアレだよ。

「軍人は有能か無能か、
　そして働き者か怠け者か、
　これらによって4種に分類できる。

　有能な怠け者は司令官に、
　有能な働き者は参謀にせよ。
　無能な怠け者は…
　そうだな、連絡将校ぐらいならできるだろう。
　無能な働き者？
　それは処刑するしかあるまい。」
　（フォン・ゼークト）

無能なくせにセコセコセコセコと無駄な質問ばっかしやがってｗ
無駄なウンチクばっかり覚えてきても１つもプログラムに生きて無いじゃん。
もう、ばっちり無能な働き者だよｗ

>>453
同意だな。

自演スキルを取得しました

いや、無能だしそんなスキル覚えられないよ

3D"Wire"
私は、そんな 三下のザコのような"せこい" ことはしません、
そう...
一行書き込みばかりの、論理思考のできないあなたのような、ね

以後 "DirectX"といった虎の威を借りたスレッド名で人をまどわせ、
貴重な 公共リソースをこれ以上ブロックしないでください

>453さんへありがとう、でも、荒らしているのではない。
私は、もうすこしまともなスレッドだけをみることにします(以後書き込みません)

>>458
> 私は、もうすこしまともなスレッドだけをみることにします(以後書き込みません)

乙。絶対戻ってくるなよ。

>>459
ああ、やっとアホが消えたな。
なにせ>>402を速いとか一瞬でも考えるあたり素質全く無いからな。
ホント、この邪魔なのどう処分したものかと思ったが案外あっさり消えてくれたな。

> 私は、もうすこしまともなスレッドだけをみることにします(以後書き込みません)

まあ、お前は2chのどのスレに行ってもバカにされるだろうよ。
コミュニケーション能力というものが絶望的に欠落しているからな。

平行線を辿る事が分かっているのにどうしてレスするかなあ

ｹﾞ制作板の総合ｽﾚはどうなったの？
誰も建てないの？

>>463
よろぴこ

非常に不快だ。
2ch'erって、なんで初心者を「バカ」だの「アホ」だの寄ってたかって卑下するんだろうね。
どこでもいいからUSのサイトにいってみ？こんなコミュニケーションありえねーよ。
いやな民族だ。さいてーにBITCHYだよお前ら。
その腐った精神は更年期障害を抱えたババァそのものだぜ？

2chで褒められたら、皮肉か褒め殺しかと不安になるから
けなされた方が心配なくてよいよ

>>465
自分でそういいながら腐ったとかさいてーとか更年期障害を抱えたババァだの
もうこれは「オマエモナー」の出番としか思えない。

実際は大部分の人は
非難どころかレス自体しないよ。
俺もバカというレスは一度もしたことないし。

>>468
>実際は大部分の人は
調べたわけでもないのにこういう嘘吐いちゃうところとか
もう馬鹿とかアホとかいわなくても十分同類項で結べると思うよ。
まあ、俺には５０歩チンポの違いでも君には大きな違いかもわからんがねｗ

>>469
現実ここは過疎化してるじゃん。
理由は何でだろう？
DirectXプログラマーが減って需要が少なくなったからか？
そういえばゲ製作板も過疎が激しいな。
理由は何でだろう？
よく考えてみるといいよ。

今回のは初心者だから叩かれた訳じゃないからな。

こんどはBBXで暴れてるよ。
二重投稿ならまだしも三重投稿しちゃうなんて
やっぱりバカなんだと思う。

ﾜﾗﾀ
ありゃひでーな

UINT_MAX + 1 = 65536で鳴らした俺様3D"Wire"は、濡れ衣を着せられ2chねらーにバカに
された。2chを脱出し、BBXにもぐった。しかし、BBXでくすぶっているような俺達
じゃあない。

>>472 爆笑

余裕のスルーを食らってて面白い

>>470
そもそもゲーム業界自体の衰退が原因だろ。
ゲームそのものに魅力がなくなってるから作ろうという奴も少ない。
各ＨＰの掲示板への書き込みもほとんどないし、更新もほとんど無くなった。
それにある程度ゲームが組めるようになるまでの入門書だって発売されてるし
こんなところで無駄な質問なんてしてる奴はやること見えてないよ。
著しくレベルが低い奴が多数。答えて意味のあるレベルじゃない。

つーか、いいかげんゲーム以外の3Dアプリがブレークしないかなぁ。
VRMLとかは大外しだったけど、まだまだアイデアあるだろ。

2Dシューティングが絶望的に衰退したのに2Dシューティングばかり作ってる趣味人の中で
何言ってんだ。

しかしBBXも完全に終わってるな。

>>480
つーか、まともに会話できるレベルから怪しいの多いな。

この　スレは　面白い！

AOEは面白かった。なにが面白かったと言うと、まるでフル３Dのような
気がしたからだ(すべてビルボードだと知ったのは、しばらく後のこと)。
AOMにはがっかりさせられた。期待を裏切られた。
デモムービーを見たときから予感はあったのだが、実際遊んでみて
やはり戦闘シーンなど、甲虫(ゴキブリ？)の戦いの用に汚いイメージがあった。

なぜだろう？なぜビルボードを使ったDirectX7までのゲームの方が、
DirectX8/X9の機能をフル装備したゲームよりこれほど印象が深かったのだろう？

どうでもいいけど、プログラミングに長けていない専門家がアプリケーション
インターフェイスをつくると、なぜMFCコマンドボタンをああも並べたがる
のだろう？(彼らは専門的知識には非常に詳しいだけに、大きなマイナスである)
以前DESIGNEBASEというリコーのソリッドモデラーカーネルのソースコード
(カーネル部はdllまでの非公開だが)をダウンロードし、ソースを読む
よりもまず動かしてみたかったため、VC++で動くサンプルを動かしてみてあぜんとした。
MFCボタンだらけのインターフェイスに。

私はその頃、まだWindowsAPIのWinMain()やWndProc()の事もろくに知らなかった。
VC++6.0を学割で購入する以前は、学割で購入したVB++5.0を使っていた
だから、MFCを駆使してVBライクなボタンだらけのインターフェイスを
コードによって作るのがVC++によるプログラミングだと思い込んでいた。

そのDESIGNEBASEのサンプルを見て、目が醒めた。
ボタンを必要以上に張ってはならない。
その点、AOEのインターフェイスは優れていたと、私は思う。

　　∧＿∧ 　
⊂（#・д・） 　釣り基地ばっかりやってられないっすお！
　/　　　ﾉ∪ 　
　し―-J　|l| |　　　
　　 　 　 　 人ﾍﾟﾀﾝｯ!!
　　　　　　（＿）　
　　 　　）（＿＿）（
　　　　⌒）　　　（⌒
　　　　　　⌒Ｙ⌒

なぜ、わたしは一度限りでチャットで遊ばなくなったのだろう？
やっているときは、想像以上に楽しかったのだ。好意的な印象がおおかったし。

だが、チャットの接続を切り、あらためて第３者の立場でロムって見ると、
こいつら(チャットで書き込んでいる連中)が、ひどくちっぽけに思えた。
そして、そんなちっぽけな連中(それはあくまでその時の私の主観に過ぎない
のだが)といっしょになって遊ぼうとしている自分までがみじめな気がした。
それいらい、チャットはやっていない。あそこはぬるま湯につかっている感覚をおぼえるから。
小学校のクラスルームのような印象がした。

BBSは？
Made in Japan だからかもしれないが、思ったよりも不快だ。
まるで、学生時代にひとりでとなりのクラスに攻め込んでいった
時のような、数十人のザコを蹴散らしにいったような、あと味の悪い感覚があった。
だが、今なお魅力的である。なぜなのだ？
ひとつには、その規模。Capacity。知名度。一言でいえばメジャーであることか。
メジャー自体に組みすることは嫌いだが、人間が多く集まることが魅力的なのだ。
村社会の寄せ集めであることが、大きな欠点ではあるが、今なお潜在的ななにかがある気がする。

なんだこいつ

またなんか頭のネジがゆるんでそうなのが来てるなあ。
全部読み飛ばしたけど。

上の耳年増外人でしょ

どうも一連の長文は全部同一人物が書いてるように見えるな

しかも>>485の文章には致命的なミスが含まれてるので、
何を言いたかったのかが全く汲み取れない情けない文章になってる。

ねじ緩んでるどころか三丁目まで吹っ飛んでる。

二次方程式の解法の適用
(問題の式) x^2 + 21 = 10x

(その１)デカルト以降の解法
(ここでは敢えて因数分解ではなく、デカルト以降の代数学を用いる。すなわち
x = (-b +/- sqrt(b^2 - 4*a*c)) / 2*a を使う。)
問題の式を移行して x^2 - 10x + 21 = 0
以後公式を使って自動処理すると、x = 3, x = 7 がすぐに求まる。
公式の使い方と平方根をマスターすれば、小学一年生でも解ける。
(-(-10) +/- sqrt(10^2 - 4*1*21)) / 2*1 = (10 +/- sqrt(100-84))/2 =
(10 +/- sqrt(16))/2 = (10 +/- 4) / 2 = 3, 7

(その２)アル フワーリズミの解法(ある解析学の本から抜粋)
根の個数を半分にすると５になる。これをそれ自身に掛けると２５になる。
これをそれ自身と掛けると２５になる。これから平方と結びついた２１を引く
と、残りは４である。その根を求めると２である。これをもとの根から引き
去ると残りは３である。これが求めていた平方の根であり、平方は９である。
根の数に新しい根を加えてもよく、和は７になりこれも求めていた平方の根で
あり、平方自身は４９になる。

平均的な現代の人は、この解法で任意の二次方程式を解くことができるの
でしょうか？
この解法は確かに 記号式で表現された解の公式をそのまま文字表現しただけです。
だが、記号式という道具を与えられない場合、論理思考能力が無ければ
二次方程式すら解くことができないでしょう。

以上は知的道具の使用がもたらす損失(論理思考能力の欠如)の一例を挙げてみました。
幾何学は難しいと感じたプトレマイオス一世が「幾何学を学ぶ近道はないか」
とユークリッドに尋ねたのは、私はあながち無理もないことだと思います。
デカルト以前には代数学と幾何学は別個に扱われていたから、幾何的な問題を証明する
(証明文を構築する)のは現代人が考えるよりも難しかったからです。

3D空間を、高速に描画するための解法

(その1)頂点バッファをUINT_MAX+1(==65536)と取る方法
DrawPrimitiveは、呼び出す回数が少ない方が、高速と考えられます。
だから、出来るだけ大きなバッファを、取るべきだと考えます。

(その2)オクトリツリーの方法
私は、この方法に疑問を、感じていました。
何で、この方法が高速に、描画できるか、分からないからです。
私が、分からないものは、使いたくありません。

UINT_MAX+1 == 65536 派の人、登場ｗ

..........
これでわたしは確信が持てました。

私は、もう(ここには)書き込まないと言った自分の誓いをやぶり、
あえてここに再三書き込みました。それは、私にたいして悪口雑言を重ねる連中
が、私が想像するとおりの人種であるのか？もうすこし決断を伸ばす必要が
ある、と思い留まったからです。

私はおっちょこちょいなところがあり、BBSをBSSと打鍵してしまったり、
UINT_MAX を INT_MAXと間違えて使いながら一週間ぐらいソースコードに
放置していることも、ないわけではありません。
ですが、そのようなことを取り上げて非難を繰り返すことのメリットは
わたしには全然理解できません。

わたしは、あなたたちにも期待したかったのです。
BBSに、2chには、今でも期待していますが。
(私を攻撃しつづける)あななたたちは、少なくとも、私の期待した人物では
談じてあり得ない、と言うことはこれで確信しました。
たとえ(何人集まっても何ひとつ大きなことができない)三下のザコ集団であっても、
知的な部分においてはそうではないかもしれないな？
という私の期待はもろくも外れたわけです。

私は、この連中を諌め聞かせる能力が足りなかったことを恥、
以後、本当にこのスレッドには書き込みません。
お騒がせしました。以後仲良くマターリお過ごしください。

16bit の環境を未だに強いられているのって……哀れ

>>494
> 以後、本当にこのスレッドには書き込みません。

今度こそ約束守れよ。

すでに約束を破っているわけで、誰も>>494のことは信用していない。
アホの上に嘘つきだし。

>>495
UINT_MAX + 1 は普通 0 だろ？
16 ビットとかいう話はあまり問題じゃないよ。

>>498
というか long long a = UINT_MAX + 1; は 0 じゃないですから、型に制限される話かと

((long long)UINT_MAX) + 1 で

どちらにしても int が16bitの処理系なんていまどき使わんだろ

これで壮大な釣りでした宣言が出たら降参してやる。

>>499-500
UINT_MAX + 1　と　((long long)UINT_MAX) + 1　は別モノだろー。
UINT_MAX は unsigned int で 1 は int だから自然に long long に格上げされる筈ないから
明示的にキャストする必要がある。
それを踏まえての発言なのだが？

>>503
少なくとも>>494氏の問題はそんなところにあるのではない。

自分の欠点が分からないというほど厄介な人間は居ないな

intを16bitと思っちゃうって
もう結構おっさんなのでは…

INT_MAX + 1 のまちがいだったとしても 65536 はありえん

今って19ビットくらいだっけ？

69 蟹座

っていうかプログラム内じゃなければ UINT_MAX = 65535 で +1 して 65536 ってのは理屈として合うけど、
そもそも UINT_MAX = 65535 の処理系を俺は最近見てない

>>492
だからさぁ。
結局、比較するもののがわかってないからそんなトンチンカンなこと言っちゃうんだよ。
DrawPrimitive一発で描画して速いのはあくまで同じポリゴン数を描画したときなのよ。わかる？

例えば、全く同じポリゴン数を計算してたとしても画面に描かなきゃ処理は少なくなるよな？
この場合はピクセルフィルレートが低くなるから速くなるよな？
これはＺバッファを使って前から描画する技術とかがそうだ。
Ｚが手前にあったら書きこまないって処理だな。
俺の経験からいってDrawPrimitive一発描画なんかよりもずっと重要な最適化技術だ。

次に君が否定したオクトツリー。
これはさ、そもそも画面に入らないものをあらかじめはぶいちゃいましょう。
って最適化技術。
ゲームってさ、ある世界があってその内描画に使う空間ってほんの一部じゃん？
だから描画に必要な部分だけ計算をしましょうね。ってのが根底にある考え方。

DrawPrimitive一発描画ってのはグラボが計算しやすいってだけで
たくさん描画すりゃそれだけたくさん計算しなきゃならないんだよ。
要は最適化技術としてはもうあまり重要じゃない。つーか大して速くならない（と俺は考える）
もちろん、計算対象から完全に除外しちゃうオクトツリーのが最適化としての優先度は全然上。

まあ、だらだら書いたけど、実用性は

他の最適化技術＞＞＞＞＞＞＞＞とても越えられそうにない壁＞＞＞＞＞＞＞＞DrawPrimitive一発描画

ってことよｗ

>>511
俺が書いたネタなんだから真面目に読むなよｗ

>>512
いや、一連のレスではあいつはそういう主旨のことを言っていた。
DrawPrimitive一発描画なんてたいして速くならないってことを遺伝子レベルですりこまなきゃ駄目だ。

だから 492 は別人がネタにしてるんだって
お前も 3D"Wire" 並みにやばいぞ。

>>514
それはわかってるよ。
だから

>いや、一連のレスではあいつはそういう主旨のことを言っていた。

この文をつけてあるんでしょ。

名前：デフォルトの名無しさん 投稿日：2005/06/01(水) 21:45:23
>>492
だからさぁ。
結局、比較するもののがわかってないからそんなトンチンカンなこと言っちゃうんだよ。
DrawPrimitive一発で描画して速いのはあくまで同じポリゴン数を描画したときなのよ。わかる？

なんだこの伸び

左手座標系用の移動行列とかの変換行列を
右手座標系に変換するのって、行列を転置するだけでいい？

>>518
リファレンス嫁
むしろ高卒なら自分で導出できるだろ…そのくらい

つまり結論としてBSEはウイルス病とは違うのですね。

>>520
BSEは現在のところウィルスではなく異常なプリオン（タンパク質の一種）が原因である
という考え方が主流ですが感染の詳しいメカニズムはまだわかっていません。

分かったみたいだよ

http://pc.watch.impress.co.jp/docs/2005/0426/kaigai174.htm
を読むと、GPUで汎用の計算が出来るようなるようですが、現行のGPUではどうなんでしょうか？
例えば、ビットマップにエフェクトをかけて、その結果を取得するというようなことは出来ないのでしょうか？
ビデオカードのメモリに書き込む方法はわかるのですが、演算結果をビデオカード側から取得することは出来ないのでしょうか？

＞演算結果をビデオカード側から取得することは出来ないのでしょうか？
出来るがクソ遅い。基本的に一方通行に最適化されてるから。

知ってたらでいいんだが。
DirctMusicでMIDIファイルを任意のDLS音色で再生させる方法って、なんか落とし穴とかある？

その場合、セグメントにGUID_StandardMIDIFileをSetParamするところを、GUID_ConnectToDLSCollection
で指定するんだか、これをやると、MIDIファイルをローダーで読み込んで作ったセグメントだと再生されないんだよね、

その後、再生までエラーも出ずに、無音が再生されるので、音色番違いの問題くさい。

んで、このツールだと、DLS用意して、GMマッピングモードをONにすれば
俺のやりたかったことが出来てるんだよね。
http://www.memb.jp/~dearna/iblend/feature.html

んーDLS音色って、普通にコレクションからロードすると、チャンネル何番に
マップされるんだｋっけ？GMマップにマッオウさせる方法とか知りたいんだが・・

ちなみに、データーの読み込みはDMUS_OBJ_MEMORYをローダーに指定して、
全部メモリから読み込ませております。（だからAutoDounloadとかの問題じゃないと思う。）

ただ気になるのは、メモリ読み込みにしたローダーってバグとかあったような気が・・・
Dx6.1時代の話ですが・・・いまはＤＸ9ＳＤＫでIDirectMusic8インターフェイスを使っています。

えー・・勝手に自己解決しました。

とりあえず、midファイルでDLSコレクションを使うならば、ローダー(IMusicLoader)は
自作したほうが良いということです。

なぜならば、ローダーはmid->sgtファイルの再配置を上手く行えず、
NRPNなど、エクスルーシブを含むトラックの再生が行えなくなります（今回の原因はこれ）

目的の自作アプリは、自前でmidiファイルを吐けるので、ローダーがきちんと変換を行える
データー形式にしてから渡すようにしました。

以上の情報が誰かの役に立てることを期待して、これを書き残して起きます。

では、お騒がせしました。

DirectX8を使って複数のWindowにDirectXで描画しようと思ってるのですが
CreateAdditionalSwapChainでスワップ チェーンを作成した場合
D3DPRESENT_PARAMETERSのEnableAutoDepthStencilをTRUEにすると
深度ステンシルバッファは作成されるのでしょうか？

作成されるとしたらどうやって取得したらいいのでしょうか？

以前、CreateAdditionalSwapChainを使ったときにはそれぞれのサイズに合わせてCreateDepthStencilSurfaceで作り、
GetDepthStencilSurfaceで取得、SetDepthStencilSurfaceで設定したけれど
EnableAutoDepthStencilのことは気にせずやってた。

6月版でました。
ttp://www.microsoft.com/downloads/details.aspx?familyid=69bf704d-cd35-40c4-91a5-aa0e27c8f410&displaylang=en

月刊だいれくとえっくすー

なんでユーザー向けのランタイム更新しねーんだろ

>>529
ありがとうございます
やはり気にせずやったほうが良さそうですね

Resetのところでエラーが返ると思ってたらスワップチェーン開放してなかったorz

X箱 開発環境に躍起になってると思われ。
ベンダ向けに常に最新をリリースしてる感じが、
リリースノートから伺えるような気がする。

でもどうせお前らDirectX9を使う製品なんて作らせてもらえないだろ
関係ないじゃん

容赦なく9.0cですが何か？

ttp://pc8.2ch.net/test/read.cgi/tech/1090723093/l50
で話題になってる登大遊の本って実際はどうなの？

右も左も分からない人にはいいかも
それ以外の人にはﾚﾍﾞﾙが低すぎて意味がない感じ

彼にはDirectX本よりも、SEのUNIX系版を早々に出してもらいたい。

>>538

DirectDrawSurfaceにいったんビットマップを読み込ませると
PC再起動するまではコードの中でビットマップ読み込みをコメントアウト→
再びアプリケーション起動してもやっぱりサーフェスには読み込んだ絵が入ってるんですが
原因&解決法教えてください。

>>540
何か困るのか？

ビデオカードのRAMに残ってるだけじゃないの？

>>540
原因は>>542の通りだろう。ドライバがそういう設計だから。
解決方法はサーフェースの解放前にゼロクリアしておく。

質問させて下さい。

DVからキャプチャした画像に、文字や画像を加えて表示するには
どうしたらよいのでしょうか？
またその合成された画像を、ファイルに保存したいのですが、
可能でしょうか？

よろしくお願いします。

DIB上に展開して文字を上書き。
保存は好きなイメージフォーマットでどうぞ。

>>544
フォトショップ使えとかそういう話じゃねーの？

表示している画面をスクリーンショットとして保存したいのですが、
どうやればいいのでしょうか。

>>547
PrintScreenキーを押せ。
んでペイント開いて貼り付けろ。

>>545, 546
お返事有難うございます。
自分のやりたい事をうまく説明できていませんでした。すみません。

DigitalVideoで動画をキャプチャしつつ、その動画に手を加えて、表示し、
動画ファイル(avi,mpeg等)に保存をするにはどうしたらよいでしょうか？
という質問でした。

度々ですみませんが、よろしくお願いします。

>>549
そんなの動画に手を加えるソフトさがしてくりゃいいんじゃねーの？

自分で動画に手を加えて保存って話ならDirectShowとかそっちの方使えばいいのかなぁ・・・。
はっきりいってよくわからん。

>>549
pinから受け取ったデータをDIBに展開して、DC経由で加工してから、
出力用のpinに送れば完了。

>>548
いえ、プログラム上でやりたいんです。
ちなみに何故したいかというと、ゲームでセーブするときにスクリーンショットを
一緒に保存して、その縮小画像をロードメニューに表示したいんです。

>>552
自分のプログラムならイメージデータを、
自分で好きなフォーマットに変換して出力すればいいだけ。
特に問題になるようなことはない。

>>553
画面のイメージデータはどうやったら取れるんですか？

他人のプログラムがオーバーレイに描き込んでいるわけでも無し、
自分で描いているんだから、自分でとれる。

>>550,>>551
DirectShowを使って、551さんの方針で頑張ってみます。
どうもありがとうございました。

バックバッファならD3Dデバイス作るときにロック可能フラグを指定して
ロックなりコピーなり。
フロントバッファなら、コピーする専用メソッドがD3Dデバイスにあったはず。

>>557
ありがとう

すいません、プログラムもほぼ初心者なんで恥ずかしい質問かもしれませんが聞いてください。

D3DXIntersectを使って３Dのオブジェクトをクリックして分岐させたいのですが、

引数一個目　クリックする対象のメッシュ
二個目　マウスの座標
三個目　↑のｚ座標を変えたもの
四個目　Hit
他　NULL

でとりあえず実行してみたのですがクリックしてもHitが１になってくれません。
やはり他の引数も渡さないと駄目なんでしょうか？

>>559
第2引数pRayPosと第3引数pRayDirはメッシュのローカル座標系で与えなきゃ駄目。
スクリーン座標からローカル座標への逆変換にはD3DXVec3Unprojectを使うとよい。

>>560
なるほど。今までクライアント座標でやってました、、、
ご回答ありがとうございます。

> 二個目　マウスの座標
> 三個目　↑のｚ座標を変えたもの

ローカル座標に変換したとしても、これは間違ってる。

>今までクライアント座標でやってました
D3DXﾗｲﾌﾞﾗﾘが親切設計なせいで厨房大繁殖の悪寒

>>562
常に視点はｘｙ平面に平行なんですが。。。それでもダメなんですか？

>>563
恥ずかしながら大学生なんです。。

ヘルプくらい読もうぜ
pRayPos [in] Pointer to a D3DXVECTOR3 structure, specifying the point where the ray begins.
pRayDir [in] Pointer to a D3DXVECTOR3 structure, specifying the direction of the ray.

>>565
二年前にちょこっとＣ触ったことあるだけなんで
[in] レイの始点座標を指定する D3DXVECTOR3 構造体へのポインタ
っていうのが何かもさっぱり分かんなかったんですよ、、申し訳ない。精進します

凄ぇなBBX
gがウソ教えてら

ヘルプ読ませた方が手っ取り早いな

>>566
＞[in] レイの始点座標を指定する D3DXVECTOR3 構造体へのポインタ
この文を理解するのに必要なCの知識は「構造体へのポインタ」これだけだ
みんなが間違いを指摘してるのは「レイの始点座標を指定する」の部分だ

0.5ピクセルずらすってどういうこと？
ｸﾞｸﾞってﾍﾙﾌﾟも見たけどいまいち分からない
誰か教えてくれ

ピクセルとテクセルの調整分。

レイもわからんヤツが3Dいじるなと言いたい。

>>570
ヘルプの「ラスタ化ルール」「テクスチャ座標」あたりを100回繰り返し読んで
よーく考えれば分かると思うよ。

>>569
それより致命的なのは、>>559の第3引数がdirectionになってないことだと思う。
始点のほうは、カメラ位置でもNear平面上のマウス位置でも大した違いはない。

jun2005 とかじゃなくて、9.0dとか10などの DirectX の次期バージョンって
いつ出るの？何の発表もないし何の進展も何の音沙汰もなし？

ヒント：Longhorn

SIGGRAPHで何か情報出てくるかなぁ

バージョン番号が同じなのに毎月新しい(?)再配布ランタイムが出ている現状は
いかがなものかと思う。

どもす。

Longhorn はもうすぐβ1でるかでないかってところだっけ。
一般リリースの直前に新しいハード機能が発表されて、それがないと
フルに使いこなせないなんてことになるのかな。

SIGGRAPH で情報でなかったらいつになるのかのう。

ノートPC買い換えようかと悩んでるんだけど、CPU も GPU も OS も切り替わり
時期なのかと思うと買い渋ってしまう。やっぱり欲しいときが買い時なのかなぁ

>>578
SDKのアップデートでランタイムの内容変わってるの？

>>579
Longhornは、まだまだ先になるだろうし
ノートPCでまともに動くには更に時が経たないと。
ましてノートで64bitというのもまだ考えられないし、
XPもDirectX9も大分こなれて来た今が丁度買い時だと思うんだが。

まぁ、素人の見解だけどなー。

もうほとんどのゲーム、ほとんどの開発者にゃ、DirectX 9で特に不足はないと思うんだけどな。
WGF2.0で来る大ネタもHDRの正式サポートくらいだと思うし。

・DirectX リリース履歴
　9.0 2002.12
　9.0a 2003.03
　9.0b 2003.07
　9.0c 2004.07
・Longhorn リリース予定
　β1 2005.夏、正式リリース 2006.8〜2006.11？
・モバイル用64bitCPU(Gateway や DOSパラで搭載機種あり)
　Mobile Athlon 64 3400+、Turion64

・DirectX のリリース履歴みると新バージョンがそろそろ発表されてもおかしくない
　時期にきてそうだが、発表されてもグラボの対応はまだまだ先になるから気にする
　必要ないかも？っつーか、>>582氏の言うWGF2.0がくるまで発表なし？
・Longhorn に関しては2003年に DirectX7.0 でベース機能、9.0でフル機能と説明
　されているが正式リリース発表と同時に 9.0d 必要です、とか言いかねない。
　もとより2年前の情報に恒久性なんぞなく信頼性なし。
・Intel は Itanium を推し進めたいのにこけ気味で EM64T に積極性が
　みられないせいかモバイル用途に関しては沈黙を保ったままっぽい？
　64bit に実用性がないのは分かっているがプログラム用にいじり倒したいところだし
　将来的に 64 bit マシンが必要なアプリやゲームが登場するかもしれない。

ということで総評としては64bitCPU搭載のGeFoｒce 6800Ultra つけたノート
が出れば買いかな、と思うものの出そうで出ないこの便秘にも似た症状。
今のノートがスペック的に厳しいのもあってWGF2.0が浸透し始める頃まで待つのも厳しいし
っつーか、ハイスペックマシン買ってもどうせまた2,3年で買い換えたくなるんだろうな、
とかなり苦悩しております。

スレ違いな内容で申し訳無い。

PCなんて2,3年で買い換えだと思うが。
3年以上使ってるPCって手元に無いぞ。

良かったな

何年も待つと、今度は次世代DVDとか有機ELとか燃料電池とかMRAMとか
また判断に迷う材料が増えますぜ。

新しい環境にキャッチアップするのは、安くて融通の利く自作PCでやったほうがいいと思う。
ノートPCはあくまで補助で。それでも今はノートPCのひとつの買いどきだと思うけどね。

それにしても有機ELはなかなか出ないよな。
2006年までにはﾊﾞﾝﾊﾞﾝ出始めてる感じがしてたんだが

>>587
寿命の問題が解決できないでいるようだね。将来このまま消えていくか、それとも
何かのブレークスルーで大化けするかはわからんけど。

そうなんですけどねぇ。
Clevo D900K がまさにわたしのニーズを満たしてるんですけど、
カナダでようやく8月に発売【ttp://web.eurocom.com/EC/ecf_model(164)】、
国内販売はIntelにキャン玉握られてるところばかりでめどたたず･･･
ちょっとだけIntelのことが嫌いになりました。

Mayaで出力したXファイルの読み込みで起きるエラーについて質問です。

CuttingEdge 第9回目 Xファイル ビューア4 スキンメッシュ(改訂版)
tp://www.microsoft.com/japan/msdn/directx/japan/dx9/mxd8.asp
を、最低限の変更で最新のDX-SDK 2005 June でも動くようにしたのですが、Xファイルを、tiny.xから「DirectX Extensions for Alias Maya（6.5）」で出力したスキンメッシュで表示を試みたところ、
エラーで読み込みができなくなってしまいました。（tiny.xでは動作。アニメーションなしのただのボックスのXファイはエラー）

調べてみたところ、
InitializeDeviceObjects内のMesh.LoadHierarchyFromFileでロードをする際にDerivedAllocHierarchyクラスのCreateMeshContainerが呼ばれ、
そこで、Xファイル内に法線ベクトルが入っているにもかかわらず

// 法線がないとき、計算してメッシュに追加
if ( (md.Mesh.VertexFormat & VertexFormats.Normal) == 0)
というところで、法線がないと判断され、そしてtempMesh.ComputeNormals();が呼び出されたときに
「アプリケーションでエラーが発生しました。
-2147467259 (E_FAIL)
at Microsoft.DirectX.Direct3D.Mesh.LoadHierarchyFromFile()」
というメッセージと共にエラーが発生しているようです。

昔のDirectXに添付していたX Expoterのソースをコンパイルして
試してみそ。最近のは動作がよくわからん。

http://www.gdncom.jp/general/bbs/ShowPost.aspx?PostID=32386
まるちゃんに答える必用はない。

>>592
志村、メール欄メール欄

Z=0の位置にある未変換ポリゴンテクスチャのドットサイズを、スクリーン座標とぴったり一致させるような
カメラ位置を求める手法があったと思うのですが、どうやるか触りだけでも教えて頂けないでしょうか。

数年前ぷよーん家庭頁さんの方で、ソース付きでこのやり方を見たのですが、
あのサイトは閉鎖されてしまったのでしょうか。

>>594
射影行列にビューポートと同サイズの正射影とか、ビューポート変換の逆行列とか。
シェーダにビューポートのサイズ渡しててきとーに調節したり。

質問です。
スキンメッシュのXファイルを自前で読み込んでいるのですが
SkinWeightsのOffsetMatrixと
TransformMatrixとが何をするためのものなのかよくわかりません。
お教えください。

対象ボーンからの相対位置。

>>597
ありがとうございます。

対象ボーンからの相対位置というのはTransformMatrixのことでしょうか？
それとも、SkinWeightsのOffsetMatrixも同じだということでしょうか？

また、対象ボーンからの相対位置というのは、そのフレームの親ボーン（フレーム）の
ことですよね？

すいません、解決しました。
どちらの行列も、同じものだったのですね。

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

すいません、もうひとつ教えていただけますでしょうか。
AnimationKeyの種類がHelpに、
0:回転、1:拡大縮小、2:移動...と、なっているのですが、
この3つをあわせてひとつの変換行列を作る方法を教えてください。

基礎からやり直せ

>>600
D3DX関数をよくみろ。
全部行列にする関数がある。
回転（クヲータニオン）→4x4行列
スケール(3Dベクトル)→4x4行列
移動(3Dベクトル)→4x4行列

アニメーション行列 = スケール行列 x 回転行列 x 移動行列　（この並びは必ずしも決まってない）

質問なんですけど
GPUのShaderって長くても別にかまわないのかな？
プログラム実行中どこもストールしなくて毎クロックコンスタントに
ピクセルを出力出来れば、プログラムが1000命令で出来てても100命令でも
処理時間は殆ど変わらないものなの？

>>603
命令によってどのくらい時間がかかるか決まってたような希ガス。
でも、単純に命令数が多いと遅くなるってわけでもないらしい。（前に誰か調べてたよね？）
ここでも厳密に計算するよりは実際に表示してみて平均どのくらいの時間がかかるのか
調べた方が早いみたいな結論が出てた希ガス。
要はよくわかってない。（俺はｗ）

>>603
さすがに1000命令もあると遅いだろうけど、多少のことはテクスチャフェッチ
などのレイテンシに隠れて差が出ないこともある。
要するに>>604も言うようにベンチマークしてみないとよくわからない。

あとGPUによっては命令数に制限があったかもしれん

お答えありがとうございます。
例えば、VertexShader1.xの頃は
命令数の制限が厳しかったから
CubeMappingで法線の正規化とか効果あったけど
2.xとかでは逆で組込み関数使った方が速いかも、とか
法線マップでは普通A8R8G8B8の32bitフォーマットを使うけど
そうじゃなくてV8U8の16bitフォーマットを使ってWは計算で求めた方が
命令数は食うけど、テクスチャサイズが減って逆に速くなるかも、
とかいろいろ考えてしまいます。
やっぱ実測が一番ですかね？
でもベンチ測れるほどシステムが出来上がってないから難しいところです。

今D3Dのフォーマット調べたんですけどD3DFMT_CxV8U8というのがあるんですね。
これに対応してるGPUってあるんですかね？

>>607
なんでそんなところに最適化かまそうとしてるのかわけわかんね。
測ってもいないのに勝手に問題視して馬鹿みたい。
つかえねーやつｗ

>>608
自分は現状でやれる最高のプログラムを組みたいだけです。
それが何か？

トップダウンで最高のものが作れるというのは幻想だな。
最高のものは常にボトムアップで作られる。
まず作ってみることが重要。駄目なら捨ててまた作るべし。

>>609
だったらこんなところで質問なんてしてないでさっさと組めボケナス

ベンチで測って、それで何がわかるんですか？
5FPS下がった、10FPS上がった、で？
自分が知りたいのはその理由ですよ。
その参考に他人の意見を聞きたかっただけです。

極端な話、自分が欲しているのは実際に速いアルゴリズムではありません。
理論的に速いであろうアルゴリズムです。
GPUというのはこういう仕組みになっているので、
"理論的には"こっちの方が速いであろう、という方を選びたいのです。

うはｗアルゴリズムのベンチマークで
FPS計る馬鹿がどこにいるんだよｗｗｗｗ



あ、>>612にいたか

>>612
おまいさんが期待するようなきれいな「理論」は無いんだよ。
速度については基本的にＧＰＵ依存なの。
だから作って試すのが一番確実。
チューニングについてはnVidiaやATIにいろいろ資料があるから
とにかくちゃんと読め。

こういうやってもみないで人に聞いてくる馬鹿（>>603みたいなの）が増えたね。
おそらくGPUを設計した人間ですら実行してみなきゃ結果なんてわからねぇだろうよ。
こういうのにいちいち完全な答えが用意されてると思ってるなら絶望的にセンスが腐ってる。

夏ですから。多少は許してくださいよ
気の短い貴方みたいな人の方が頭悪く見えますよ

いや、外野から見ててそうは見えなかったけど。。。。

>>615
ただやることなら簡単ですよ、エフェクトファイルを数文字書き換えればOKです。
何度も言わせられるが、でもやって何がわかるんですか？
結局何もわからないんでしょう？君もわからない、俺もわからない。
結論はこれでいいです、これ以上の議論は無用です。

>>616
自演？
君は何がしたいの？俺と罵り合いがしたい訳？
俺は君には何の興味もないので
話し合うつもりはない。今後レスはしないで結構です。

↓以下何事もなかったかのように次の話題

↓めんどいのでスルー

↓ぬるぽ

↑ｶﾞｯ

>>618
>でもやって何がわかるんですか？
それを確かめるためにやるんでしょう。
君はやらないから何もわからない。
わからないから的外れなことを言う。
ただそれだけのことなんですよ。

↓はい、次の質問どーぞー。

HALモードではラスタライザ以外でジオメトリ処理もGPU側が受け持つのですか？

>>624
IDirect3D9::CreateDeviceを呼ぶときのBehaviorFlags引数の指定に従う。
D3DCREATE_SOFTWARE_VERTEXPROCESSING
D3DCREATE_HARDWARE_VERTEXPROCESSING
D3DCREATE_MIXED_VERTEXPROCESSING
って奴ね。

>>625
ｻﾝｸｽ。遅かった謎が解けました。

DX7で、Dsoud。
サウンドバッファを、元々あるものをDuplicateSoundBuffer　で取得したものだと、
SetPositionが効かなくなる。

また日本語が不自由な知障が。

DX7で、DirectSound。
サウンドバッファを、元々あるものをDuplicateSoundBuffer　で取得した。
ところが、この複製したものだとSetPositionが効かなくなる。
なぜ？

>>629
頭に障害がある方でしょうか？

あ。３Ｄバッファの取得を、元のサウンドバッファからやってた

>>628,630
見事に放置されてるな。(ﾌﾟ

こんばんは。
質問があります。

ビデオカードのチップセット名やドライバやＶＲＡＭ残量などの
情報をプログラムで取得するにはどのようなＡＰＩを使用すればよろしいのでしょうか？
解説してあるサイトなどの情報がお分かりになる方はぜひ教えていただきたいです。

＃dxdiagみたいな情報を知りたい・・・。

>>633
DirectX

VRAM容量なんかは大雑把な目安としてDirectDraw7を併用するんじゃなかったか。

まず無いだろうなと思いつつ、駄目元でお尋ねしたいのですが
(固定のLVertex、TLVertexに対する)TVertexって存在しますか？
要するにライティングだけ任せたいのですが

法線はどうすんの？

1. ライティングに法線が要るとは知らなかった
2. 特殊な前提を用いている。たとえばローカル座標での頂点座標を正規化すれば法線と見なせるとか。
3. 法線はテクスチャに埋め込み済み

法線オナニー

>>636
そういう無駄な質問をしちゃうよりも、自分が最終的に何を実現したいか？
ということを質問のしょっぱなに相手に伝えた方が上手くいくと思われ。

あーそりゃそうっすよね。法線マップですらないです。あきらめます。サンクスです。

>>640
普通にいわゆるVertexFVFやっていたのですが、
後から自分でもスクリーン座標を求める必要が出来まして、
二度手間だしトランスフォーム済みFVF使った方が良いかな･･･でもライティングがなぁ･･･。
という安易な流れでした。ごめんなさい。

DirectX5の頃は、変換後の座標バッファみたいなのにアクセスできた気がしたのですが

途中で送信してしまった
最後の一行は削りそこねなので無視してください
名前も636=641です

http://www.microsoft.com/downloads/details.aspx?FamilyId=3904B19A-02B9-447B-AB58-C12E2456E9BA&displaylang=en
DirectX 9.0 SDK Update - (August 2005)

つーかもうアップデートやめて一式新しいの用意せぇやな…。

名前はUpdateだけど一式入ってるじゃん

>>645
すげー微妙過ぎるからいっそ９．１、９．２、９．３ってあげちゃってほしい。
つーか、いまって9.0juneで作ってても9.0Augustのランタイムで動くようにできてるの？
教えて偉い人！

>>646
D3DX使ってるとDLLが無いってエラーになりそうな気がする。
そういう意味ではDec.2004あたりのSDKで開発するのが無難。

ランタイムは基本的に9.0cのままだろ。

D3DXDLLはFeb2005以降、バージョン毎に必ずファイル名が変わってます。

MS配布のランタイムは9.0cから不変
DLLはアプリ開発者責任で配布

関係ないけどこんなのあった
ttp://sakura02.bbspink.com/test/read.cgi/erolive/1124446856/

DirectX10改めWGFは、再び改めDirectX10になる鴨。
http://fcj.s18.xrea.com:8080/modules/news/article.php?storyid=1800

>>650
ﾜﾗﾀ

>>650
あのDLL単体で勝手に配布していいのか？
責任とかどうこうの問題？

インストーラでDLLだけ入れる奴あるけど、あの形態は合法なのか？

心配な香具師は漏れのようにDecember 2004 SDKを使おう。ｗ

今そうしてるけど新しいの気になるじゃん
もしあれが合法なら、ちょっとサイズ小さくなるし

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/directsdk/ProgrammingGuide/InstallingWithDirectSetup.asp
このへんだな。
日本語で詳しく書いてあるページもあったけど、なんで消すかな日本MS。

なんかDrawPrimitiveUPが変だ。
UPで描画したオブジェクトだけチラツキが起こるので、絶対ありえないと思いつつも、
D3DUSAGE_DYNAMICなVertexBufferにmemcpyしてDrawPrimitiveしたら解決した。
まさに欝だ氏のう的な出来事だと思った。一体何故だ・・・。

環境はWin64＋GF6600＋nVidia最新ドライバ＋DXSDK August2005。
Win64のnVidiaドライバが怪しい予感はしますけど。
ていうか2ポリの四角形を表示するためだけにVertexBufferとかイヤン。

>>658
変ってＳＤＫのどのバージョンでおかしくなったの？

>ていうか2ポリの四角形を表示するためだけにVertexBufferとかイヤン。
意味ワカンネ。
何が嫌なの？

>変ってＳＤＫのどのバージョンでおかしくなったの？
SDKのバージョンは書いた。

>何が嫌なの？
めんどくさい。
なんで2ポリのためにバッファ作ってロックしてSetStreamSourceして云々とやらにゃあかんの。
しかもDYNAMICなバッファだからResetDeviceとかのイベントフックしたりとかもうね

チラツキが収まることが分かったからUP使わないことにするけど
原因分からないとなんか気持ち悪い。

>>658
同じプログラムでWin32はOK、Win64はNGってこと？
Win32版を64bit Windowsで動かすとどうなる？

>>661
32bitコードを64bit Windowsで動かしてこの現象です。
Win32で正しく動くかは別のPCでテストしてみないと分からないです。
とりあえず仕方ないんでVertexBufferを逐一作っていこうかと

アクションゲームを作ろうとDirectX9 AppWizardを使ってプログラムの雛型を生成しました。
メニューバーは必要ないので、生成するとき「Menu bar」のチェックを外しました。

実行してみると、メニューバーは表示されないのですが、AltキーやF10キーを押し、
カーソルキーの上下を押すとシステムメニュー（移動、サイズ変更、最小化、最大化、閉じる）
が表示されてしまいます。
これを表示させなくするには、ソースをどのように書き換えればいいんでしょうか？よろしくお願いします。

>>663
ウインドウスタイル

台形のスプライトを表示したいのですが、
単純に下のようなコードの場合、テクスチャがゆがみます。

m_pd3dDevice->SetVertexShader( D3DFVF_TLVERTEX );
m_pd3dDevice->SetTexture( 0, pTexture );
m_pd3dDevice->DrawPrimitiveUP( D3DPT_TRIANGLEFAN,2, v, sz );

どうしたらゆがみのない台形スプライトが描画できるのでしょうか...
ピクセルシェーダーを使えばできるのでしょうか？といってみるテスト

>>665
長方形（正方形）のスプライトを斜めから見たのと同じように透視補正済みでマッピングしたいなら、
TLVERTEXの第4座標成分（rhw = 射影変換後のw座標の逆数）を然るべく設定すればよい。

　　　A　　　B
　　 ／￣￣＼
　／　 　 　 　 ＼
C￣￣￣￣￣￣D

上図の場合、辺ABが辺CDの1/3の長さだから、CDよりもABが3倍遠くにあると見なす。つまり、
　　[頂点A,Bのrhw] ： [頂点C,Dのrhw] ＝ 1 ： 3
になるように適当にrhwの値を設定すればよい。

>>665
てゆうか、台形スプライトなんて必要にせまられた時点で負け組。

2Dシューティングでそんなのが必要になって悩む時点で
設計を間違ったと気づけ

そもそもスプライト自体要らない

>>663
俺も、それができず結局、初期化プログラムを自分で書いたな
でも、tab+alt切り替えで落ちやがる諸刃の剣。素人にはお勧めできない

PowerVR(ry

>>663
CreateWindow()でWS_SYSMENUを含まないウィンドウを作れば？
WS_BORDERだけとか。

ALT+TABで落ちないようにするのってめんどくさい。
Windowsの問題だろう、アプリ側にリソース解放＆再生成
させてんじゃねえと言いたくなる。ビスタﾀﾝではその辺
マシになってると期待。

D3DPOOL_MANAGEDが使えるのってごく一部だからめんどくさいよな

>>674
極一部じゃなくて、ロストには
D3DDeviceそのものが吹っ飛ぶときと
なんか中途半端に生き残ってるときと２つあって、
前者の場合はPOOL_MANAGEDで指定したものとか関係なしに吹っ飛ばすから
結局、復帰は自前でやらなきゃ駄目。

ん？
Alt+Tab で D3DDevice そのものが吹き飛んでも、POOL_MANAGED 指定したのは生きてたと思ったけど。
それとも Alt+Tab のは後者のタイプなのか？

>666
おぉ、ありがとうございます。
rhw値は奥が小さく手前が大きいということでよろしいですか？
値の範囲はさじ加減でしょうか。。。いろいろ試してみます。

>>677
ちゃんと射影空間を理解すれば値はおのずと求まる。
数学勉強するのが面倒だったらさじ加減でもしてろ。

>>677
射影行列をよく観察して、変換後のw座標が何を意味するのか自分なりに考えてみろ。
rhwはその逆数だ。

>>678-679
同じ偉そうなのでも、678はまるで中身が無いなｗ

nemui

>673
100%裏切られる期待って虚しくないか？

そういやVistaはDirectXが新しくなるんだっけ？
なんか今までと互換性はあるけど、今までの書き方だと遅くなる、と
どこかで見たような。

>>683
ビスタではそもそもWGFになるはずだった。が、名前を変えてDX10になるそうな。
だからDirectXという名称は継承したが、APIは全部変更。
DX7,8,9はエミュレーションレイヤで動くから互換性あるけど遅いヨ♪ていう仕様。
まあつまりあれだ、またMSは素人を騙すようなことやってるって事よ。

ひとつの会社の都合でコロコロ変えられる仕様、
まだ使えるのに勝手にサポートから外され、強制超人墓場、
皆で共有をしているが故に、微妙に違う兄弟で溢れかえって収集がつかない
どっちがいいのか、どれもよくないか、ベストなのは全て捨てて別な道を選ぶって

世の中、保守性とか互換性ばっかじゃん
そうじゃない世界もあるってことを教えてくれたDirectX・・・
そのまま突き進んでくれ

>>686
そういうからには、やっぱDirectX10の為に
WindowsVista+VisualStadio2005買うの？
おいらはごめんだにゃあ

MSはライバルがいないから好き勝手やるんだよな。

クライテリオンはミドルウェア路線に逃げたし、
インテルは早いうちに死滅したし、
ボーランドはフリーウェアになったし、
その他は細々と食ってる状態。

>>687
MSDNでも入ってりゃ普通にいると思うんだが。

>>664 >>672
情報ありがとうございます。
アイコンと右上のボタン群がも表示されなくなってしまいますが、
WS_SYSMENU をつけないでウィンドウを作ってみます。

最新のってDirectShow無いんだっけ？

WGFの仕組みでALT+TABが問題になるとは思えんが……。
そもそもリソース解放しないんだし。

問題になったりしてな。OS も DirectX を使うってだけで、ゲームをフルスクリーンにすると……

>>691
替わりにPSDKServer2003SP1に含まれる

WGFじゃなくてDirectX10で
Win32OSをサポートするんだったら
依然ロスト残りそうだなぁ

>>695
なるほど、だからWGFからDX10に名前変更したんだ。
「旧DXのクソ部分も引き継ぎますからっ」て。

http://www.thezbuffer.com/articles/280.aspx

と、言うことらしい。

>>697
ヨタ話、じゃないだろうなそれ。。。

>>697
"DirectX 10 is the name of the game"っていきなり何のこっちゃと思ったら、慣用句だったのね。

name of the game
一番肝心な＾点［こと］、最重要点、主目的、本質、核心、要点、肝心なこと、問題の最も大事な点、実情
【語源】ゲームの名前には「一番大事なポイント」や「肝心となるもの」が含まれるところから
【用例】 The name of the game is making money. : この世はすべてお金よ

よくわからんなあ
結局DirectX10はWindowsXPをサポートするのか？
DX10用のドライバ入れればOKなのか？

> No more DeviceLost
うそくせー。俺は絶対だまされないもんね。

　　 　 l'´￣`l￣￣￣￣￣￣￣￣￣￣￣｀l
　　　　|　　　|　u　　　　　　　　　　　　　 　 |
　　　　|　　　|　　　　　. 　 ＼　　 '／　 　　 |　　はああああー
　　 　 |　 :J |　　 　　　　 ‐ｰ　 くー　　　:　|
...　　　|　　　|　　 J　　´ﾟ　 ,ｒ "_,,>､ ﾟ' 　　 |　　ヤパーリ、ryokoたんの穴は
. 　　　|　　　| 　 　 　 .　　 ト‐＝‐ｧ'　　　　|
. 　 　 |　　　|　　　　　　 　 ` ｀二´' J 　　 |　　　シマリがいいYO〜！！
..　　　|　　　|　　　 　 　 　 　 　 　 　 　 　 |
　　　 |　　＼ 　 　 　 　 　 　 　 ＿＿ 　 　ﾄ、
　　　ミ 　　　＼　　,.ミ'´￣￣｀`　　　 ｀ヽ､| |
((　　ﾐ　　　ミ　 ＼'　　　　　　　　 ､ 　　　ヽ|　　　　　　　　　　力
　　 ミ、　　ﾐ　　　 ＼ 　 　 　 　 　 i.　　 　 ﾞ、　　　　　　　　　　　勹
　　　|　　 ミ、　,'　　　　　　　　　　　　　　　 l
　 　 Ｌ.＿__|＿ l　　　　　　　　　　　　　　　　l　{　　　 -─-　､
　　　 　 |　　　 l　　　 -、　　　　　　 　 ヽ　　　,. '´　　　　　　　ヽ
　　　　　| 　 　 ! 　 　 　 ヽ　　　　　　　　 ヽ ,.'　　　　　　　　,、　 ヽ
　　　　./´￣`V　　　　　　,ヽ､　　　 　 　 　 ,'　,'　 ;　,.　 ,:　, ハ :,　, i
　　　 /　、　　|　　　　　 /　 ､`ｰ　　　　　ノ!　;　: ; /_'／./_/　 Li_l　 !
　　 ./ 　 i　　 | 　 　 　 /　　 ヽ　　 ヽ 〃 /　 |　;:｢ ＿___...　　　　ﾘjリ
　　 !.　　　　　!　　 　 /　　　　 ヽ　　 {{　/ （｀|　il|　＿_..　　　｀￣lﾉ i　Σ
　　 ｀ー‐ゝ、 '　　　 /　　　　　　ヽ___,.-‐'"⌒ﾞ|　!|　°,,,　　,　￣/,: ハ
　　　　　　　`ー--‐'　　　　　,. -‐'"´　　　　　ﾘi从＿　　 、　'''ノ_:_ﾉ　ヽ
　　　力　　　　　　　　　 ／"ー─------＜二／　　´ヽ､-＜r"／,ｰ､ 丿
　　　　　勹　　　　　　{ 〈　　　　　　　　　　　　　　　 )､ Y　 ｀ゝ(_/_/./'
　　　　　　　　　　　　　} `ー----------─一--‐'´

ホモ氏ね

>>702-703
わけわかめ

>>703
まさかこんな所で出くわすとはな・・・。
超久しぶり。元気そうで何よりだ。

誰？

流れだけ見ると皇太子じゃね

>>703は皇太子？

皇太子光臨記念下記子

http://www.google.co.jp/search?hl=ja&q=ryoko+%E7%9A%87%E5%A4%AA%E5%AD%90&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

もう何がなんだか
新参者には敷居が高いよ、キモくて

これか…
ttp://d.hatena.ne.jp/ryoko_komachi/about

DirectX初心者な俺でもスレ違いだってことはわかった

>>711
俺が久しぶりと書いた相手はその本人。
俺が誰かは、別に気にしないで貰って構わない。

つまりryokoって人は男なのか。

ﾈｶﾏｷﾀｺﾚ

>>713
では気にしてもいいですか？
……

てめぇ、名を名乗りやがれ！

>>713
すいません、身内話は他所でやってください。

>>717
すみません、自治厨キモイです。

メイン画面は一人称ビューで、
それとは別に俯瞰視点からのミニマップを、メイン画面の任意の位置に描画したいと思ってます

普通にメイン画面を描画した後、
SetRenderState( D3DRS_ZFUNC, D3DCMP_ALWAYS );
をセットしてミニマップを描画すれば楽勝だぜ！

・・・・と思っていたのですが、やってみた所、ミニマップの方は当然、描いた順に
ポリゴンが描画されるため、ポリゴンの前後関係がメチャクチャになってしまいました

ミニマップのポリゴンを毎回Zソートする以外に、何か方法があったら教えて頂けないでしょうか

>>719
ミニマップ部分のZバッファをクリアかしら。
(sz=1.0のポリゴンをZ比較なし/Z更新あり/カラー更新なし)で描画)

ミニマップはテクスチャにレンダリングして、
トランスフォーム済みの板ポリに貼り付ける

あ、半透明で表示する場合は>>721だわ。

ついでにIDirect3DDevice9::Clearが矩形指定できるのに今きづいたわ。
チラシックですまそね。

Zバッファって操作できないという固定観念に囚われてました・・・・
Zバッファだけクリアって出来たんですね

テクスチャによる半透明の方も試してみます
お二人？とも、ありがとうございました

>>719
ZwriteとZtestにも負荷が掛かるので必要のないときはオフにするといいらしいよ

>>725
まぁ最近のGPUだとそのくらい屁の河童だけどな。

どうでもいいことに拘って大して速くなってない典型例だな

>>725
てゆうか、なんでOFFにして早くなると思ったの？
ならないだろ。

Clearするときステンシルバッファもクリアするよう指定すると
処理が速くなる件

D24S8とかなら早くなるかもね

まあ、メモリ読まずにｶﾞｯと塗りつぶせるから速いでしょうな。

そんなドライバ依存なことを自慢げに言われても。

自慢してるように見えた？

自慢、自慢が自鰻自鰻に見えて・・・
無性に鰻が食べたくなった

>>734
病気だ病気。
いますぐ死ななきゃなおんねーよ。

スーパーで中国産ならどこでも一串\380じゃね？
もっと安いところも多そうだな。
死ぬほど食えるよ

中国産か・・死ぬほどって一匹くらい？

一匹は普通に一食分だろ。死なんよ。

>>738
そんなでかいもん出す店で食ったこと無い。
一体どんだけでかい（長い）重箱出すのかと・・・
ってゆうかそこまで食いたいとは思わない。

そういえば鰻って切り身しか見たことないな

>>740
俺の場合はバケツで買ってきて家族でさばいて食べます。
うなぎの頭を木製のまな板に千枚通しで突き立てて固定してさばく。
焼く時は七輪お勧め。新鮮なうなぎなら味付けは軽めに。

そんなに食うと吐きそうにならね？
うなぎってなんかこってりしてるじゃん。
あと、俺は天然のうなぎが嫌い。
骨が太くて非常に食べ難いし、おいしくない。

ここはうなぎの好みを暴露するスレになりました

もう私たちに構わないで…！

鰻だ氏のう DirectX (Part 16)

ここからこのスレはDirectXで鰻ゲーを製作するスレになります

なまず

鯰と鰻はちがう

なに言って鰻鯰

鰻もおいしいが鯰もおいしい
久しぶりに鯰食べたいなぁ

もう私たちに構わないで…！

どぜう食いたい

鰌と鯰と鰻はちがう

「饅」参戦

饅饅に鱚

魥魭魦魳魣魫魨魬魮�A魴魷鮃鮝鮷鯗
魯魸魹鮔鮓�C鮀鮐鮉鮎鮊鮍鮇鮅鮒鮄
鮑鮋魿鮖鮗鮟鮧鮪鮭鮰鮠鮨鮚鮬鮫鮞
鮆鮮鮦鮩�D鮲鮴鯇鯁鯀�E鯊鮹鮼鮾鮿
鯆鮸鯈鯉鯎鯏鯐鯑鯒鯣鯢鯨鯝鯤鯔鯖
鯧鯯鯫鯵鯘鯛鯟鯡鯥鯪鯰鯱鯲鯳鰄鰋
鰕鰐�F鰔鯸鰉鰓鰌鰍鰆鯺鯹鯽鰂鰖鰈
鰏鰒鯿鰑鰊鰘鰙鰚鰞鰮鰥鰭鰜鰪鰤鰦
鰨鰧鰢鰩鰡鰯鰰鱇鰲鰽鱃鱆鰷鰶鱄鰺
鰻鰾鰵鱅鰱鱈鱊鱎鱖鰹鱏鱘鱓鱔鱒鱉
鱗鱚鱛鱠鱞鱟鱐鱮鱣鱝鱧鱜鱩鱪鱫鱨
鱰鱶鱵鱲鱷鱸鱻鱁魛魞魡魪魥鰛鯷鰣

夜の3D 鰻ポリ

なにこの魚スレ

eelいいけどoctoもね
http://www.microsoft.com/downloads/details.aspx?familyid=1C8DC451-2DBE-4ECC-8C57-C52EEA50C20A&displaylang=en

うなぎは置いといて、今回はD3DXのアップデートはないし、いくら新しいもの好きでも必要かどうか見た方がよいね。
http://msdn.microsoft.com/directx/sdk/

まあ、大した更新も無いようだし、話を鰻に戻そうか。

「ひつまぶし」もお勧め

夜のお供に鰻パイといいますが。

>>763
「うなぎパイVSOP」がお勧め。「真夜中のお菓子」だよ。

鰻のAIでも考えてみようか

鰻の表面のツルツルを再現するシェーダー

SSS?

みんな俺様が鰻の話題をしにきましたよ！！

>>766
こないだ出たPS2のドラゴンボール。あれのCGが表面テカテカで
鰻っぽくね？

SS見てみないとﾜｶﾗﾝ

うなぎポリ(*´Д｀)ﾊｧﾊｧ

新SDKも出たらしいのに、なんだこの墓場っぷりは。

英語ドキュメントを読めないのはOpenGLスレと同様です

だってさあ、、XACTもXINPUTも今作ってるゲームに使う予定ないんだもん

次スレタイは
鰻だ食おう DirectX Part16
ですか？

>>775
今のスレタイよりは良いな

1年半ほどプログラミングから離れてて久々にこのスレみました
DirectX10とやらがでるそうですがソレを待ってから勉強再開したほうが良さそうな感じですか？
7,8,9のコーディングでは遅いとか書かれてて勉強しても無駄になりそうでｶﾞｸﾌﾞﾙです

>>777
3D系のプログラミングをやったことないのであればDX9でもOpenGLでもいいから
何か齧っておくのは悪くないと思う。基礎的な部分では役に立つだろうからね。

ありがとうございます！
一応DX8をかじった程度やったのですが
仕事の都合上勉強が出来なくなり最近余裕ができたのでやってみようという次第です
DX9の勉強を始めたいと思います
ありがとうございました〜

>>777
言語の文法だとかライブラリの使い方よりも、3DCGの概念の勉強の方が
遥かに重要だから、X10まで待つのはあまり意味がない。
むしろ1年半ほど離れていたことが致命的。
もう他人から学ぶことがない程度に修得しているのなら別だが。

>>780
他人から学ぶことが無いまでいかなくても、
ほどほど３Ｄつかえりゃ問題ねーべ。

この１年半でリアルタイム3D界隈たいした進展があったわけでなし、問題あるまい。

おれも立派な鰻の蒲焼を表現出来るように精進するよ。

湯気はもうリアルタイムでもいいところまでいくよな

>>756
なんかこえぇ

じっと見てると鰻が浮き出てくる

>>785
今でもバイナリをテキスト化するにはmimeやbinHex、uuencodeなどを使うわけだが、
その昔fishなるエンコーダーがあった。

PC98ユーザーにとっては、ish のほうが有名

そりゃぁ当然。ishがあるからこそ、fishという名前が活きる。

　　　＿＿(^^)　＜ペイピッポォ　新スレおめでとうピー
　　／＿＿　＼
　　|　|　　 |　　|
　 （＿）　（＿＿）

そういえばそんなものがあったな。完全に忘れてたが。
懐かしい。

夏貸しー

　　　　　■■■ 　重 要 　■■■
初心者イビリが好きな人は来なくていいからな！
さっさと巣に帰れ！↓

【C++】 DirectX初心者質問スレ Part6 【C++】
http://pc8.2ch.net/test/read.cgi/tech/1127198808/

>>793
その"巣"まで自分から出向いてきて何を言うか

>>793
騙りでネガティブキャンペーン張るほどとは・・・そこまで暴走せんでも
さすがによそのスレにまで迷惑かけるのは勘弁だぜ

まぁ、それなら大多数の人は行けるわけだが

鰻をバカにする奴には一生DirectXが使えない！
要はスタミナ。

結局のところ　質問スレ≒質問厨隔離スレ

鰻も重要だが平賀源内の功績も忘れてはならない。

奴も今で言うと電通みたいな役割だけどな

白報道は、なか〜まはずれでつか？

要は糸井みたいなもんだろ。

最近はもう DirectX で鬱になったりしないしなぁ
いろいろ不満があるとはいえ基本的に至れりつくせりだし
本気で鬱になったのは５までだろう

では次スレからスレタイは 鰻だ食おう DirectX で。

なまず

なんだかんだでDirectXって結構よくなってね？ と思いつつある。
これでデバイスロストもなくしてくれたら最高だな。ゲイツに恋しそう。

Vistaではなくなるにょ

>>806
ところがそうでもなくなったらしい。
WGF廃止。DirectX10復活。
まぁ、名前だけの事で、中身は一緒なんだが。

http://www.thezbuffer.com/articles/280.aspx

The ZBuffer : PDC2005: DirectX 10 Talks
http://www.thezbuffer.com/articles/284.aspx

>>809

806 が言いたいのは、Vistaでは"デバイスロストが"無くなるにょ
だと思われ。

さぁ、みんなで鰻食ってプログラムだ！！

鰻だ食おうだと誰も来なくなるから
DirectX総合スレ（16鰻）とかで。
ゲ制作のがなくなったし

Direct 3D
http://pc8.2ch.net/test/read.cgi/gamedev/1005293179/
２Ｄ！！のDirectXをやってみるかもな
http://pc8.2ch.net/test/read.cgi/gamedev/1005133911/

後藤たんのGPUの記事とか見ても、ぶっちゃけどうでもよくね？って気分になりつつある。
停滞期だな。

まぁDX10が出るまでは停滞かな。ATIの新しいのもUnified Shaderじゃなくて
ちょっとがっかり。

スキンメッシュに、頂点、法線、テクスチャ座標のほかに、もうひとつテクスチャ座標を入れたいだけなのにできねーーーー
描画すると人間のメッシュが、極彩色のウニのみたいにグチョグチョになってグニョグニョ蠢いてる！キモイ！もうやだ！
CloneMeshでD3DVERTEXELEMENT9を指定してメッシュを作り直すんじゃだめなんだろか・・・

SetFVF

>>818
俺も昔、その問題で悩んだな。Tiny姉さんのサンプル見ても判らなかったので、
pSkinInfo->UpdateSkinnedMesh()でスキンメッシュを適応した後のメッシュを、
更にCloneMesh()で頂点要素を変更して描画することで、とりあえず解決した。
まぁ、毎回メッシュをコピーしないといけないから効率悪いけど。

つーか、日本の書籍でスキンメッシュを誰にでもわかる文章で解説している
解説書やムックは無いものか？
どの本も、スキンメッシュは扱ってないか、MSのサンプル嫁で済ませてる。
実はスキンメッシュを理解している人って誰もいないんじゃなかろーか？
という気になってくる。

下手にD3DXだけで済ますから内部構造が分からなくなる。
きちんと理解しようと思ったら、ファイルの読み込みから描画まで自分でやってみるべし。

>>820
スキンメッシュなんてそんなに難しく無いだろ。
サンプルで十分理解できる。

>>821
それはそうなんだが、１からプログラムを組んでいくと、作成途中で
試すことができないので、出来上がった後バグが出ると、何処が悪いのか
ますます判らなくなるorz

ところで>>818のやりたがっていることを、シェーダで行うのって可能なの？
市販のゲームでは、キャラにノーマルマップ使った凹凸や、返り血の
テクスチャを重ねてたりしているみたいだから、出来るんだとは思うけど。
どっかにサンプルとか無いだろか？

頂点にテクスチャの座標増やせばいいだけでしょ。
何に困っているのかわからない。

>>824
いや、普通のメッシュならXファイルから読み込んで作成したものを、
CloneMesh()やCloneMeshFVF()で頂点要素を変えるのは
簡単なんだけど、アニメーションつきのスキンメッシュは、
その方法では、上手くいかないんだが？
俺の場合、サンプルでいうと、CAllocateHierarchy::CreateMeshContainer()
の中でメッシュを変更しただけではダメだった件。

>>823
途中で確認する場合は、必要箇所をテキストで出してみたり、
データ構成を最小にして、最低限の情報だけで少しずつ組んでいけばいい。
いちいちバグが出るのを恐れていたらプログラムなど組めない。
バグが出たら原因が分かるまでデバッグ。

俺が819にバッチリな回答を書いてやったのに。
ID3DXSkinInfo::SetFVFをちゃんと呼んでるか？

おいおい、スキンメッシュもろくに実装できんのか。
D3DXなんかに頼るからいつまで経っても進歩しなんだYO

21世紀にもなって、いまだ分割モデルで人間を
表示している俺は真の勝ち組

>>829
当然さ兄貴、ブレンドなんて認めないぜ！
かる〜い

>>829
ゲームが面白ければ無問題。
むしろ軽くて好感触。

スキンメッシュで法線ベクトルが無い場合、追加する箇所を、

CloneMeshFVF( pMesh->GetOptions(),
　　　　　　　　　　　pMesh->GetFVF() | D3DFVF_NORMAL | D3DVSDE_DIFFUSE,
　　　　　　　　　　　pD3DDevice, &pCD3DXMesh->MeshData.pMesh );

って変更すると、頂点カラーが使えるようになるのかなーと思ったけど
出来なかったのは何故

頂点の指定方法って、FVFコードと、DirectX 9.0の
頂点宣言の２種類があるじゃん。
２つの違いが、いまいち把握できないので、その日の
気分で使い分けているんだが・・・実際、どっちがいいの？

どっちでもいい。

>>833
FVFコードで対応できない頂点フォーマットの場合は頂点宣言を使う。
レガシ頂点フォーマットを使う場合は好きな方を使え。

時間の無いアマチュアにとってD3DXは必須。
時間無いなら3Dなんてやるなって言われたらそれまでだが

イメージとしてはアマチュアのほうが時間ありそうだけどな。
納期に追われないで好きなものを作るんだろうし。

>>837
アマチュアは本当の現場を知らないんだよ。

時間が無いのではなく作らないだけだということに
>>836は永遠に気がつかないんだろうな。

いやいや、アマチュアは他に仕事があるんだろ
時間が無いのは道理

アマチュアなら別に急ぐ必要ないでしょ。

1日のうち作業にかけられる時間が少ないんだから
総作業時間を減らすか製作期間を長くするかのどっちか。
前者を取るのは何も悪くないし、もちろん後者も悪くない。

>>837
納期がないから完成しないんだよ、普通のアマチュアは。

予想通り永遠に気がつかない>>840

プロ気取りのあなたは随分暇の様でつね

プロは仕事がなければ暇です。あまり続くとプロじゃなくなっちゃいますが。

パーキンソンの第一法則
　　"Work expands to fill the time available for its completion."
　　（仕事は、その完成のために使える時間を満たすまで延長される）

専業主婦や引きこもりが何も生み出さない理由

>>829
甘いな。丸影を堂々と使って恥じるところのない俺のほうが上だ。

　　(　⌒　)
　　　l | /
　　〆⌒ヽ
⊂（#｀д´） 　誰が丸禿やねん
　/　　　ﾉ∪
　し―-Ｊ |l|
　　　 ＠ノハ＠ -=3
　　　　　 ペシッ!!

よくフリーゲーム漁ってるタダゲー厨の俺に言わせれば、
いつまで経っても作品を完成させられないアマチュアが多いのは
ダラダラやってるからじゃなくて細かいところにこだわりすぎて先に進まないから。
逆にこだわりのなさすぎる奴は進歩せずに糞ゲー量産してるので
数を見れば圧倒的にレベルの低いものが多い。

>>836
何に対して時間が無いのかがわからないけど、

切り詰めた時間の中で成果物を上げなきゃいけない場合は、
ミドルウェアやハイレベルAPIの使用はプロにだって求められる話。
予算とクォリティと納期を天秤にかけて計画的に判断するのがプロです。

学習する時間が無い、てのは論外。
プロだって業務以外で学びたい、学ばなければいけない目新しい技術は山ほどあるわけで。

>>848-849
わらた

>>851
天秤にかけられた「時間」（プロの場合納期、アマチュアの場合はモチベーションを維持できる製作期間）
がアマチュアの場合軽いってだけの話だろ。プロがD3DX使うのもアマチュアが自前で書くのも自由

アマチュアは視野が狭い傾向がある
バランス感覚がなく分不相応の手法を好み、押し付ける
しかも思い込みが激しく芸術家気取り

一例）
ハイレベルAPIの利用は「粋ではない」とされる
公開されるソースに芸術性を求める
見てないけど英語で書かれたサイトには凄い技術が書いてあると思ってる

すごい視野の狭さだな

でも日本語に訳されてないﾄﾞｷｭﾒﾝﾄ多いよね。

日本語で存在する情報のレベルと、英語で存在する情報のレベルには、雲泥の差がある訳だが。

どうせ必要とされてないからどうでもいいだろ。

日本の場合は教科書みたら載ってるからわざわざWEBで公開する必要がない

>>853
限られた時間の中で製作を短縮しようと考えるのはプロ・アマ問わず「時間」は等価。
差し引いた時間をクォリティや予算に還元しようとするのがプロ。
絶対的に違うのは「リスク」で、これが納期。

道具は使い道次第でプロは然程に自由は無い。限られた環境で開発を迫られる事は多々ある。
極端な話、選り好みできるのはアマチュアだけ。

>>860自己ﾚｽ
>限られた時間の中で製作を短縮しようと考えるのはプロ・アマ問わず「時間」は等価。
>差し引いた時間をクォリティや予算に還元しようとするのがプロ。
>絶対的に違うのは「リスク」で、これが納期。

これら全ては制作上の進捗ではなく、スケジュール上の話。
スケジュールの上でRMやQAが想定されなければプロジェクトが破綻する一番の原因となる。

>>860
それはプロアマの問題より立場の問題やね

だな
こんな人による様な話をプロアマで区切るのがアフォだな

>>863
自称プロの底辺職業プログラマですか？ｗｗｗ

どこまで話が逸れてるんだか

ちゃんと鰻の話汁！

蒲焼が一般的ですが、美味しい白焼きの食える店知りませんか？

場所は東京でいいのか？

>>864
845ですが何か？

>>869
870ですが何か？

>>867
829ですが何か？

え〜っと……俺はどのレスを書き込んだんだったっけかな……。

逆引き ゲームプログラミング
http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1169-X
3,360円

目次みたらそんなに悪くなさそうだけど何か欠点ある？

>>873

目次に3D関係の項目が無いことに、気づかない？

はじめてゲーム作る人向きじゃない？
まぁ、殆どがネットにあるけど。

>>819-820 >>827
CloneMeshのあと、D3DXSKININFOをSetFVF()の代わりに
SetDeclaration()使ってスキンメッシュの頂点構造を変更できたYo

これでキャラのテクスチャの上に血のテクスチャを貼り付けられると
思ったけど、あらかじめキャラのテクスチャ座標と同じ座標系で
血のテクスチャ描いておけば、頂点構造を変えずともテクスチャ２枚重ねで
解決することに気づいた。

そこまできっちり合わせちゃうなら、テクスチャ自体すり替えるだけで…ｹﾞﾌｹﾞﾌ

Alt+Tab
対応ﾏﾝﾄﾞｸｾ
どっかコピペできるサイトない？

>>877
その方が軽いよな・・・

次の問題は、手とか頭が取れる処理だな。
手や頭が取れたメッシュモデルをあらかじめ作っておき、状況に応じて、すり返るのが
手っ取り早いと思うけど、なんか根本的な解決法になってない気がする。

ゲームなんかで良くある、
一枚絵の上に波紋が同心円状に広がって消えていく処理をやりたいんですが、
これ、どういう計算でやってるんでしょうか？（波紋の部分の画像が歪むやつ）

画面を格子状のポリゴンメッシュに分割して、
物理計算で、各頂点の座標を移動させるか、テクスチャ座標を
ずらしてるんじゃね？

ピクセルごとに歪ませるならシェーダかもね

格子状に分割して歪ませるのは分かるのですが、
その物理計算をどうやってるのかなぁ・・・と。
こういうの参考になる書籍とかサイトないでしょうか？

>>882
量子力学

技術デモを目指したもの以外、みんな物理じゃなくなんとなくそれっぽく歪むだけだろ
メガデモ古典のWaterエフェクトみれば？
EMBMもテクスチャの読み出し座標をずらすだけだし

>>880
同心円に広がる処理は、波動方程式の物理シミュレーションでしょ。
数値計算の教科書に詳しく載ってるけど、
Game Programming Gemsとかにも簡単には書いてある

波紋の部分の画像が歪む処理はEMBM。
例えば水面下が屈折したような画像を水面に映したいなら
"屈折して見えるはずの画像"が得られる視点位置で一旦テクスチャに描画。
それを水面に貼り付ける作業はシャドウマップとかでやる投影テクスチャと同じ原理。
この時に水面の法線とかにしたがってテクスチャの参照地点をずらせばいい。
反射も同様に処理してフレネル効果とかを入れるとそれっぽくなる。

DirectXってクリッピング機能があるのけ？
見えないものは描くなと、どの本にも載ってたから
描かないようにいろいろやったけど
（例１）
　□（２万ポリゴン）

　□（２万ポリゴン）
　↑（カメラの向き）

（例２）
　□（同じ）　　　　　　□（同じ、かなり離れている）
　↑（カメラの向き）

ってやったら例２が軽かったんだけども

カリングとクリッピング間違えた！！！！！

視錐台カリングについて
Part6に書いてあるじゃねぇかｗ
サイナラ

名前欄間違えたけど
反省はしない。

読まず、調べもせず、真っ先に質問ﾜﾛｽ

DrawSubsetを使用して、同じ敵キャラのメッシュを位置や向きを変えて表示しているんだけど
同じインデックスバッファやバーテックスバッファでも、DrawSubsetは呼ばれる度にバッファを
毎回再読み込みしているだろか？

もしそうなら、DrawSubsetを使う代わりに、自分でGetVertexBufferとGetIndexBufferでバッファの
アドレスを取得して、それが現在セットされているバッファと異なるときだけ、バッファをセットし直し
DrawIndexedPrimitiveを使って表示したほうが速くなるかと思うんだが、どうだろ？

>>891
測定してみればいい。

たしか、DrawSubsetとかSetRenderStateって
賢いつくりになっているから、現在の設定と
同じ設定をしたときは、処理を省略するんじゃなかったっけ？

つ　【Instancing】

まぁ、ビデオカードを選ぶわけだし、本当に速くなるのかは知らない。

同じ植物のモデルを一度に全部描画するってやつ？
http://www.ati.com/developer/gdc/D3DTutorial08_FarCryAndDX9.pdf

>>894
>>895
そんな高度な話では無いと思われ

ｖｃから実行したら動くのに
実行ファイルから直接実行したらデバイス作れねぇってどういうこと？
もうリリースとか意味ﾜｶﾗﾝですorz

>>897
お前のコードが悪い

D3DPRESENT_PARAMETERS のメンバが正しく初期化されてないとか。
もしくは

- どこかのメンバ変数を初期化し忘れ
- どこかで配列をオーバーアクセス

をしてるとか。

基礎が身に付いてないな > 897

VCから実行したら平気ってことは、多分カレントディレクトリがらみの問題だろ。

口は悪いが親切なツンデレ898と、
なんか意味のない899の鮮やかな対比！

カレントディレクトリに置いた画像とかロードしてるんじゃないの？

>>897
今までデバッグでビルドしてたんでしょ？

>>897
俺もそんな事あったよ
ファイル読み込みの終端に\0を
入れたのが原因だった。
デバッグモードでは上手くいくのに
リリースモードだと失敗する。

恐らく897の些細なミスが原因じゃないかな。

デバッグモードで成功してリリースモードでバグるような状態のことを不確定性原理という。
http://www.asahi-net.or.jp/~YM4N-YB/Yougo.htm

リリースビルドでVC++からだと起動できるのに、直接実行だと起動できないつーのもあったな。
1バイトの範囲外アクセスだったが。

俺の場合はどちらでも起動するけど、VCからだと
「初回の例外が発生しました : Microsoft C++ exception: char」
とかいういのが表示される。
謎だ。

ここの連中、口は悪いが親切だな。さすが鰻を食ってるだけのことはある。

以後あらゆる質問にツンデレで答えるスレになります。

>>905
ハイゼンバグか。

>>907
独り言はNTEmacsにでも書きなさいよ！

>14.社内紛争の話 - MS編
>MSのOffice開発チームはなぜかデバッグモードを一切使わない
>なぜならリリース後に馬鹿げたバグを出したくないからだ
>(納期ギリギリまでデバッグモードに頼るバグだらけ穴だらけWindows開発チームを皮肉っている)

デバッグモードでバグが見逃されてしまう矛盾
むしろ鬼のように問題点を指摘しまくるデバッグモードに
設計したほうが後々のためには良いのでは

テストはリリースでバグ追いかけるときはデバッグモード
当たり前だろ？

鬼って問題点を指摘してくれるの？

機嫌さえ良ければ鬼は問題点を指摘してくれるよ。

鬼はスーパープログラマー。

>>892
やってみたけど、ほとんど変わらなかった…orz
頂点数が目茶目茶多ければ差が出てくるのかも知れない。

>>894-896
シェーダ3.0では、そういうことも出来んのですか。弾幕とか煙に使えそう。

DirectMusicを使用して、WAVセグメントの指定した位置の音量を調べることってできますか？
音量が一定値以上なら、キャラを適当に口パク、以下なら、口を閉じるって自動的にできるようにしたいのですが。

>>919
WAVデータをどっかから抜き出して出力レベルを調べる、くらいしか言えない。。

DMusicなんてすっかり忘れたから適当なんだけれど、IStreamだったっけ？
それで元のストリームの(デザパタで言うところの)アダプタを作るんじゃないかな。
出力レベルを調べながら、再生すればいいんでないかと。。

私もDMusicで作ってたことあったけど、どうも色々とめんどくさいから、DSoundしか使ってない

>>919
「んーーーーーっ」てでかい声で言ってみ。

>>921
つまり、ちゃんとした音声認識が必要なわけだよな。
そこまでやった音声データから顔の筋肉駆動の論文は見た記憶がある。

いっこくどう

>>920
情報ありがとうございます。いまいろいろ調べています。
メディアプレーヤーとかでも音量をバーで表示したり
しているのでなんとかなるんじゃないかと思っています。

>>921-923
母音にあわせて口の形を変えようとか、高度なことは
考えていませんｗ
自分の耳でいちいちWAVファイルを聞いて、声の出るタイミングを
測るより、プログラムでやったほうが後々楽かなと思いまして。

でも、母音を調べる方法ってのは興味ありますね。といっても
専門家じゃないとわからないような理論使ってそう。

音声と3Dキャラをリアルタイムで同期させてるデモ
を発見しますた　　ん〜ちょっと微妙・・・
http://www.atom.co.jp/bot/voice/contents/index.html

よし、音声の専門家であるオレが答えよう。
キーワードはホルマントだ。第一ホルマントと第二ホルマントで
母音は決定する。それを抽出できればあらゆる言語の母音に
対応する口の動きをつくることができるぞ！！！

・・・・ってそんなことは1980年代から知られていることさ。
まだ完全なものはできてないの！！！ハハハーーー

>>925
Half-Life2でも見てみると良いよ
あれのフェイシャルは音声解析して自動生成してるんだけど
ほとんど違和感ない

あ、ちなみにその機能を使ってゲームのキャラに
So Cold歌わせたPVがある。まじｶｯｺﾖｽ。

ttp://files.filefront.com/Im_Still_Seeing_Breen_v11/;3846080;;/fileinfo.html

なんかどっかの芸人さんの話をするやつもなかった？

口パクなんか適当でもわかんねーよ。テレビアニメとか見てみろ。
クールなフィーチャーを実装する前に、労力対効果というものを考えたほうがいいぜ。


そして俺はついに何もしなかった。

うなぎたんに口パクしてもらいたいﾊｧﾊｧ

>>930
声に合わせて描画したアニメは、迫力あるけどな。

中途半端に声と口の形があってるとアニメファンに
むしろキモイって言われるんでしょ？「アキラ」とか

サクラ大戦は評価いいよ

かみちゅ！もキモイって言われてたな

ゲームだと誉められるのにアニメはNGか

「日本アニメ」のファンは、フルアニメーションを「気持ち悪い」と切って捨てる人たちですから。

その癖作画にはケチを付ける

動画枚数が多いと誉めるんだよな。
お前らリミテッドが好きなのか嫌いなのかどっちかと。

マスコミが報道する｢なつかしアニメ｣は団塊世代に評価がよくて
今ヲタの間で評価の良いアニメはヲタが犯罪を起こしたときに真っ先に取り上げられますから

「消費者」っていう単語を「愚民」に脳内変換できてこそプロって事か

あいつら何もわかっちゃいないんだよ。クロフォード先生もおっしゃってる。

クロちゃんはえらいよ、わかってるのはアイツだけ
評論家気取りの消費者ｲﾗﾈ

君はすばらしい批評家になるだろう、君はよく知らないことについてとてもうまく話すから。
（アンリ・ジャンソン）

一冊の本を作るには三年かかる。それを茶化し、間違った引用をするのには五行で足りる。
（アルベール・カミュ『手帳』）

あなたが五百ページ書いたとする。批評家はそれを題材として五十行書く、
その文章の目的は何よりも、彼があなたよりも頭がいいことを示すことであり、
もし彼があなたの本を書いたとしたら、もっと才能を示しただろうということを言外ににおわせる。
それならなぜ批評家はまず本を書いてみなかったのか。
（ガブリエル・シュヴァリエ）

批評家の言うことを決して聞いてはいけない、これまでに批評家の銅像が立てられたためしはない。
（シベリウス）

現状に対しすなおであれ　批評家になるのは合格してからでよい
（赤尾好夫）

批評家を格言並べて批評