DirectX総合スレ (Part6)

言語はC++
他の言語使ってる奴はいますぐ消えろ

■過去スレ

DirectX総合スレ
Part 1: http://pc5.2ch.net/test/read.cgi/gamedev/1083728025/
Part 2: http://pc5.2ch.net/test/read.cgi/gamedev/1095863432/
Part 3: http://pc5.2ch.net/test/read.cgi/gamedev/1105333209/
Part 4: http://pc8.2ch.net/test/read.cgi/gamedev/1132937938/
Part 5: http://pc8.2ch.net/test/read.cgi/gamedev/1157727402/

■関連スレ
【C++】 DirectX初心者質問スレ Part10 【C】
http://pc8.2ch.net/test/read.cgi/tech/1153831096/
Ｃ＃でDirectX9 初心者の館　２頂点目
http://pc8.2ch.net/test/read.cgi/tech/1103998649/
Managed DirectX vol.2
http://pc8.2ch.net/test/read.cgi/tech/1061285378/
くだすれDirectX（超初心者用）
http://pc8.2ch.net/test/read.cgi/tech/1132965206/

■関連サイト
- MSDN > DirectX
http://www.microsoft.com/japan/msdn/directx/default.aspx
- DirectX Home Page
http://www.microsoft.com/japan/windows/directx/default.mspx
- DirectX Info Lib (デバイス情報のデータベース。すばらしい！)
ttp://www.netsphere.jp/dxinfo/
- BBX(掲示板)
ttp://bbx.hp.infoseek.co.jp/

おつー>>1

結局 ID:bg7PnqAA はグラフィックカードを探しにきただけなのか・・（=´Д｀=）

っつーか、正直おれの方が勉強になった。
最近のチップは2^nテクスチャも作っちゃうのな。

チップメーカーもマイクロソフトも、初心者に優しすぎ。
そして、パフォーマンスを省みないコードが蔓延・・

2^n以外のテクスチャ、な。

わからんのがテクスチャ座標１．０って範囲外なのか？

次スレ立ての相談しないで2^n2^n騒ぎまくった公共心のかけらもないクソやろうは
市んでいい

前スレ1000ﾜﾛﾀ

2^n以外の場合CLAMPしか使えないからパフォーマンスには
大して影響しないんじゃないかね。

あくまで２D処理用って感じがする。

前スレの坊やの場合サンプリングの仕方が間違ってて
WRAP指定で外側参照してるとかじゃないのかねぇ。

D3DXMatrixScalingで縮小したポリゴンにテクスチャをはっつけてるんですが、
自前で縦横半分・1/4の画像を用意してはっつけたらパフォーマンスがあがったんです。
こういう縮小に対してミップマップって働かないんですか？
＃ミップマップの説明を探したら「距離の遠いものに対して」という記述だったもので…

すみません、setsamplerstateのミスでミップが効いてなかっただけみたいです。失礼しました。

インバースキネマティクスで
帯が動く様（例：ワンダの前掛けみたいな）を
作ってみようと思ったのだが
こんなもんでおｋでしょうか？
http://gamdev.org/up/img/8117.zip
キーの上下でＺ移動
終わる時はESC

もしかしてバネとか２重振り子とかで動かすのだろうか

>>12
根元のほうの動きが硬すぎない？
引っ張ってもまがったままだし、止めると先っぽから戻ってくるし。
布シムならCloth Simulationでぐぐればいっぱい出てくるよ。

>>13
クロスシミュレーションは難しそうだったのでスルーしてましたが
４亀にあるＶＦ５の話し見てると
帯はボーン、スカートはクロスシム使ってるみたいですな
IKはモーションの補正に使われてたようで

外国のクロスシムはデモとソースコードがポイとあるだけでよくわからん
数式を説明したサイトを探しまくりんぐ中
ヒントどもでした。

>>14
> 外国のクロスシムはデモとソースコードがポイとあるだけでよくわからん
> 数式を説明したサイトを探しまくりんぐ中

解説が欲しいならGame Programing Gems5にあるよ。

>>15
Gems5に載ってるのですか
しかし、\12,600ギギギ・・・

Gemsシリーズは持ってなかったなそういえば

バネ　オイラーで調べてたら
ウマイハナシさんの所にあったわー

ついでに12のプログラムは消去します。

あらかじめ縮小したテクスチャを用意して貼ると
拡大されてもちろん画質は悪くなるんですが、描画速度は上がりました。
これなんででしょうか？グラフィックでもキャッシュみたいのがあるんですか？

>>18
グラフィックのキャッシュではなくCPUのキャッシュ
CPUのキャッシュに収まるテクスチャが最も高速になる

CPUのキャッシュは関係なくね？
メモリ帯域とテクスチャキャッシュの問題の気がするけど。

>>18
グラフィックチップにテクスチャ用のキャッシュがあるよー
近隣がよくヒットするように変な並び方になってるんだよねテクスチャ

ttp://gamdev.org/up/img/8142.zip
シミュレータできたどーーー
といっても野村ＸＸさんのを改造しただけですがね・・・
先人は偉大

テクスチャ座標1.0は範囲外ですよ。
サイズ10のテクスチャの場合、テクセル範囲は0.05〜9.95まで。

ごめん0.95

>>22
なにか動きが布っぽく無いような・・・
昔作った布シムをage。法線の計算が怪しめですが、何かの参考にどうぞ
ttp://up.img5.net/src/up0700.zip

参考も何もソースがないものをどう参考にしろとｗ
布の動きなら実物見たほうが数倍早いし。

ソースコードが付いてないのは、
>>22 がソースコードを付けなかった事に対する戒めです。
>>22 もソースコードを付けていないのに、なぜ私だけ責められなければ
ならないのでしょう。

うるせーよ！この板にここまで童貞が多いとは思わなかったぞ。

誤爆失礼、、

>>19-21
やはりキャッシュなのですね。色数減らしてキャッシュに入るようにしたりできんのかな。
ありがとうございました。

rk1/UrCBは前スレ1000について何か言うことはあるか。

ん? ちょっとプログラムageただけで何でこんなに突っかかられなければならないのだろう。
ここって、不用意にプログラムageると嫌がられるスレなの?
前スレ1000とか言われても、dat落ちして見れないし。
軽い気持ちでageたんだけど、迷惑だったみたいですね。
プログラムも消しときますね。

>>32
誰も突っかかってないしwガラスのハートだなw

DXUTを使ったプログラムで画面更新間隔の制限をしたいのですが、
皆さんはどのようにして実現していますか？
私の場合、DXUTSetConstantFrameTimeを使ってみたのですが
どうも機能していないようだったので、timeBeginPeriod(1)と共用し
以下のようなコードをFrameMoveコールバックの先頭に配置しました。

static double nextTime = DXUTGetTime() + per;
if (DXUTGetTime() < nextTime)
{
do{
UINT wait = (nextTime - DXUTGetGlobalTimer()->GetTime())*1000;
Sleep(wait);
}while(DXUTGetGlobalTimer()->GetTime() < nextTime);
}
nextTime += per;

一応それなりに動いてはいるようなのですが、1,2フレームの誤差が気になります。
より良い方法などあればご教授頂けませんでしょうか。

マルチメディアタイマーにイベントをセットしてもらって、
描画スレッドでWaitForSingleObjectを使って待ちなさい。

Sleep(time) (但しtime>0)の精度は20msぐらいしかないのでゲームには向かないです。
Sleep(0)はすぐに制御を返します。これを使ってループ回してタイミングをとると
正確な同期がとれますが、CPU使用率が100%になるので嫌われます。

餅は餅屋

あーー
timeBeginPeriod使うとSleepの精度上がるのね。
今さくっと調べてみたら結構Sleepでループ回している人も多いみたいね。

>809 ：名無しさん＠ゲムデヴ ：2003/09/14 11:01 ID:???
>オレは5ms以上時間があるならSleep(1)をし
>それ未満だったらSleep(0)でループしてるよ

>上手く行ってるような気がするよ

こんなの見つけたから参考にしてあげて

夜の間に一体なにがっ・・・！

>>35
なるほと、タイマイベントを使えばよかったのですね
確かにこれは比較しても精度が良いです
どうもありがとうございました

でかいポリゴンの一部を小窓から覗くみたいなことをしたいんですが
全部描画してるもので遅いんです
これは小窓サイズのテクスチャに描画して貼り付ければ高速になるんでしょうか？

でかいポリゴンの意味がわからん。
多量のポリゴンモデルなのか、１枚板の巨大ポリゴンなのか。

すみません、両方です。

>>41
ビューボートを小さくすればいいわ。
ただし通常時と同じパースにしようと思ったら
射影行列の調整もいるわね。

ビュー"ポ"ートねｗ

>>41 こんなんでいいかしら。
http://gamdev.org/up/img/8161.zip

>>42-44
すごくよさげです、ありがとうございます！

CloneAnimationControllerを使おうとするとコンパイル時に
そんな宣言は無いと言われて困っています(´･ω･`)

d3d9anim.h内を覗くとあるし、他の関数は問題なく使えます。
何が原因なのでしょうか？

>>46
呼ぼうとしてるのは、ほんとにID3DXAnimationControllerのインスタンス？

>>47
ありがとうございます。
別のクラスから呼んでました。アホだorz

カラーキー抜きでスプライト表示するとフチがジャギってしまうんですけど
これアンチエイリアスするには自前でフチのα値設定するしかないんでしょうか？

フチだけジャギーだと違うかも知れんけど、サンプラ変えれば直るんじゃね？

g_pD3DDevice->SetSamplerState(0,D3DSAMP_MAGFILTER,D3DTEXF_LINEAR);
g_pD3DDevice->SetSamplerState(0,D3DSAMP_MINFILTER,D3DTEXF_LINEAR);

環境：VS.Net2002 & C++ & DirectX9

自作フレームワークが形になってきたんで、それで試しに一本ゲームを作ったら
プレイ中に幾らか進んだところで D3DXCreateTextureFromFileEx 関数が
D3DERR_OUTOFVIDEOMEMORY エラーを吐きやがる。
ずっと悩んでたが、試しにアロー演算子書いてメソッド名の補完リストを出してみたら
Releaseメソッドが出てきたので、これ試したらエラー出なくなった。

もしかして LPナントカ っていうポインタ型に実体を持たせた後は
とりあえずReleaseするのが常識だったんですか・・・
ゲーム終了時とか「とりあえずこれで終わる時」に消えるオブジェクトはちゃんと消してても
「ゲーム中に何度も書き換える」ものは上書きで元有った奴を書き換えて使えると思ってた（´・ω::;::;;;,

mallocしたものをfreeしないとどうなるよ。
そういうことだ。

>>51
> 「ゲーム中に何度も書き換える」

その書き換え方が問題だ。
D3DXCreateTexture* はその名のとおり新規に作成するのであって、書き換え関数ではない。
Release せずに資源を再利用したければ D3DXLoadSurface* 関数とかを使う。
Release してから D3DXCreateTexture* のほうが絶対に楽だけど。

まぁ置き換えるととかそういうことは割りとどうでもいいんだわ。

確保したメモリはちゃんと解放する習慣をつけようぜってな感じ。

CComPtrでも使え

レスどうもありがとう。
malloc <-> free も  new<->delete もちゃんとするようにしてるんだが
DirectXの方は、windowsプログラミングの経験も含めてまだ浅いので
API関数がメモリをどう確保するのかまだなじめない・・・
頑張ります

【単純にワールド行列をD3DXMatrixRotationXなどで回転させる派】
　利点　→　簡単。
　欠点　→　1フレーム内で何度も回転操作を行う場合は処理が重い。

【XYZそれぞれの回転角を３つのfloat型変数に保管し、回転操作の際はその軸のfloat型変数を
増減させる。値の変化があったら描画直前でワールド行列を作り直す派】
　利点　→　処理が軽い。
　欠点　→　親子関係が入ってくると作りにくい。


私が前者で友人が後者なのですが、皆さんは回転操作ってどうしてます？
普通は前者ですよね？回転操作ってそんなシビアになるほど遅くないですよね？

意味がわからねんだけど・・・

どうやっても最後は行列使うんだから同じコトいってるとしか思えん。
そもそも1フレーム内で何度も回転って1つのモデルを何度も表示って意味ならどっちも同じ事だし。

>>57
自分の好みでおｋ。
それでも気になるなら自分で測ってみればいい、3分もかからんだろ。

処理を軽くするために、
・姿勢を示す単位ベクトルを保持し、描画時にマトリックスにぶちこんでる。
・多間接の場合は親から子の順番で描画し、子は親のマトリックスを掛け合わせる。
いずれの場合も三角関数は使わないし、単位ベクトルも近似的に計算している。

三角関数使う場合はどうするのと聴かれそうだが、
可能な限り多数の描画対象を扱うために、
基本的に三角関数は使わないゲームデザインなので、答えようがない；

もしかして
D3DXMatrixRotationX
D3DXMatrixRotationY
D3DXMatrixRotationZ
でそれぞれ作って掛け算してるってのが重いって事を言いたいのだろうか？

具体的に重さが変わる処理は、どこのことを言ってるの？

>>58
説明が下手でごめんなさい。
例えば1フレーム内で10回の回転操作を行うとすると
前者のパターンでは回転角を現すfloat型変数に対して回転角を10回加減算した後に行列を作成し
後者のパターンでは回転行列の関数を10回呼ぶ事になります。

結果は似たようなもだけどどちらのアプローチが良いか
どんな利点や欠点があるのか、という話です。
>>59さんがいうようにどっちでもいいのかもしれませんが、他の方の意見も聞きたいです。

>>60
>姿勢を示す単位ベクトルを保持し、描画時にマトリックスにぶちこんでる
う、よくわからないです。ごめんなさい。
姿勢を示す単位ベクトルというのは3軸方向へ伸びる3つの単位ベクトルでしょうか？
でもそれだと普通に行列を回転させるのと変わらないでしょうし・・・。

>>61
そうです。私のやり方だと回転操作を行うたびに行列回転をするので重く、
友人のやり方では回転操作はxyz軸を示す3つのfloat型変数に対してのみ操作を行うため、
行列への回転操作は描画直前の一度だけなので比較的軽い。という事です。

長くてごめんね

>>61
その前に、その友人の方法にちょっと突っ込みたいのだが…

XYZ軸それぞれに回転量を持っているとしてだ、
現在の姿勢に対して回転させるときにその友人は
RotationY += hoge;
こんな風にしてるんだよね？

そうだとして、最終的に描画のためにマトリックスに変換するときに
RotationX、RotationY、RotationZを使って行列に変換してるんじゃねーかと憶測しているのだけど、
Coordinate = XRotMat * YRotMat * ZRotMat;
みたいになってる？　ソレだとまず理論的に破綻してるような気が…

もしかして、>57は回転量を持たずに、毎回行列操作をしてるんじゃね？

struct Obj {
void rotateX(float f) { RotateX(m_local, m_local, f); }
Matrix m_localx;
};

つー感じで。

はいはい解読解読。

>>57の前者は今まで行われたX軸Y軸Z軸それぞれの回転の履歴を保存しておき、その順番に応じて適用。
>>57の後者は今まで行われたX軸Y軸Z軸それぞれの回転の角度をそれぞれに積算して適用。
>>60は（単位ベクトル云々で事実上）行列を保持して回転の結果を保存して適用。

>>57の前者と後者は全く違う方法。
>>57の前者と>>60は全く同じ方法。ただし>>57毎フレーム全部再計算している。

で、結局どうなったんだろう。

ところでVC++2005Expressと新しいSDK（June2006とか）でシェーダデバッグってできる？
ググって出てくるサイトで説明されているDirectX Extensions For VS.NETとか見当たらなかったんだが・・・。

無理。2005EEしかないなら、PIXでなんとか汁。

>>68
�d
Standardとかだとできるのかな？

>>57
いってることちがうっしょ？
要は姿勢行列の保持を�@Matrixでしてるか、�Axyzの回転角でもってるかの違いでしょ？
ワンフレームの処理の重さ云々は全く関係無いっしょ？

俺は用途によってモードを変えてる。
Matrix制御モードのときと回転角制御モードのときとあるｗ
もちろんこれを切り替えるときは画面をフェードイン・アウトで切り替える。
どうしても切り替えたときにキャラの動きが「ブキッ！」と変わっちゃうからねｗ

１．�@は座標系を頻繁に切り替えるときに有効（動いてる足場に飛びのる等）
２．�Aは向いてる方向を厳密に判定する必要のあるときに有効（ＲＰＧなんかにいいかも）

�Aで１のことをやろうとすると座標系を切り替えたとき（ローカルＡからローカルＢにチェンジ）に
その座標系での回転角を座標変換後の行列から割り出しにくい（できるんだろうけど疲れるぜｗ）
�@で２のことは俺の知識ではできんｗ

なわけでこんな制御してる。
たしかに他の人がどうやってるのかってのは聞きたいな。

マトリックスから回転角を取得するのはたしかに至難だが、
移動・拡大縮小・回転(クォータニオン)の成分を抽出するのは簡単だし、
回転をクォータニオンで補間するなら特に問題ないじゃろ。

DirectX8の悪しきXファイルフォーマットの行列キーの時にも
移動・拡大縮小・回転に分解してフレーム間のモーション補間してる。

>>71
>移動・拡大縮小・回転(クォータニオン)の成分を抽出するのは簡単だし、
>回転をクォータニオンで補間するなら特に問題ないじゃろ。
え？それって回転角をもたずにどうやって「今どっちの方向を向いているか？」って判定すんの？

例えばいま東向いてるか、南向いてるか、北向いてるかとかって判断するの面倒じゃね？
つーか、やっぱり回転角をちゃんと視覚化できる形にしたいってのもあるしね。

回転角←→姿勢行列

が双方向に変換できない限りモードを２つもったほうがいいと思うんだけど。
これが完璧にできるって前提があればどっちの変換でもいけるけど、
大抵のモデリングソフトはできていない。（できてるように見えてもどこかでできない瞬間がある）

まあ、例えモードをわけたとしても双方向ができないと

ワールド-ローカルＡ(90,0,20)-ローカルＢ(180,0,30)-ローカルＣ(45,0,50)-ローカルＤ(270,80,90)-・・・
ワールド-ローカルＥ(90,0,20)-ローカルＦ(180,0,30)-ローカルＧ(45,0,50)-ローカルＨ(270,80,90)-・・・

ってなったときにローカルＣとローカルＦの関係を比べる必要がでたときにできねぇんだけどなｗ

クォータニオンから回転行列作って(0,0,1)のべクトルを変換すればどっちを向いているかは出るじゃろ

>>74
駄目っすｗ
勉強不足でわからないっすｗ

>>72
行列のほうが、向いてる方向の確認は判別しやすいよ
各ベクトル成分が軸になっているからね

xyzの回転角を使うということは
別の言い方をすると回転方向がxyzに制限されるということであり
その結果向いている方向が判別しやすいと言っても
それは制限したことによる結果であって
データ保持形態の利点というわけではないんです

完全な真上を向いていないなら(0,01)に回転を適用してatan2f(x,z)で角度が出る。
まぁ角度が必要な状況ってのもそうそうないんだけど。

逆にy=1なら真上、y=-1なら、真下を見てるちゅーことになる。

XZ平面に対しての角度ね

>>76
正直なにいってるのかさっぱりわかんね。

上方向をY軸としたときに0〜360で自分の方向を決定できるならその方が楽じゃん。
「行列のほうが方向の確認がしやすい」ってところからそれを誰の視点で言ってるのかわかんね。

スクリプトなんかでも結果は回転角で現在の状態を取得できたほうが便利だし、
少なくとも俺の知識じゃベクトル成分を回転角に完全に変換するのはかなり困難だ。

この辺の前提から俺とあんたでかなり違うと思う。
別にベクトル同士の計算を強引にして「方向がわかります」って話しだけじゃないんよ。
回転角が取得できなきゃそもそも駄目な用途があるんよ。（スクリプトあるときとか）

そこまでわかってていってるのか、ただ、「計算ができます」っていってるだけなのか
まずそこからいってちょっとわからん。

>>79
それは「上方向がY軸」という制限を加えることで
自分の向いている方向が決定できているんじゃないでしょうか


＞スクリプトなんかでも結果は回転角で現在の状態を取得できたほうが便利だし、
これは、自分が現在どの方角を向いているというのを、回転角で取得したい、ということですか？

ワールド座標系でのxy平面での進行方向を確認したいのであれば
正面を表す行成分をxy平面に射影してatan2を使えばいいだけの話です

行列で姿勢を持っている場合、自分の向いている方向はローカル座標系では常に正面です
回転角が必要な場合になるのは、比較する対象がどの方角にあるか、というときくらいじゃないでしょうか

xy平面じゃなくてxz平面ですね
すいませんでした

>>80
それはちょっと安直じゃね？
３回転中の２回転目の判定がほしいとかいうチェックをしたことがないの？

>>82
3回転中の2回転目の判定、って具体的にどんなことか分からないんですけど
そもそも3回転って何を3回転するんですか？　xyz軸のこと？　そして何を判定するの？

>>83
ええー？
この表現で通じないのー。
お前、話し難いー。
ホントに３Ｄでプログラム組んだことあるのかよー。

そりゃ、ありますけど

その発言からなんとか理解しようとするなら
3回転はYawPitchRollのことで2回転目はPitchのことで
判定とは相手の位置の方角がどの方向なのか

こういうことですか？
これで間違っていたとしても
単にあなたの説明不足なだけですよ

>>69
持ってないから断言できないけどStandardも無理と思われ。

一応ソース↓
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=909404&SiteID=1

ローカル→ワールド変換行列の、逆行列じゃだめなのか？

>>85
はぁ・・・馬鹿とは話できないねｗ
じゃあな。

3回転中から2回転目がほしくなったことはないだが・・・
行列からクォータニオンは取り出せるし、直行行列での姿勢もわかるから
計算負荷に目をつぶれば3軸の回転角度も出るしなぁ・・・

>>88
俺も3回転中の2回転という表記を見たときは一瞬3つの軸回転の事が脳裏をよぎったぞ
もちろん君が言いたいのはそういう意味ではない事はわかったが
3回という表記が誤解を招きやすかったり、説明が足りないという印象は否めない

文章じゃ伝えたいことが思ったほどうまく伝わらないのは当たり前だが
それを馬鹿とか切り捨てるのはどうかと思うぞ

>>90
ありえねぇんだよ。死ねよ。

ああ、回転角の定義、というか、どこからの回転角なのかが食い違っているのね。

>>92
はぁ？食い違ってる？
俺にはちょっと考えれば矛盾が見えるような馬鹿な醜態（>>80）晒したことを必死で誤魔化してるようにしか見えないよ。
こういう誤魔化し方を一度でもした奴とは俺は技術的な会話を継続しない。
はっきりいって技術者として不適切。

人に対して偏屈なのは別にかまわないけど、
匿名掲示板のこんなところでまでくだらん曲解使って自分の考慮の無さを隠してるようじゃ伸びない。
技術に対してはいつも素直でいなきゃ駄目。
技術者にはそれが伝わるし、隠せ無い。
１から出なおせといいたい。

どうしちゃったのこの人？

「失敗の原因を素直に認識し、『これは非常にいい体験だった。尊い教訓になった』
というところまで心を開く人は、後日進歩し成長する人だと思います」

松下電器産業創業者　松下幸之助



とりあえずあれだな。仲良くしろやカスども。

九、謙虚に反省せよ　向上へのクッションである

旺文社創始者　赤尾好夫

「これでいいのだ!」

無職　バカボンのパパ　

Microsoft XNA Game Studio Express 1.0
ttp://www.microsoft.com/downloads/details.aspx?FamilyID=a73a7e71-ff41-432d-a0eb-043e904a1905&DisplayLang=en

Microsoft XNA Framework Redistributable 1.0
ttp://www.microsoft.com/downloads/details.aspx?FamilyID=2e136a1f-f187-478c-9da5-aaeb0904782b&DisplayLang=en

それで結局３回転中の２回転目ってどういう意味なの？
理解している人が居るなら後学のために教えてもらいたい。
33d6g8SGは答えなくて良いから。

>>99
マジでわからんの？
例えば、キャラが3回転するとき回転角は0〜1080になる。
この2回転目を判断するには360〜720を判断する必要がある。
これを行列に変換してしまうと、どうやって逆変換かけてもこの0〜360と360〜720というのは判断しようがない。

つまり、>>80で
>回転角が必要な場合になるのは、比較する対象がどの方角にあるか、というときくらいじゃないでしょうか
なんていってるけど、２回転するだけで回転角（またはそれにあたるパラメータ）が必要になるっちゅー話。

お前ら下らない争いになるととたんに元気になるよなｗ

そんな熱くなることじゃねぇよ。万能の回転技法はない、場面に応じて使い分けるもの。

SDK付属のメッシュを見るためのMeshViewについてお聞きしたい。
このソフトでスキンメッシュを読み込んだ時、右下に表示される
Vertの値が、Xファイルに書かれている頂点数と微妙に違うのですが、
これはいったいどういうで何を表しているのでしょうか？
具体的な例を出すと、tiny.xのファイルには、
Mesh {
　　4432;
のように、頂点は4432個と記述されているのに、
MeshViewで読み込むと4884vertと右下に表示されます。

よろしくおねがいします。

>>103
位置座標は同じなんですけどＵＶと法線は別なんですとかそういうのじゃね？
結局、DrawPrimitiveに突っ込む形にしてみないとわからないんじゃねの？

>>103
自分でXファイルを展開して表示するところまでコードを書いてみれば分かる。

3Dｽﾌﾟﾗｲﾄｸﾗｽのﾚﾝﾀﾞ処理は、ﾃｸｽﾁｬ毎で管理して描画したほうがいい？

>>106
３Ｄスプライト？ビルボードだったらモデルといっしょじゃね？

>107
板ﾎﾟﾘにﾃｸｽﾁｬはっ付けている奴です。疑似2D用の。
そっかﾋﾞﾙﾎﾞｰﾄﾞを参考にすればいいのか。ありがとうございます。

あれ？同じテクスチャーが続くように気を配るのって紳士のたしなみじゃねーの？

じゃあ同じﾃｸｽﾁｬを使ってる板ﾎﾟﾘ達を、ﾊﾞｯﾌｧに詰め込めばﾏﾀﾞﾑにﾓﾃﾓﾃ？

紳士の背景に薔薇が咲き乱れます。

過疎って増すが質問。
D3Dで、BeginScene　を実行したかどうかを取得するにはどしたらいい？

static bool fBeginScene = false;

inline HRESULT MyBeginScene(なんちゃら) {
　fBeginScene = true;
　return d3ddevice->BeginScene(なんちゃら);
}

inline HRESULT MyEndScene(なんちゃら) {
　fBeginScene = false;
　return d3ddevice->EndScene(なんちゃら);
}

inline bool D3Dで、BeginSceneを実行したかどうかを取得する(void) {
　return fBeginScene;
}

inline bool D3Dで、BeginSceneを実行したかどうかを取得する(void) {
    return d3ddevice->BeginScene() == D3DERR_INVALIDCALL
}
しかしなんでもないときはBeginSceneされてしまうという罠

>>114
そんなの既に考えたわ。
そうゆう外人系の発送じゃなくて、
ちゃんとＤ３Ｄの初期化処理の内部にフラグとかがあって
BeginScene をフラグを取得ってか、
そういや、BeginSceneを２重に実行するとどうなったっけ？

考えたんならドキュメントくらい読めよｗ

そもそも、そんな判定が必要になること自体が間違い。

すいません、↓のように1MBの一枚のテクスチャを二つのテクスチャステージに設定した場合ってビデオメモリには1MBぶんのテクスチャが確保されるのでしょうか？それとも二倍の2MBぶんのテクスチャが確保されるのでしょうか？

LPDIRECT3DTEXTURE9 g_pMeshTexture;

〜中略(1MBのテクスチャをg_pMeshTextureに読み込む)〜

g_pD3DDevice->SetTexture(0, g_pMeshTexture);//ステージ0では色のみ使用
g_pD3DDevice->SetTexture(1, g_pMeshTexture);//ステージ1ではαのみ使用

久しぶりにDXSDK取りにいったら、
色々変わってるのぅ。
やはりDecember 2006 SDKは様子見だよな？
October 2006 SDKこっち使ったほうが無難だよな？
魅惑のﾋﾞｽﾀなんて糞食らえだぜ。

>>117は非同期処理もしらない無垢なクソガキ

SM1.1切り捨てってなんやねん！！
DirectX8世代(4Tiとか)はゲームするなっちゅーことか！！

>>120
最近グラマになったクソガキなのかもしれないが、
昔から状態確認するためにGet・・・とかIs・・・には頼るなとMSが言っている。
もっともカンファとか行かないだろうから知らんだろうけど。

MSの名言を2つ。
最も高速にレンダリングする方法は、レンダリングしないことだ。
最も高速に状態確認する方法は、自分で何したのか覚えておくことだ。

>>121
>SM1.1切り捨て

まじかそれ。えらい困るんだが。

つーか、1.xピクセルシェーダだけ切り捨てなのね・・・
正直、3.0未満はアウトとかじゃなくてヨカタ
未だにゲフォＦＸ5200なので・・・

SM1.1は制限が多すぎて使い物にならん。
結局2.0の有無で分岐が現実的な線引きになっちまう。

初代箱のSM1.1も専用拡張がされてるしな。

>>120
非同期うんぬんの前に別々のスレッドから同じデバイスに
同時に書き込みを行おうとする事自体がおかしい。

自分のアプリが糞なのも認識できずにマルチスレッドの問題にしようとするぐらい馬鹿なら
スレッドなんか作るなといいたい。

つまり 糞スレ立てんな っつーことだな。

すみません。「D3DXLoadMeshHierarchyFromX」周りで行き詰ってるので質問したいのですが、
症状は、

ビルドは成功します。それでMSVCからF5で起動しても上手くいきます。
ですが、生成された実行ファイルを直に起動すると落ちてしまいます。
デバッガでアタッチしたところ、「D3DXLoadMeshHierarchyFromX」直後で
落ちていました。

「ID3DXAllocateHierarchy」の派生クラスは、サンプルのSkinnedMesh
を引用しています。変更した所は、
CreateMeshContainerとGenerateSkinnedMeshだけですが、
D3DXLoadMeshHierarchyFromX後にどちらも呼び出されることなく落ちるので
そこが原因ではないと思います。

D3DXLoadMeshHierarchyFromX後、４回目のCreateFrame内で
pFrame = new D3DXFRAME_DERIVED;
を処理しようとしたところnew内のmallocでエラーが発生し、
ヒープが壊れているとアナウンスされました。
ファイル自体は読みに行っているので、パスが間違ってるということはないと思います。

読み込ませているXファイルはSkinnedMeshで正常に読み込め、表示されます。(デバイスはHAL(SW vp)です)
似たような症状があったので参考にしたのですが、
http://www.shader.jp/xoops/html/masafumi/cbbs/cbbs.cgi?mode=al2&mo=207&namber=206&space=15&rev=1&page=0&no=0

D3DDEVTYPE_REFでもダメで、D3DCREATE_SOFTWARE_VERTEXPROCESSINGでもダメでした。

行き詰ってしまったので質問させていただきました。
思い当たる点がありましたらご指摘ください。

>>128
きっちり読まずに勘で答えるけど、
D3DDEVTYPE_REFじゃなくて
D3DDEVTYPE_HALはどう？

>>129
やってみましたが、それでもだめでした。
ハイエンドなグラボの友達のPCでもダメだったので
やはりヒエラルキの実装に問題があるのでしょうか。
もう一回ソース洗いなおしてみます。。。
何か気づきましたらまたお願いします。

変更が多くないなら再現するコードを上げたら？

つーかそれはそのままヒープぶっ壊してるだけなんじゃ？

DirectXのバグじゃないのか？

D3DXLoadMeshHierarchyFromXで落ちるってのが納得逝かない。

今まで使ってきてD3DXLoadMeshHierarchyFromXで落ちるなんてなかったし、
SDKのサンプルプログラムで同じファイル読み込んでみりゃ判るんじゃないかね。

どっちみちヒープエラーってVCに言われてるならどっかでメモリのアクセスが間違ってんだろう。

そもそもD3DXのXファイル関係の機能を使うなんて気が狂っているとしか思えない。

つーか俺がこの世に生きている時点で世の中が間違ってるに違いない。

外人さんで似たようなのがいたので貼り。
まぁ、お前がヒープぶっ壊してるんじゃねぇの？という同じような流れのようだが。

http://www.gamedev.net/community/forums/topic.asp?topic_id=376836

4回目で落ちるよウワーン、という辺りが似てて不覚にもワロタｗ

そういやD3DXはSquadもバグってたな

みなさんありがとうございます。
やはりメモリ操作でﾄﾝﾁﾝｶﾝなことをしていました。

エラーが発生したところより前ばかりをトレースしていたのですが、
発生点よりも後ろのコードでのメモリ操作が原因でした。
ヒープを壊すのは初めてなので、まだ実行していない所が原因
になることもあるのだと、とても勉強になりました。

高級言語での統合開発環境の温床でﾇｸﾇｸと育った者としては、
抽象化されて隠蔽されているスタック操作やヒープの動作が
今ひとつよく分からないものですが、
これからはまじめに勉強せねばと思いました。
みなさんありがとうございました。

まだ実行していないところが、影響あるもんなんですか？ｗｗ

今頃突っ込むのもちょっとな・・・

>>136
厳しい競争を勝ち抜いて生まれてきたはずなのにな。

おまえのために干からびて死んでいった精子たちに謝って来い
いますぐお父さんのチンコに額を擦り付けておｋい

DrawIndexedPrimitiveで矩形ポリゴンにテクスチャ貼り付けて
2Dスプライト表示、みたいなことをしたいんですが、
キャラクタを10種表示したいとすると毎フレームで

キャラクタの動きを頂点座標に反映させて
頂点バッファをロックして転送してアンロックして
テクスチャ変えてDrawIndexedPrimitive、

ってのを10回することになるんでしょうか？

最初はそれでいいんじゃないかな

頂点バッファも最初は使わないほうが良いと思うよ

2Dでは頂点バッファは使う意味が薄いと思う

なんで頂点バッファを使う使わないなんて、どうでもいい話に流れていくんだろう？

頂点バッファはそう頻繁に書き換えるものではないし、
そもそもDrawPrimitiveの類の命令は何度も呼び出すなと
リファレンスに書いてあるんだが。
その程度のことも知らない奴がいるのか…

かと言ってまとめすぎるのもよくない

>>149は煽り方が実に拙いなぁ
でも
最初はそれでいいんだよ

まとめるより、一番早いのはそもそも描画しない＝クリッピングではじくって方を覚えておかないと
ワールド上に存在するモデルをすべてまとめようとか頓珍漢なことをやりだす。
描画しない（＝クリッピングではじくこと）が一番早い。これはとても重要なことだ。

>>152
そうですか、で、実際はどうでしたか？

さぁまたまた　2　D　ス　プ　ラ　イ　ト　の話からずれてきましたよ！

>>152
（それくらいグラボに勝手にやってくれるだろｗｗｗ
と思ったのだがグラボごとに実測しないと確証とれないし、
書き込むのやめよう…）

昔自力でポリゴン描いたり、テクスチャーマッピングしようとしたときは、
画面外の描画はスキップしてましたがX68kなので、移植はできません。

DirectXでは車輪は勝負どころではないので、
できれば車輪の再発明は避けようと思います。
スマートなやりかたがあったら是非ご教授いただけませんでしょうか？




で、実際はどうでしたか？

重要だとか発明だとかではなくて描画の最適化における常識。
それらをやった上で速度が出ないのならわかるけど、
いきなり教えろとか言われても、面倒だから他人に教えてもらうような
単なる手抜きにしか見えないなぁ。

常識とはしらなんだ

常識っていってもあくまでD3Dでの話だな。

>>144
板状のメッシュ作ったほうが楽な気もする。
と、頂点情報からメッシュを作れることを３日前に知った俺が言ってみる。

>>155
お前馬鹿なの？
せめて頂点変換まではしないと座標が最終的にどこに配置されるかわからないじゃん。
範囲外なのか範囲内なのか。
だからDrawPrimitiveに突っ込んだもんは全部頂点処理だけはかかるだろ？
その前にはじかないと駄目だろ？
グラボができるわけねーじゃん。頭悪い？

ああ、やっぱりいつのもお方だ。

>>160
OBB、ビューフラスタムカリング。
まぁそれ以前に２Dスプライトの話で座標変換とかありえねぇけどな。

恒例のｇｄｇｄ議論になってきましたね。

てか、マジでDrawPrimitiveに突っ込んだもんが画面内にあるかどうか
頂点毎にアクセスせずに済むと思ってるならあまりの馬鹿さにヒクｗ
ちなみに>>160の話しは３Ｄも込み。

で、実際はどうでしたか？

>>165
そりゃ描画しねぇのが一番早いに決まってるだろ？
やってみなきゃわからんか？ｗ
そりゃおめ重症だろｗ

良くわからんのだが、
どういう人生を送ればDirectXにコンプレックスを抱けるんだ？

>>167
つかなんでそんな無駄にまとめちゃうの？
理解してないからそういう見てて恥ずかしすぎることやっちゃうんじゃん。
てか、別に仕組み理解しなくても関数みてわからんか？ｗ勘でよｗ

>>167
いや、ハナからお前には聞いてないよ？

プログラム以前にコミュニケーション能力の向上が重要であると切に思う。

成長期に何かが満たされなかったんだね、可愛そうに。

両者の言い分の意味が分からん
だれか詳しく解説してくれ

(´･ω･`)＜ええ？マジで言ってんの？

漏れもわからん

どちらもお互いを煽り合ってるからね。どうしようもなく。

バッファにまとめるのと単体で描画していくのとではどっちが早いの？
　　　　　↓
画面外のものは描画しないのが最速なんだよﾓﾗｰ
　　　　　↓
頂点変換しなきゃ画面外かわからないだろﾌﾟｷﾞｬｰ
　　　　　↓
　　　今ここ？

まぁ描画しないのが最速なのはえらそうに語ることではない。
2Dに関していうなら頂点変換もないし、ガードバンドクリッピングで
弾かれるので大して意味はない。GPUキャッシュくらいか？

こういうと3Dではどうこう言いだすが、
そもそもの話は2Dスプライトでの話だ。

どっかの人もウォークスルーもまともに出来上がらんうちからカリングのことを心配してたし
素人を惹きつけるなにかがあるんだろうか

モデルはメタセコイアなりフリーのがあるけど、アニメはどのツール使ってるの？
アレな人は、げふんげふんとでも言っておいてクダサイｗ
フリーのがいいのだが、無いよねぇ？

ググるとけっこうあるようだけど

http://jbbs.livedoor.jp/sports/31203/

>>178
RokDeBoneとかエルフレイナとかは？

>>176
で？そんな少量のポリゴンでなんかまとめるといいことあるの？

>>177
残念ながら別人なんですが、
ゲームプログラマなんてとっくに辞めてほとんどこんなスレ来てないし。
似たような人に似たようなこと言われただけでしょ？
ちなみにゲームプログラムの話題なんて他の掲示板でした覚えも無し。

いやいや身分を隠そうしても私にはわかってしまうのですよ。

バッチ処理ぐらいしかやることのない2Dスプライト話の最中に
まとめるよりクリッピングが大事なんだとあさって向きながら
切り込んでは罵倒を繰り出すアナタは間違いなくあの時の勇者様。

たとえばシューティングとか視野をプレイヤーが自由に動かせない
＋大量のビルボードを一個づつdrawprimitiveしまくりな場合に限って
視野に入ってないエンティティの描画処理を除外するとすさまじい効果があがるだろうな
そりゃもう興奮してどっかの掲示板でがんばっちゃうくらい

エンティティのモデル一個の描画そのものが結構な負荷になっててしかも視野が自由に
振り回せるような環境でfrustum cullingなんてやってもFPSが不安定になるだけで逆に迷惑
そんなのに割ける労力があるならprogressive meshとかoccluder cullingの
導入を検討したほうがいいよ

ほいでもってそもそも最適化とか言う以前にアマチュアの3Dゲーは
なぜかMIPMAP使ってないのがやたらと多い
使ってくださいお願いだから

PCなら大抵ドライバ側でmipmap強制できるから別にいいんじゃない？

途中送信

特にPCは出来る限り低スペックのマシンでも動かすためにVRAM節約したほうがいいし

>>179
>>181
ありがとうございます。
探したらまとめっぽい良い感じのを見つけました。

http://www112.sakura.ne.jp/~kaientai-project/voice/6-4.mp3
バスケのゲーム作れるＰＧいない？いたら、メールくれ。

ただ今、鋭意開発中。セブン〜エアガーデンへの招待〜
http://www112.sakura.ne.jp/~kaientai-project/seven.htm

企業ってのは利潤の追求が最終的な義務であり責任でもあるわけで…。
給与の支払いによる支出が原因で、本来の企業活動ができないというのは
本末転倒であって、経費以外の支出はあってはならないんだよ。

今の日本には、自分ことしか考えられない自己中心的な一般人が多くて、
給与額の増大による支出が原因で、経営が圧迫されるケースが多いし。
このまま一般人を野放しにしたら、本当に日本の将来が危うくなってしまうよ。

誤爆失礼

Direct誤爆

>>184
視野が自由に振り回せるならなおさらはじいたほうがいいじゃん。
例えばサッカー場みたいなモデルをまとめて一つドスンとおくよりは
いくつかに分割して、視界に入るもんだけDrawPrimitiveしたほうがあきらかに速いよな？
つーか、モデルを１つに固めたらあんまり遅くて動かなかったけどな。

>>192
俺の場合はサッカー場みたいな土台になる部分は1モデルをドスンと置いてそこに生えてる草木なんかを視線との内積で処理からはじくかはじかないかを決めてるなぁ。

まぁサッカー場に木は生えないけど。

>>193
グランドに木の生えてるサッカーゲームやってみたい。

>>185,186
OK貴様には死ぬまでmipmap使わないことを許してやる
絶対に使うなよ

何でファビョってるのか知らないけど俺は普通に使ってるから

ミップマップ使うより、ミップマップなしで異方性フィルタのほうが数倍きれいなんだけどな。
ミップマップは異方性フィルタがない＆テクセルレートのない貧弱環境用だな。

>>192
そのサッカー場のモデルをみせてごらん

>>197
＞数倍きれい
ミップマップなしで異方性フィルタ と
ミップマップありで異方性フィルタ を比べて言ってるの？

最適化のことを言ってるのにテクセルレートのない貧弱環境用とか言われてもこまる
節約できるところはどんな環境でだって節約したいんだよ他にやらなきゃならないことが
いくらでもあるんだから

同次座標x,y,z,wのwって何を意味してるんでしょうか？
なんかテクスチャを伸ばすような感じに利いてるような気がするですが。
たぶん手で設定するようなものでなく行列演算で設定されるもんだとは思うんですが、
意味は理解しときたいと思いまして

(x,y,z,w) = (x/w,y/w,z/w,1)

すみません
LPDIRECT3DDEVICE9で作成したデバイスのサーフェイスをLPDIRECT3DTEXTURE9に
コピー（というかレンダリング）したいのですが、どうやったらいいのでしょうか？

IDirect3DDevice9::GetRenderTarget() でデフォルトのサーフェイスから取得して
IDirect3DSurface9::GetContainer(IID_Direct3DTexture9, ...) でテクスチャインターフェイスを取得しようとしても
E_NOINTERFACEになってしまいます。

バックバッファからテクスチャにレンダリングするよい方法はないでしょうか？

>>202
・バックバッファからGetRenderTargetでサーフェス持ってくる
・テクスチャからGetSurfaceLevelでサーフェス持って来る
・StretchRectでコピー
これで駄目かな？

ってか、Windowsならバックバッファからテクスチャに持ってくるよりは
先にテクスチャをSetRenderTargetで設定してそいつに書けば良い気がするが
それじゃ駄目なんかね

>>203
ありがとうございます！
やってみます！！

次スレ立ってることに2ヶ月間気付かなかった俺

教えて先生。

しばらくWindows開発から離れてたら、噂には聞いていたけれど DirectDrawが無くなってた。
ちょっとウェブめぐってみたんだけど、あくまでも3Dゲーの中での2D処理用な気が。
2Dゲーを作ろうとしてるんだけど、DirectGraphics(DX9)で作るべき？

ちょっと　とっかかってみたけれど、今までバックバッファに描いてたのを
テクスチャに描くようにしてD3DXSPRITEで表示…って これじゃすんげー遅くなりそう。。。

自己解決です。
動的にテクスチャをいじるのではなくて、レンダリングターゲットの指定が出来るのですね。
(DirectDraw時代より冗長な気がしますが) トライしてみます。お騒がせしました。

>>206,207
バックバッファに描くという方法を考えてたなら普通にGDIでやるべきじゃないか？

そうじゃなくていわゆる昔ながらのスプライト（矩形の切り張り）がやりたいなら
４頂点の板ポリ使った方がハードウェアアクセラレーション効くんで断然速いよ。
半透明も回転も拡縮もグラボにやらせるほうがいい。

なんで3Dの中の2Dとかややこしい事思ったのかしらんが、
ビューマトリクスを平行投影（D3DXMatrixOrtho系）にすれば
座標で悩む事もない。

そのﾀｹｲｼｹｲｽｹって中国人こそ死ぬべき

Microsoft DirectX SDK (December 2006) から、同梱されている
DirectX Viewer が起動すると落ちるんだが、おまいらの環境はどうですか？

うちの環境はざっくり書くと、こんな感じ

Athlon64x2 4800+
2GB Memory
GeForce7900 GT

前のバージョンのやつ持ってくると動くんだよなー
同梱しているソースをビルドすると、DX10要求されるんだよなーｗ
わけわかんねーｗ

>>210
vista専用

ゲームのバックミュージックとして、DirectMusicでMidiファイルを
再生してるのですが、それだけで
CPU使用率を４０〜５０％も消費してしまいます‥

当方の環境は、Pentium4 1.8 でメモリ 256M です。
たかだかＢＧＭを鳴らすだけでこんなにもCPU使用率が上がってしまう
ものなのでしょうか？
もっとその負荷を軽減する方法はないでしょうか？

昔DirectX5の時代にDirectX3DIMいじっていてサーフェイスの管理がめんどくさすぎて
挫折したへたれなんですが、最近のバージョンでもIMはそんなもんですか？
VC++Expressが無料ということで再挑戦しようと思っているのですが、MFC使わないで
組み方を説明しているサイトや本でお勧めのがありましたら教えてください。m(_)m

今はライブラリも結構出てるからそれ使えば問題ない

>>212
MIDI自体がCPU消費しまくる
Pen4 1.8Gじゃそんなもんだろ

WinのゲームでのMIDIってネット環境が貧相だった時代の苦肉の策って気がするな。
MIDIは専用ハードが無いと厳しいし今ならOggがベストなんじゃないかねぇ。

>>213
DirectX3DIMはDX7のしかやった事ないけど、DirectXGraphicsの方が簡単だと思う。
サイトはこの辺がいいんじゃね？

ttp://www.plustarnet.com/aspil/Programming/
ttp://www.twin-tail.jp/
ttp://monsho.hp.infoseek.co.jp/index.html

まあ、ちょっと古いからそのままだとコンパイル通らなさそうだけどｗ

>>217
ありがとうございます。
いつのまにかDirectXGraphicsに3Dも2Dも統合されていたのか・・・かなりウラシマですorz
あと、上記サイトの中で最新のDirectX9SDKではwin2000が未対応になったという記述がありますが、
これは開発環境だけで、実行環境ではwin2000でも98でも問題ないですよね？

一度でも質問に答えが返ってくると、調べればすぐ分かることまで、
調子に乗って延々と質問し続けるんだよね。

>>218
問題ないよ。

>>218
98はDirectX9がインストールできないかな？
でも98自体使ってる人がほぼ皆無の状態って感じ。
エロゲでも2000 XPのみサポートってのが結構ある状態。
こっから先を調べたけりゃ自分で探すしかない。
おそらく誰に聞いても同じ。

ランタイムのインストールができませんですた@2k。（さっき）

SDKはともかく、
2000でも、DirectX9は動く。

SDKに関しては、

http://pc10.2ch.net/test/read.cgi/tech/1132965206/65
によると、

>日本語ヘルプがある最新版　＝　2004OCT
>Win2000サポート最新版　＝　2004DEC
>実際にWin2000で使える最新版は？　＝　手動で解凍してincludeとlibを設定すりゃ新しい奴

らしい。

両方 Extra update が出てるね

ライタイムならDirectX9は初代Windows98からサポートしてんぞ。

SDKのバージョンアップって開発環境へのサポートとバグフィックスだけなんだろうか？
機能追加したらランタイムの方も同じようにアップデートされないといけないはずだけど
9.0c以降は変わってないし・・・（最新のは10になったけど）

9.0cの変更は基本的にD3DX部分だよ

つまりDirectXはWindowsVistaにしか対応してないってこと？

バージョン名が抜けてると意味不明だぞ。

DirectX9.0cならWin98〜WinVista
DirectX10ならWinVista

シェーダー部ぐらいしか変わってないのかなーXanimeは直す気あるのか・・・・

最新のランタイム
ttp://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3
（WEBインスト）
と
ttp://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=77bc0499-19d0-46b6-a178-033d9e6c626b
（配布用フル版）
とでは対応ＯＳが違う？（配布用はXP以降しか書いてない）

どうしてDirectX9.0cっぽいんだぜ？

DirectX SDK - (February 2007) 来たね誰か要点プリーズ
http://www.microsoft.com/downloads/details.aspx?FamilyID=09F7578C-24AA-4E0A-BF91-5FEC24C8C7BF&displaylang=en

>>234
PIX 64-bit Support
PIX Vista Limited User Account Support
PIX Direct3D 10 Frame Counters
DirectSound Header Updated with Windows Vista Specific Speaker Configurations
Documentation for DirectX 9 for Windows Vista
New Technical Article: Installation Best Practices for Massively Multiplayer Online Games
Samples

>>235
基本はVista対応みたいね。
この板的にはMMO用の Technical Article が気になる人が多いかな？

あとは、
＞PIX Direct3D 10 Frame Counters
これどういう意味？
もう 3Dだけ DirectX 10 に移行する準備に入ってるの？

DirectX SDK - (ファブリーズ 2007) 来たね誰か要点プリーズ
http://www.microsoft.com/downloads/details.aspx?FamilyID=09F7578C-24AA-4E0A-BF91-5FEC24C8C7BF&displaylang=en

http://www.microsoft.com/downloads/details.aspx?familyid=09F7578C-24AA-4E0A-BF91-5FEC24C8C7BF&displaylang=en
http://www.microsoft.com/downloads/details.aspx?familyid=09F7578C-24AA-4E0A-BF91-5FEC24C8C7BF&displaylang=kr
http://www.microsoft.com/downloads/details.aspx?familyid=09F7578C-24AA-4E0A-BF91-5FEC24C8C7BF&displaylang=cn
↑リダイレクトされる↓できねー
http://www.microsoft.com/downloads/details.aspx?familyid=09F7578C-24AA-4E0A-BF91-5FEC24C8C7BF&displaylang=ja

ファブリーズの原料ってとうもろこしだっけ？
まさか甘いとは…。

いつの間にかDX10のシェーダコンパイラがデフォになってるし。。
ＤＸ９版よりバグってるんだよねこれ

一旦GDIでLoadImageして加工した画像をテクスチャにしたいんですが、
良い方法はありませんか？
D3DXCreateTextureFromFileInMemoryExを使っても上手く行きません。

>>241
もうお前色々駄目そうだからテクスチャロックして直接書き込め。
http://www.c3.club.kyutech.ac.jp/~sukiyaki/index.php?%A5%C6%A5%AF%A5%B9%A5%C1%A5%E3
//========================================================
//テクスチャを作成します。
//=========================================================
LPDIRECT3DTEXTURE9 lpTex;
D3DXCreateTexture( lpDev, 256, 256, 0, 0, D3DFMT_A8R8G8B8, D3DPOOL_MANAGED, &lpTex )
//==================================
//テクスチャをロックします。
//==================================
D3DLOCKED_RECT TexRect;
lpTex->LockRect( 0, &TexRect, NULL, 0 );
//==================================
//ここで画像データを転送
//==================================
LPDWORD p1 = (LPDWORD)TexRect.pBits;
DWORD pitch = TexRect.Pitch / sizeof(DWORD);
for ( long y = 0; y < height ; y++ )
{
for ( int x = 0; x < width; x++ )
{
p1[x] = 色;
}
p1 += pitch; //次の行
}
//==================================
//テクスチャのロック解除
//==================================
lpTex->UnlockRect( 0 );

すっげぇ遅そう。

>>243
GDIからじゃこんなもんじゃねぇの？
次の行までのpitchわからんからまとめて一括は無理にしても
１行単位でならコピー効くかもしれんけどな。

サーフェスをバックバッファに送る処理で、
StretchRectを使ってもUpdateSurfaceを使っても
ＰＣによって機能しなかったりするんですが、
解決方法はありませんか？

フォーマットが一致してないからじゃないからじゃね？

>>245
サーフェイス間転送時のサポートしてるフォーマットの組み合わせを
起動時に調べてから対応している組み合わせてサーフェイスを作らないと
だめなんだがちゃんと全パターン調べてるのか？

このスレを見ている人はこんなスレも見ています。(ver 0.20)
【C++】 DirectX初心者質問スレ Part12 【C】 [プログラム]
幽霊は本当にいるのか [オカルト]
くだすれDirectX（超初心者用） [プログラム]
アップローダーを設置している人 Part15 [自宅サーバ]
おいでよ　どうぶつの森　雪の後の虹326本 [携帯ゲーソフト]

Direct幽霊

aaa

DirectXの勉強って何から始めればいいんだ？

ウィンドウ作るところから

>>252
それは分かったから次は？

まずどこまでは勉強したと自分で考えてるんだ？

>>254
現在日本語版ドキュメントを読んでて、
そして、JavaとC++の違いに愕然中。

DirectXの初期化するところから

>>256
というか、勉強方法が木になる

>>255
先ずは、JavaでOpenGL（JOGL）から始める事を勧める

>>257
俺は時代的にちょうど盛り上がってたELの中身を見て勉強してた

無理だ、こんな詳細全部覚えられる筈が無い。
一字一句覚えないとプログラムできないんだろ？

>>260
とりあえずあれだ、向いてないんじゃないｋ(ry

頻繁に使う物（幾つか作ると自然に覚える）だけ頭に入れておけば困る事はないだろ？
その他の”よくわからん”物は、概要だけ覚えて後は必要な時に調べれば何の問題もないと思うのだが･･？

どんな考え方したら、丸暗記しないとプログラム書けないとか思うんだろうか･･･。

Cの本とか暗唱できるくらい覚えてからプログラム始めたのだろうか・・・

始めたばかりの自分でも演算子の種類くらいは暗礁できるよ！（誤字）

じゃーとりあえず20個くらいﾖﾛ

(1)->
(2)<<
(3)? :
(4)わからん…

問題の解決に当たって、

　必要な知識を洗い出せるのが理系

　必要な知識を洗い出せないのが文系

理系とか文系とか言ってるやつが文系

ちなみに理系とか文系なんて存在しない
血液型とか星座占いと同レベルな話
>>266みたいなのは簡単に宗教の手におちるタイプ

>264
ボケ殺しｲｸﾅｲ

理系文系なんて、ただの所属グループ名にすぎない。
重要なのは、数学ができるかできないかだ。

>>267-268
いや、俺は芸術系だよｗ

それは多分世間的には文系と呼ばれる

じゃぁ体育系は理系か？ｗ

しょうがないなぁ。

今日から、コメントは、
//DirectGraphics を初期化しマッスル
という方向で行きましょう。

＞DirectGraphics
そんな名前の物はDirectXには存在しないのでスレ違い

なぜかDirectGraphicsって勘違い多いな

昔のDirectXのDirectMusic使ってSMFを再生すると
BankSelect(LSB,MSBともに)が無視されちゃうんだけどこれって9にすれば直るのかな・・・
windowsのMCI使うと何故かかなりラグあるしなんとかDirectMusicでやりたいんだけど

>>275
意味がわかってるし通称としても浸透し始めてるのに知らないフリなんて
剣道部にいた嫌われ者の先輩みたいだ。

そんな通称はないし、浸透もしていない。

>>279
ﾌﾟｹﾞﾗ
DirectGraphics の検索結果 約 20,700 件中 1 - 10 件目 (0.09 秒

スペース入れるとさらに出てくるな。

"Direct Graphics" の検索結果 約 68,600 件中 1 - 10 件目 (0.13 秒)

http://www.google.co.jp/search?num=100&hl=ja&inlang=ja&ie=Shift_JIS&q=DirectX-Graphics&btnG=Google+%8C%9F%8D%F5&lr=

単なる勘違いの蔓延を通称とか言っちゃうのが痛々しいな・・・

まあ、「間違いは認めるから察してくれよ」という気持ちも十分に理解できるけどなｗ

化石は死ねば？ｗ

ttp://msdn.microsoft.com/library/ja/directx9_c/directx/intro/dx9whatsnew.asp?frame=true#Graphics

今日も☆とかちつくちて☆聞くお

800×600の2Dスクリーン座標から3D座標への変換作業で苦戦してます。
（マウスクリックした所と3D空間の地面の照合）

IDirect3DDevice9* DEV;

※mouseXには0〜800、mouseYには0〜600の数値が入ります

D3DXVECTOR3 vec1(mouseX, mouseY, 0);
D3DXVECTOR3 vec2;

D3DVIEWPORT9 vp;
DEV->GetViewport(&vp);
D3DXMATRIX vmat;
DEV->GetTransform(D3DTS_VIEW, &vmat);
D3DXMATRIX pmat;
DEV->GetTransform(D3DTS_PROJECTION, &pmat);
D3DXMATRIX wmat;
DEV->GetTransform(D3DTS_WORLD, &wmat);
::D3DXVec3Unproject(&vec2, &vec1, &vp, &pmat, &vmat, &wmat);


この様にコードを書いたのですが、返値ベクトル vec2 に
意味不明な数値が返ってきて困ってます。(-1.005, -1.005, 1)とか。
正規化してるとしても数値が小さすぎます。

::D3DXVec3Unproject関数の使い方を間違ってるでしょうか？

D3DXVECTOR3 vec1(mouseX, mouseY, 0);

そもそもこれは何？
奥行きが潰れている状態で、ベクトルも対象物も分からないのに何が出るっていうんだ？
窓ガラスに鼻くそを付けて、ここが地面なんだとのたまうのか？
頭がおかしいんじゃないのか？

>>288
＞D3DXVECTOR3 vec1(mouseX, mouseY, 0);
これは別におかしくはないぞ。
透視変換後のスクリーン座標で指定するから0.0fなら
正しくワールド空間に展開されればニアクリップの値になる。

あぁでもD3DXVec3Unproject()の仕様次第だな。
俺は自前で変換してるからこの関数がどうなってるかわからん。

>>288
・・・・
知らないのなら、無理に答えなくていいです
まず文章を読んでください

D3DXVECTOR3 rayS(mouse.x, mouse.y, 0), rayE(mouse.x, mouse.y, 1.00f);
ClassSprite::GetRay(rayS, rayE, mProj, mView);

void ClassSprite::GetRay(D3DXVECTOR3 &p1, D3DXVECTOR3 &p2, D3DXMATRIX &mProj, D3DXMATRIX &mView)
{
D3DVIEWPORT8 vp;//D3DVIEWPORT8
lpDevice->GetViewport(&vp); // ビューポート パラメータ取得
D3DXMATRIX mat;
D3DXMatrixIdentity(&mat); // 単位行列
D3DXVec3Unproject(&p1, &p1, &vp, &mProj, &mView, &mat);//ベクトル射影
D3DXVec3Unproject(&p2, &p2, &vp, &mProj, &mView, &mat);//ベクトル射影
}

D3DXMATRIX vpmat, tmpmat;
D3DXMatrixIdentity(&vpmat);
vpmat._11 = vp.Width/2;
vpmat._22 = -vp.Height/2;
vpmat._33 = vp.MaxZ - vp.MinZ;
vpmat._41 = vp.X + vp.Width/2;
vpmat._42 = vp.Y + vp.Height/2;
vpmat._43 = vp.MinZ;
vpmat._44 = 1;
tmpmat = vmat * pmat * vpmat;
D3DXMatrixInverse(&tmpmat, NULL, &tmpmat);
D3DXVec3TransformCoord(&vec2, &vec1, &tmpmat);

>>288
確かに
>※mouseXには0〜800、mouseYには0〜600の数値が入ります
>
>D3DXVECTOR3 vec1(mouseX, mouseY, 0);
「これは何？」と思うなｗ

>>290
鼻くそをつける窓ガラスがz=0だ。
あとは窓ガラス上の鼻くその位置(0〜800、0〜600)から、
ビューポートの範囲に合うように変換すればいいだけだ。
あとはMSDNで「ビューポート矩形」で検索してちょ。
（つか、画面サイズ801×601？

>>293
誰も思わねーよｗ
つーか、自分にレスして楽しいか？（ＩＤが変わってもバレバレなんだがｗ）

何がビューポートだよ。
無知もいい加減にしてくれ。アホか

288は私なんだが。

>>291
レイをとばすなら開始位置と射影からベクトルが求まるから、
わざわざ二点を変換するような回りくどいことをする必用はない。

C# Managed DirectXで2Dの画像をウィンドウに貼り付けるにはどうしたらいいですか？

ポリゴンを四角形にして画像をテクスチャにして張り付ける

とかち、、、なぜこのスレにまで

>>295
レイの(x,y)に置ける差額をZ１単位で知るのが目的だと何故分からない？
288=293=295だろうが
もう、知らないのに回答者を気取るなっての

二点をわざわざ変換しなくても、視野角が決定した時点で起点とスクリーン座標までのベクトルがすぐに出せる。
ディスプレイの手前に四角錐があると考えれば分かるはず。
その四角錐の頂点からディスプレイの特定の座標までが始点におけるベクトルになる。
このときに使われる手前のZ座標は視野角が変化しない限り不定なのであらかじめ計算しておくことができる。
そこからスクリーン上のベクトルを求めるのは引き算だけ。
あとはそれを回転成分だけ処理してワールド上のベクトルに変換する。

二点を逆変換すれば確かに出るが、一回ですむ処理なのになぜ無駄に二回処理するのか理解できない。
ものすごく無駄な計算をしているのが分かっていないのか？

自分の都合がいいように仕様を固定して答えてみました・・・みたいな

射影が動的でも二回変換するよりも遥かに無駄がでないが、
無駄な方法でも結果が出ればいいのなら好きにすればいい。

レイの正規化されたベクトル差違(x, y)の数値があれば
3D空間内のそれぞれのオブジェの接触判定に使えると、それだけの話なんだが
２点を求める必要性を否定するとは、意地になってませんか？

>>303
それもスクリーン側の二点をわざわざ変換しなくても算出できる。
ワールドへの変換を理解していれば普通に計算方法が思いつくはずなのに、
遠回りして無駄が多い言っているだけ。

逆に、なぜ意地になって二点変換という無駄な方法にこだわるのか分からないが、
どうしてもそれが良いのなら当人の勝手だろう。
しかし他人に無駄な方法を広めるのは思い直した方がいい。

その方法がまともな方法だと本気で思ってるのか？

>思いつくはずなのに、
>分からないが、
>思い直した方がいい。
>思ってるのか？

　↓

>当人の勝手だろう。

1フレームに一回呼ぶかという頻度の処理に何を威張っているの？

愉快なID:Z1aRLr5Iが居ると聞いて再びやってきました！

>>291のコードを例えて言うなら
1+2=3
を
100-1=99,
100-2=98
99+98=197,100+100=200
200-197=3

にしているのに似ている。
結果が同じなんだから文句を言うな。

こんなのどっちのやり方でもいいじゃねーか。

そもそもの原因はD3DXのせいなんだよな。
実質的な計算方法が分かってい馬鹿でも、ある程度使えてしまうので、
無理矢理へんな使い方で答えを出そうとする。

不便なものは、使いにくいが、人を鍛える。
便利なものは、使いやすいが、人が鈍る。
不便なもので鍛えて便利なものを使うのがベストかもね。

わけがわからずソースだけもってきてなんでか動いてるって状態よりは百倍ましだと思うがな。

D3DXは本当に３Dが初心者の人が扱うにはやはり難しい。
なんだかんだで中級者以上の人間が楽をするための関数群な気がする。

最初はどっかの３D対応のライブラリでも使いつつ、
細かい使い方とかはライブラリの中身を拝借するのがいいかもしれんな。

都合よく3D対応でオープンソースのライブラリがあればだが・・・
確かLampとかいうライブラリが教育的なんちゃらって銘うってた気がするけど。

Lampはソースは山ほどあるしコメントもそこそこ入ってるけど、解説と呼べるドキュメントが皆無で
初心者向けを謳うために一番大事なものがないんだよね。
やっぱD3DX・XNA・Java3Dあたりのサンプルと格闘するのが無難なんじゃね？

１点だけの変換だと、
・視点〜前方クリップ面
・後方クリップ面〜無限遠
の表示しない対象にHITしないか？
目からビーム撃つなら問題ないだろうが…

表示した物体をクリックするなら、
前方クリップ面と後方クリップ面上の２点を変換して、
その区間で判定するようにしたほうがいい。
表示していない物をクリックするのは何かと不具合が多い。

だから１点か２点かはケース・バイ・ケースだ。

>前方クリップ面と後方クリップ面上の２点を変換して、
>その区間で判定するようにしたほうがいい。
2点を変換しないとこの程度の計算も出来ない時点で終わっている。
あまりにも頭が悪いんだが、いったい何なんだろう？
不具合って、またろくでもないやり方をして勝手に出来ないと思いこんでいるだけだろ。

>>314
今ならXNAは確かにいいかもなぁ。

初心者向けとしては一番知名度が高いDXライブラリが
3D対応したらって思ってる人は多そうだな。

XNAは固定機能ないんだよね？
初心者にいきなりシェーダから入らせるのは無理があると思う。

それとも、逆に座標変換の流れが曖昧にならずにいいのかなぁ。

ところで初心者の定義ってなに？
プログラム経験1ヶ月くらい？

3年以上プログラム経験があるくせに、初心者だからと言い訳する奴がいるんだが。

DirectXを初めて使うなら初心者だろう

>>316
淋しいのか？
生きるのが辛いなら、さっさと来世に旅立ったほうがいいぞ？

とうとうプログラムの話が出なくなり、煽るだけになってしまった悲しい末路。

今の流れで初心者なら３D初心者って意味じゃね？

ライブラリ使って何か作る⇒ライブラリの中を追って動作を知る
⇒ライブラリを使わずに作れるように

ってのが一番無難だと思うけどな。

>319
目安にはなるだろうけど、期間そのものは関係ないと思う。
自分も初めて触れてから5年くらいあるけど、業務や研究に使ってるわけでもなんでもないから初心者の域を出ないだろうし。

何年もやってて初心者って、それは初心者ではなくやる気がない人間。
自分は初心者だと名乗るのではなく、自分はやる気がない者だと名乗らないと、
本当に期間の浅い初心者に失礼。

初心者、中級者、上級者の定義が技術レベルによって定義されるとすれば
いつまでたっても初心者ってことは十分にありえる。

3ヶ月の経験があるとしても、1日2時間しか勉強できる場合と、1日5時間勉強できる場合とでは単純に考えて、
知識量も技術も違ってくるから、日数で初心者かどうかを切り分けることは適切じゃないだろ。

初心者は、ドキュメントの読み方を知らない人 だと思う。
読み方わかるなら、基本的なものは作れる。

中級とか上級とかは分ける必要ない。
初心者と初心者以外で十分だ。

DirectXの名前ぐらいしか知らない。どんな事ができるか知らない→入門者以前の問題
チュートリアルを読んで、実際に作ってみた→入門者
チュートリアルで作った物を改造〜ドキュメント片手に基本的な物を作れる→初心者
他人の書いたコードを追って内容が理解できる→中級者以上

技術レベルに応じて 入門者・初心者・中級者 で分けるとこんな感じ？

>>316
DirectXの名前しか知らないような人が、２週間ほど前からXNA始めたけど
シェーダは日本語情報も多いから、単純な物ならちょっと検索すれば見付かるし、酷く苦戦するような事はないかな。

例えばテニスを何年もやっていて、ずっと下手糞だったら、
その人は永久に初心者を名乗ることになるのか？

それは初心者ではなく、才能がないだけ。
初心者と混同すべきではない。

まあよほど理解力ない人じゃなければ、ある程度やってればこのくらいはできるようになるだろう
ってのが初心者とそれ以上の線引きなんだろ

それを考慮しての327が結論でいいじゃない、どうでもいい

＞どうでもいい
　
全くだな。

そうか！

はじめて2年目だけど未だにサンプルとかを切り貼りしないと
プログラム作れない俺でももう既に上級者だったのか！


スマン

初心者と中級者の線引きなんかしても意味がない。
どうせ、線引きしたがるような奴は
自分を初心者に入れないように
都合のいい定義を作ってるから。

むしろ、自分が初心者に入るように定義する人が一番厄介だと思うんだ。

まぁどこまでが初心者なんてどうでもいいな。

自分が初心者だと名乗る奴は学習能力が無く、いくらやってもモノにならない無能者。
永遠の18歳とか恥ずかしいことを言っている奴と同じ。

上級者ってのは俺らには想像もできないようなことができるんだろうな。
DirectXを操って天変地異を起こしたりとかさ。

全然話変わるんだけど、
DirectXってSDKバージョン幾ら増えても
D3DX使わなかったらDirectX9.0cとかで動かせるんか？

>>336はDirect3D10をD3DXを使わないというだけで、
DirectX9環境で動かせる凄い技術を持っているようです。
どうやったのかぜひ教えてください。

>>337
動くかどうか聞いてるんだから
そんな技術知らねーお（　＾ω＾）


まあ質問の仕方がおかしかった、すまん
DirectX9の中にもSDKのバージョンってSummerとかAprilとか色々あるけど
D3DXを使わなかったら最新SDKでないDirectX9.0cで動くのかなってことです

みなさんこれが初心者です
そして私も初心者です（　＾ω＾）

>>336のレスは、>>331と同レベルの俺でもおかしいことがわかったｗ

>>336>>338
DX9のプログラムでD3DXをまったく使っていなければ9.0cのDLLだけで動きますよ。

>>341
thx！

>>339
初心忘れず頑張るお（　＾ω＾）

>>335
ごめん、こないだのあの地震はオレが出したバグが原因だったんだ

知らなかった
プログラマーとは神様だったのじゃ・・・

未だにクラスなんてものがわからん俺でもDirectX！

ローディング画面で別スレッド立ててアニメをグリグリ動かしてるんだけど
このスレッドでpresentしまくりつつメインのスレッド上のロードのルーチン内で
テクスチャの確保とかをやるとタイミングによって失敗することがあるんだよね
まぁセマフォを通す必要があるわけだけど上級プログラマの方たちはここら辺りを
どんな設計にしてるのか聞いてみたい気がした

デバイス作成時にマルチスレッドにするぞ( ﾟДﾟ)ﾄﾞﾙｧ!!
ってフラグたてときゃ内部でクリティカルセクションとりにいくべ

テクスチャにD3DPOOL_MANAGED使うと
FPSが1/3ぐらいになる。
そんなはずはないと思って調べていたら
CPU使用率が100%になってた為だった。
DOOM3とか普通に動かせるレベルのPCなのに
どんだけ重いんだ俺のアプリは

D3DPOOL_MANAGED＝地雷という記憶しかないなぁ。
DirectX9出た当初に一度試してそれっきり。
　
たしかヘルプはD3DPOOL_MANAGEDの環境依存性(ドライバ依存性)に
言及してないよね。つまり建前上は「依存は無い」と。だから
D3DPOOL_MANAGEDを指定可能かどうかを示すフラグもなかった。
　
色々痛い目にあってD3DPOOL_DEFAULT(自前でリストア)に戻した。

>>347
素敵なんだけど具体的にどの関数がクリティカルセクション
とおってるかわからないとさすがに使う気にならないなあ
しかしDirectX的にはどれがいちいちスレッドセーフなのか
明示するのはメンドイから黙って使っとけということなんだろうか

>>347
IDがS3社

>>349
特定環境下でのMANAGEDの地雷性よりも、DEFAULTのデータロストの方が厄介なので
前者を使う方がトラブルが少ない。

MANAGEDの地雷性を危惧して下手な対策する位なら、マニュアルに
「最新のドライバをインストールして下さい」
の一文を乗せた方がいい。

>>349
MANAGEDはドライバに任せないというオプションもあるよ。(Direct3Dが管理する)
っていうか、そのオプションの説明でドライバに依存するということは言及して
いることになるんじゃないの？一行で簡単に片付けられているけど。

>>350
当然、マルチスレッドで問題の発生する関数全てだろう。
そのオプションを指定しなくても、一部クリティカルセクションは使用しているようだが。

AGPメモリを使うためにDEFAULTを使うので、
一度自前でリソース管理する部分を自前で作ったら、MANAGEDが全く不要になった。
結局MANAGEDの使い道が皆無。

しかし例えばテクスチャのミップマップレベル強制など
D3DPOOL_MANAGEDを指定しなければ使えない機能などがある。
（ミップマップ制御が管理下しか有効にならない理由は
制限されたサイズ以下のサーフェイスのみVRAMにロードするって、
ふざけた理由じゃないだろーなー）

そういえば某イリュージョンのエロゲデモはテクスチャ作成時にsystemmemとdefaultと
2つセットでつくってたなんでこんな馬鹿みたいなことすんのかなと思ったがそういうことなのか
そんなにmanagedの各ドライバでの実装の問題は深刻なのかい？今初めてきいたわけだけれども

>>356
それは速度ＵＰが主眼で、ドライバ依存性云々は関係ない。
ある程度ＰＧをやってれば自前でリソース管理する様になるので
自然とMANAGEDを使う事はなくなる。
MANAGEDがドライバによってコケるってのは杞憂に近いな。。。
んな事言うのなら、外にも心配しなきゃいけない事がたくさんあるし

速度アップが主眼なら自前でやるよりドライバに好きなようにManageさせたほうがいいんじゃねーの？

なんか仕組みが分かってない>>358が混ざってるな。

ねつ

ダークメタルヘルム
モノトーンガントレット
サイキックキャップ
アーミーグリーヴス
アドミンチュニック
マダムシューズ
ボレアス
ニンバス
トールハンマー
ユダ
ドルフィン
メタルバックラー

すげー誤爆ｗ

すみません質問です。
環境:C++,DirectX9 BCCDeveloperを使用
ID3DXSPrite::Begin()を使用したいのですが、
ttp://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/DirectX9_c/directx/graphics/reference/d3dx/interfaces/id3dxsprite/_id3dxsprite.asp
を見る限りはBegin(void)のようですが、コンパイル時に
「パラメータが足りません」とエラーがでます。
又、ID3DXSprite::Draw(引数略)を使用したときに、上のサイトの仕様通りに使用しても
「パラメータが多すぎます」とエラーが出、また、D3DXVECTOR2を要求してるはずの部分が
「D3DVECTOR3に変換できないので2は使えません」とエラーが出ます。
ttp://www.uploda.org/uporg712890.cpp.html
C言語と、VisualBasic6.0+DirectX7は一通り勉強したのですが、C++とDirectX9は勉強開始して間もないので
拙いソースですがよろしくお願いします。

ID3DXSpriteは仕様がころころ変わるので、そういったものが自己解決できない人間は絶対に使ってはいけない。
チュートリアルをこなしていれば普通にテクスチャを張るぐらいは出来るはずなので、そちらを使うべき。

>>362
ID3DXSPriteは、９がリリースされたその半年後に大幅に仕様変更され
関数の引数も変更されたので、ドキュメントの記述は当てにならないのです。
（ドキュメントの修正はされなかった）
DirectXは、こういう事が多いので、ドキュメントを鵜呑みにせず
使用前に各自がヘッダファイルを見て自己解析する必要があるのでーす

おまえら英語ドキュメントくらい読もうぜ

DirectX限定の質問じゃなくてすみません、
今スキンメッシュの仕組みを根っこから理解したくて勉強しています。

Direct3DXのスキンメッシュの仕組みは使わずに、
自分で、スキンメッシュに必要なボーンやらメッシュやらの情報を
格納する独自の形式を書きました。
んで、X形式ではなく他のデータを読み込んで、アニメーションなどのデータを
独自の方法でメモリ内に置き、いざ表示するぞ、というときになって疑問に思ったんですが、
ボーンというのは普通、親のボーンに対する移動・回転のオフセットは
アニメーションのキー（何ミリ秒の時点で移動いくつ回転いくつ）でのみ
表現するもんなんでしょうか？

自分の中では、まず各ボーンは基本のポジションがあって、
そのポジションに対して相対的な移動・回転がアニメーションキーに格納されて
いるものと思っていたんですが、違うんでしょうか（これはスキンメッシュじゃなく
メッシュごとのアニメーション（X形式でいうフレーム）の場合？）。

自分が使いやすいようにすればいいよ。

>>363-364
ありがとうございます。
とりあえず、ID3DXSpriteの変更部分を踏まえたプログラムと別の方法で行うプログラム両方書いてみます。

>>366
ある頂点を目的の位置に移動させるときどのような行列が必要か
考えてみればいいんじゃね？その頂点の元々の位置とキーフレーム
から計算される姿勢行列、それで十分なのか十分でないなら
足りないものは何なのか。

誤情報申し訳ない
>>348で管理下のテクスチャを使うと重くなると言ったが
IDirect3DTexture9::SetLODを毎フレーム使用していた為だった。
これを外せば、目立った処理落ちはなくなる。
重くなる理由は>>355の通りだろう。
また動的にLODを掛けたければ、サンプラステートを使うのが定石。
エフェクトを使っていると、これがまた使いづらいのだが。

>>367, 369
ありがとうございます。
ではどっちに限定しても困ることは無さそうだし、
両方試してみようと思います。

難しくて勉強が進みません。
私は才能が無いので死ぬべきです。
もう生きているべきではありません。
私はクズです私は存在する意味がありません。
私は世界の敵です。私は無意味です。
私の存在は世界の害悪です。
私は全ての存在の敵です。

勉強した年数を言ってみろ。
5年程度も勉強せずに才能とか言うようなら何をやっても無駄だ。

構うなよｗ

私はどうせ学歴も低いです。
私は所詮クズです生きるべきではありません。

マジレスすると、まだ始めようと思って１年も経ってない。

COMオブジェクトの勉強するとDirectXの勉強もはかどるね

マジレスすると自分とか人間が存在する意味とか考えるヤツは一神教を信じている。
誰かが何らかの意図を持って人間を創造しない限り人間の存在に意味はない。

>>372
適性があっても、いきなりDirectXで3Dのゲーム作ろうなんて考えると
絶対つまづく。それで仮にサンプルコードの寄せ集めでゲームが作れたとして
そのレベルを超えようと思った瞬間に超難題がいくつも出てくる。
まずはC++を使いこなせるように勉強しながらWin32APIでWindowsアプリを
作れるようにして、自信がついたらDirectXに入るとか・・・・
まぁそれすらも全然出来ない(または意欲が出ない)なら、
さっさとあきらめて別の分野に行った方がいいかも。
ゲームプログラミングの「味を占める」ことが出来るかどうかって、
やっぱ重要だと思う（自分もそこらへん微妙だがｗ）。

普通に>>372はネタだと思ったんだが
マジレスしている優しい人がいる

べ、べつに>>372のために答えてるんじゃないんだからねっ
この掲示板をみてくれてるたくさんの人のためなんだから勘違いしないでよねっ！！

どうせ、ちょっと↑であった痛々しい煽り合いの片割れかなんかだろ？

確かにDirectXを勉強したいけど、
やっぱり基礎から固めていって何年もかけてやるべきなんだよな…。

ありがとう、これで成仏できるよ。

つーか目的にもよるけど既存のライブラリ使っちゃうのも手だぞ。
一通り使えるようになってからライブラリのソース見れば
DirectXのどんなAPIでどうすればこうなるのか、とかが分かりやすい。

と思う。

プラグイン追加で2D画像から仮想的な法線マップを作成できるソフトってPhotoShopとGIMP以外シラネ？

>>384
CG板のPainterスレで法線マップを作るプラグインを公開してる人がいた気がした。
あとはPaint ShopからShoto Shopのプラグインが使うとか。

プラグインを使うとか、だよね・・・俺も冥土に逝ってくる（´・ω:;.:...

>>382
DirectXよりOpenGLの方が簡単でいいよ

DirectXってそんな難しいかなあ
細かいところ突き詰めればそうかもしれないけど

だがOpenGLの方が簡単だってことはねーわ

>>388
細かいところまで勉強しようとする必要は無いの？
１時１句完全に覚える必要は無いの？

DirectXって、ハードウェア依存の仕様が多すぎて安定感がないのよね。
軟弱な地盤に超高層ビルを建て増しし続けてきたみたいな感じ。

別にDirectX自体に安定感がないわけではないと思うけどな。
ハード依存/非依存を適切に選択するコードは書けるわけだし。

まあそれを完璧にやろうとするのが
面倒臭すぎ・非現実的過ぎてやってられないんだけどな。

> 細かいところ突き詰めればそうかもしれないけど
このスレでそりゃないだろｗｗｗ

>まあそれを完璧にやろうとするのが
>面倒臭すぎ・非現実的過ぎてやってられないんだけどな。

その点は同感
ほぼ徹底して面倒見ていると思われる
Microsoft 謹製のフレームワーク DXUT.cpp 関連のソースを
見ると DirectX の魑魅魍魎さを感じる

> 軟弱な地盤に超高層ビルを建て増しし続けてきたみたいな感じ
そもそも Windows という OS 自体がですね

>そもそも Windows という OS 自体がですね
Microsoft という会（ｒｙ

いきなり3Dからやるから難度が高くなるんだと思います

ハード毎に分けてソース書かなきゃいかんのはOpenGLも変わらん。
nVIDIA拡張仕様とかATi拡張しようとかあるんだし。

研究用ならOpenGLでもいいけどゲームになると結局
DirectSoundやDirectInputが必要になってくるから
描画もDirectXGraphic使うことになるんだよな。

OpenGL＋SDLという手もあるぞ

トリッキーな方法なのですが

::D3DXMatrixPerspectiveFovLH(&proj, (float) 60 * 3.14 / 180, 1, -1, 0);
pDev->SetTransform(D3DTS_PROJECTION, &proj);

と、近いview平面のz値を-1、遠いz値を0
とすると、遠近感は有効になりますが（遠くの物は小さく、近くの物は大きく）
ステンシル？が無視されて、物体の前後関係なくDrawPrimitiveで登録した
順序通りに頂点が描かれます。

これはどういう事なのでしょうか？

自前でZを計算してみろ。
いかにアホな状態になっているか分かるから。

今後サウンドはOpenALのほうがいいんじゃないかね

アホとかじゃなくて、
これがなかなか有効なんですよ。
今まではフツーに 0.01〜1 とやってたのですが、今回こうやったら
遠近感だけが維持されて、物体のz値による前後関係を無視して
任意の順序で描画できたので、あるシーンでは非常に有用になったのです。

フツーに考えると視界に何も表示されないはずなんですが、
何故かきちんと表示されて、上記の効果が得られます。
これはどういう事なのか誰か教えてください。

Zバッファを使いたくないなら、異常なパラメータを設定せずに、
Zバッファ自体を無効にすればいいだけだろ。
馬鹿の考えることはさっぱり理解できない。

pDev->SetRenderState(D3DRS_ZENABLE, FALSE)
で
Zバッファを無効にすると、遠近感も無効になってしまうのです
（遠くの物も近くの物も同じ大きさになる）
しかし、Ｚバッファを有効にして、プロジェクションの視界を-1〜0にすると
遠近感は維持されて、z値の前後関係だけが無視されるので
あるシーンでは有用になるのです

>>404
それは嘘だ。
ZENABLEをONにするということは
ピクセル単位のZバッファカリングを有効にするということ。
遠近感の計算はプロジェクション行列で決まる

ﾜﾛｽ

D3DXのせいで仕組みがさっぱり分かっていな状態でプログラムを組む馬鹿が増えすぎ。
すぐに途中で詰まって馬鹿なことを触れ回るし。

>>404はまずD3DXを使わず、自前で計算する部分を作れ。
射影行列を作るくらい大して時間はかからんから。

>>404
ttp://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_Dec_2005/D3DXMATRIXperspectivefovlh.asp
これの下に書いてあるのが射影行列ね。
これでzを計算すると(3列目ね)
Zp = zf/(zf-zn) - zn*zf/(zf-zn), Wp = z
zf が 0 だから 最終的な Z(Zp/Wp) は常に0になるわね。
同じz値の場合、後から描画したポリゴンが上書きされるわけよ。
逆にこの式では、znとzfは遠近感(x,y)には関係してないはずなのよね。

>>405
嘘じゃないです。
試してみれば分かります。
とにかく、プロジェクション視界を-1〜0にすると、
遠近感のみが維持されて、z値の前後関係が無視されます。

これはどういう事なのか、誰か知ってる人がいたら教えてください。

>>407
馬鹿、馬鹿って、とにかくそうなるのは事実なのだから
（やってみればすぐに分かります。計算云々の問題じゃなくて
　現実がそうなのだから仕方ないのです）
それについて、誰か「知ってる人」がいたら教えてください

>>410
>>408に答え出てるんだから、それ見てから返事したら？

>>408
なるほど。
zfを０にしての計算そのものが、単純に結果反映されてたのですね。サンクスです。

無知な人ほど、口汚く罵る、という事も分かりました。

>>413
逆に聞くけどZENABLEがOFFの時に遠近感が計算されなかったのは何故か説明できる？

ついで言うとその手法でZカリングを無効にするのはZENABLEをOFFにした場合より遅い。
間違いの根本を改善せずにパッチワークで修正してるようなものでお勧めは出来ない

3Dプログラムを作る上で、あまりに基本的な部分をすっとばしいたら、
今後何かやろうとしたときにすぐにダメになることは目に見えているのに、
何故、基礎から学習していこうとしないんだろう？

基礎から学習していたらいつまで経っても前に進めないからだよ。
背伸びしてナンボ。
過去書いたコードのダメな点は、後から気付けばいい。

>>414
単純に、z関係を計算しないからじゃないですか？
遠近感によるXスケールとYスケールを計算する分、
ZENABLEをOFFにするより遅いのは当然ではないですか？
しかし、上レスで繰り返し述べてる通り、
遠近感によるスケーリングのみを有効にしてそのカリングを無効にできるので
特定シーンの表現時に非常に有用だった訳です。
根本？はそれです。
お勧めできないとの事ですが、外に正規のやり方があるのなら何とぞ教えてください。

>>415
基礎の必要性はもっともですが、その基礎すら説明できない癖に
口汚く罵るだけの、自称エキスパートがいるから問題なのです。
罵倒するのは良いが、>>408氏の様に具体的回答も同時に併記すべきなのです。

ロクに知識もない癖に分かってる気分で、結局は罵倒するだけの
中２病患者は、このスレで回答者を気取るべきではない、
とそういう事です。

回答する人間の気分を悪くして回答が得られると思ってるのか？面白いやつだなｗ

>>417
え？まじ？ほんとにそうなってる？
それはむしろDirect3Dの固定機能パイプラインの実装を疑うな…

D3DRS_ZENABLEが使えないなら、他に手はもうない。

SetRenderState(D3DRS_ZENABLE,FALSE);
が使えないなら、
SetRenderState(D3DRS_ZFUNC,D3DCMP_ALWAYS);
が適当かと。
(高速かどうかは不明。GPUによっては速いのもあるかもね)

固定機能パイプラインの挙動が変ならシェーダできちんと遠近計算は行って
ZENABLEをOFFするのが最もパフォーマンス的に有利だと思う。
(Zバッファとの比較をする必要がないから、当然速い。)

別にいいんじゃね？
一人が回答を返せばそれで十分だし、
わざわざ相手のことを罵る人間には期待せんでも。

まぁ、俺だったら、いちいち罵倒表現を挟む奴はシカトするが…。

あ、変なところで書いちゃった。

＞D3DRS_ZENABLEが使えないなら、他に手はもうない。
この続きで
＞射影行列で0に射影すると考えれば理論的には正しいのでその手法でよいと思う。それ以外に、

が続く

>>ID:LKvKLn/o
いい機会なので、透視変換について勉強すれ
これがわかれば世界が広がるぞ
誰しもが通ってきた道だし

回答を求めているのに偉そうに振舞う常識のない質問者もいれば、
煽るだけで何の知識のない似非回答者もいるってことだ。
こういう場だと納得した上で利用せんと神経が擦り切れるだけだ。

って、修正したって明らかに文脈変だ。なんか泥沼orz
このSHIFT+Enterで書き込みって機能いらねぇ…

で、正当性を確かめるためD3Dのサンプルで実験したけど、ちゃんと遠近計算されてるぞ。

プログラムはこちら
C:\Program Files (x86)\Microsoft DirectX SDK (April 2006)\Samples\C++\Direct3D\Tutorials\Tut06_Meshes

ここのD3DRS_ZENABLEをFALSEにした結果と
プロジェクション行列の計算を言うとおりに変更した結果のプログラムは同等に見えるけれど。

D3DRS_ZENABLEの値を変更したときに行列設定のパラメータも弄ってたんじゃないの？

バグによる未定義な結果を前提にする意識をも
情報統合思念体は存在を許容するのだろう

このまま話続けたいが会社いってくるお（；＾ω＾）

>>425
失礼。
先ほどテストした時は、他の平面シーンでの行列を設定したままでした。
D3DRS_ZENABLEをFALSEでも遠近感ＯＫでした。
速度的にも速いので変な引数指定しないで、そっちにします。

勉強するのがいやなら、ありもののライブラリで楽をするのがよい。
おかしくてもライブラリのせいにできるしな。

単純なXファイルでID3DXMesh::DrawSubsetを使って描画するオブジェクトと、
ボーンが入っていて、プログラムシェーダーを使って描画するオブジェクトが混在しています。

オブジェクトごとにID3DXEffect::Begin 、ID3DXEffect::Endを使って切り替えて描画するのでしょうか
それとも、Xファイルを描画できるプログラムシェーダーを用意するのが一般的なのでしょうか？

場合による、どうせ重いのはDrawPrimitiveとSetTextureなので状況にあわせて変えればよい。

2D限定で
最近のビデオメモリの転送速度なら裏画面のサーフェイスをメインメモリに置くようにしたり
裏画面を二つ用意してトリプルバッファリングする
とかいう面倒くさいことしなくても大丈夫なの？

5年前くらいに
DirectDrawのbltに頼るより自前の方が早いし
ハードの不具合に煩わされないと言われていたな。

>>428
それは嘘です。
Zバッファを無効にすると、遠近感も無効になってしまうのです。
試してみれば分かります。やってみればすぐに分かります。
現実がそうなのだから仕方ないのです。

特定の環境では、バグの動作も一定の再現性を持つ
経験則を疑うことを知らない井の中の蛙は
信じているものがオマジナイにすぎないとは知らず
いつか自作プログラムを世に出したときにDirectXが不安定だと騒ぎ出す

でっていう

>>431
サンキュー

ニンテンドーDSでマリオカートをやったんですが追い抜いたり追い抜かれたりすると音が真横を通って後ろから聞こえます。
最初はドップラー効果で錯覚させてるのかなとも思ったけど本当に真横から聞こえてくるので不思議なんですが（それに携帯機だし）
たとえばDirectSound3DやEAXやドルビーデジタルやドルビープロロジックIIxなんかで実装されてる技術で
どういう概念や理論や数式が使われてるんでしょうか？

たとえば耳と耳の感覚が20cmとすると波長がそれより長い音波はある瞬間において音圧の差が左右の耳で発生しないため指向性が無くなる、
とかいろいろ音の理論はあったと思います。

----------------------------------------
たとえばドップラー効果は

f * { (O + v1) / (S + v2) } = f'

みたいな式だったと思います。
------------------------------------------

まあそれを勉強できる良いサイトや本でもいいんですが・・・・

音響理論はスレ違いでしょう。
DirectXでは音源位置やエフェクトを設定するくらいしかやること無いんだし。

DirectXは現状EAX2.0のオクルージョンとかに対応してませんでしたっけ？
たしかEAXはOpenALにオープンソース化で使いやすく！とか言ってたのはどうなったんだろう。

これはDirectXの実装の質問ですがモデルのxファイルと3D音響データと
コリジョン計算用のデータ（多くの場合球か直方体でしょうか？）ってどっからでもアクセスできるように同じレベル（クラス）で保存しとくんでしょうか？
同じキャラをたくさん出すのにジオメトリックインスタンシング等の技術は同じく使えるのかな？

それから米国にはGamasutra(ガーマスートラ？カーマスートラのもじり？)とかいうゲーム開発者専用の雑誌がありますが日本には無いんでしょうか？

>>LKvKLn/o
亀レスだが、大学中退して線形代数をちゃんと勉強しなかったことを
ド後悔したお兄さんが、周りの言ってたことの意味を教えてあげよう（/ω＼

まずZバッファについてだけど、”Zバッファは”遠近感（遠くのものが小さく見え、
近くのものが大きく見えるという意味だよね？）には関係無い。
Zバッファというのはもっとハードウェア寄りの概念で、
最終的に２Dに変換された座標を、ディスプレイの平面上にピクセル（点）を描くときに、
ピクセルAとBどっちが手前にある＆どっちが隠れるかをビデオカードが判別するためのもの。
ちなみにだいぶ昔はZバッファではなくZソートという手法が使われてて、
頂点ごとではなくポリゴンごとにZ値を保存していた。
だから交差するポリゴンは正常に描画できない（ちらつく）という問題があった
（プレステ１やサターンを思いだせばわかる）。

もうひとつは、行列について（プロジェクション行列やら透視変換やら言ってたやつね）。
もし高校で行列を習ったことがあるなら教科書をひっぱりだしてくるべし。
行列というのは、線形代数に使われる計算で、
「ベクトル（≒座標と考えて良い）を、ある空間から別の空間に変換する」性質がある。
あるオブジェクトのローカル座標を、ワールド空間における座標に変換できるのもソレ。
回転や移動もそう。ある座標Vに対し、
cosΘ 0 -sinΘ 0
0 1 0 0
sinΘ 0 cosΘ 0
0 0 0 1
この行列を掛けると、Y軸を中心としてVをΘ度だけ回転した座標が出てくる。
手計算でやってみそ（めんどくさいがｗ）。
この行列を作ってくれる関数が、D3DXMatrixRotationY()なのね。

透視変換（カメラから見た３次元座標を、スクリーンの２Ｄ座標系に
変換する行列計算）も、同じように４×４行列の計算で出来ている。
D3DXMatrixPerspectiveFovLH/RH()がそう（>>408）。
今調べてみたんだが、本当はその行列自体で遠近感を表現できるわけでは
ないらしい。が、その計算結果のw（(x, y, z, w)のw）でxとyをそれぞれ割るらしいのだ。
そしてそのwはzに比例する（z/d dは前面クリッピング距離）ので、
遠いところにある＝zの大きい座標ほど、xとyが小さい値になるのだ（つまり小さく見える）。

それぞれの行列の何行何列が何になってるかを暗記してるような人は
そうそう居ないと思うが、大抵この辺りの基礎は漠然と知ってるのが普通なんだな。
というわけで突っ込まれても当たり前ということだｗ
突っ込まれたら、とりあえずは自分のコードや知識を疑ってみるべし。そしてちゃんと礼も言えｗ
何の回答にもなってないレスは無視する他ないけどな。

ところで透視変換行列で出てきたwでx, yを割る処理は、
シェーダのコードですら見たことないから、
「最終的に出てきた(x, y, z, w)のxとyをwで割り、zをzバッファに入れる」
という処理はシェーダでもいじれない、完全にDirectXが勝手に行う
処理なんだろーか？？

長文＆スレ汚しスマソ、久々に回答しようとして調べてたら
楽しくなってダラダラ書いてしまった・・・

>「最終的に出てきた(x, y, z, w)のxとyをwで割り、zをzバッファに入れる」
>という処理はシェーダでもいじれない、完全にDirectXが勝手に行う
そうだね、基本的にＶｅｒｔｅｘShaderは同次座標を返すもんらしいので。
xyzwのwの概念は難しい、座標(4,4,4,2)と座標(2,2,2,1)は
3次元の世界では同じ位置になるらしい。よくわからんが。

ところで、GPUにはサーフェス⇔サーフェイスまたはテクスチャ⇔テクスチャの
コピーって機能はないのかな？これがあればやGPUだけでやれることの幅が広がるのだが。

>>443
StretchRect

>>444
それはレンダーターゲットじゃなきゃだめだよねえ
もっと具体的に言うと、頂点バッファレンダリングがやりたかったんだが
最新の環境じゃなきゃ無理かなぁ

頂点バッファレンダリングってなんぞ？

唐突の質問でごめんなさい。
DirectXを使ったポリゲーとかのモデルデータは主にどんなソフトを
使用して造られてますか？
色々調べたのですがPOSERで基本的なモデルを造ってShadeで加工して
骨を入れたりできるんですかね？

3DSMAX

俺、LightWave。 たまにメタセコも使う。

Carrara5
セーブデータがテキストなんでコンバータ作るのが楽。

現実的な値段で言うとCarrara5ですね・・・POSERも対応できるし・・・

俺はLightwaveだな。
何気に今かなり安いし。

Lightwaveが多いな・・・俺もだが。
4大ソフト以外を選ぶときは、XFileが吐けるかどうかぐらいはチェックしとけよ。

つまりBlenderを使う私は生きていてはいけない。
私は死ぬべきだ私はゴミでありクズだ。
私は死ななければならない私は存在してはならない。
私の価値は存在しない私は消滅しなければならない。

>>372
>>375
>>382
>>454
　
そのネタつまらないから。

>>446
頂点バッファをレンダリングターゲットにして
GPUで構築する技術
まあ過渡期のもので気にすることなし

ＸＮＡでゲーム造りたい人で一番安上がりなモデリングソフトは何ですか？
ぶっちゃけ統合環境は只同然で手に入るけど３ｄソフトが馬鹿高いので敷居は
そのままのような・・・

>>457
フリーので十分

んーでもWindowsは描画系が弱いから、ボードゲームみたいな感じのもの以外の
ゲームを動かすのはかなりきびしいんじゃないかな。
昔はプログラムからハードを直接叩いて描画の高速化とかできたけど、
今のWindowsXPとかではそんなのは不可能だし、正直ゲームには向いてない気がする。

ねーよｗ

>>459が何をいってるのか分からない

10年前ぐらいからタイムスリップしてきたのか？

W・I・N・G！ W・I・N・G！

え？WinGってウインジーじゃなくてウイングって呼ぶの？？

>>459
ねーねー、誤爆さん。
本当はどこに投下するつもりだったの？この珍発言。

>>459
おまえはWindowsのゲーム見たことないのか

>>443
同次座標調べてみますた。
むず；；；；；；
まぁありがとっすー。また一つ賢くなったかも？(つ´∀｀)つ

>>459
Windows3.1〜95までしかまともにさわったことのない上司のウンチクを
真に受けてしまった可哀相な人発見
何の分野でコード書いてるのか気になって眠れなかったじゃないか

>>459の釣りしっぷりにﾜﾛﾀ

>>447
モデルを造るソフトから造った。

>>447
モデルはLightwave、テクスチャはPhotoshop
ビックカメラやヨドバシカメラならほどほどのお値段で買えて
ボーンやアニメーションなど機能的にも満足。

>>459の人気ぶりにshit!!!

AliceSoftあたりってまだそんな感じじゃないの？

数年前あたりのAliceSoftのゲームやったことあるけど、
グラボ弱い環境の人のために２D描画はDirectGraphicsは使わずに
MMXやSSEでのみ高速化してるっぽかった。
DirectSoundは使ってたけどソフトウェアエミュレーションがデフォになってて、

３Dのダンジョンなんかは、ソフトウェアの自前レンダラーがデフォで、
Direct3Dはオプションだった（ダンジョン自体ローポリだから余裕っぽい）。
最近出てるのはどうなのか知らない

そういうのは、もうFlashでいいんじゃないかと思うw

昔の人は大変だったんですね

いや、今でもアリスのソフトはそんな感じ。

新作ではさらにグラフィックの負荷落ちてるからな。

それでやっていけるのはむしろ羨ましい。
DirectXのバージョン追っかけるのはもう疲れたよ('A`)

逆に言えば今の状態がアリスの限界ということになるな。
ゲーム自体は10年前からまったく進化してないしな。

そもそもそんな3Dバリバリは求められてないだろうしなあ。
3Dエロゲはネタとしては面白いけど客層選ぶし。
自前でレンダリングした方が環境差は出にくそうだし、
限界っていうか最適解の一つって感じじゃないかな。

つまり学歴が一番重要なのですね
私は生きていてはいけないのです

まぁアリスはエロゲ会社だしな。
路線としては正しいわな。

入りたいとは思わないがｗ

じゃあ死ねばいいじゃん。

>>480
きめぇ！

>>372
>>375
>>382
>>454
>>480

そのネタもう秋田から。

ＡＤＶは仕方ないとしても、戦○ランスはＳＬＧなんだから
幾らでも３Ｄ演出の必要性があるはずなのに、
戦闘シーンなんか、完全２Ｄだったからな‥

ちなみに昔のアリスは決して保守的（懐古的）じゃなく、エロゲ初の
ＨＤ専用ゲームを出したり、マニア以外誰も持たないような
256色Ｇボード専用のゲームを出して、ファンに購入させたりと
結構無茶な事をやってた。

アンケート結果で、ユーザーの大半が低スペックマシンを使ってたんじゃね？
エロゲユーザーはFPSユーザーと違って、ゲームのためにマシン買い換える
なんて人少ないだろうし。
そんなうちのPCもつい最近までラデ8500LEでCPU1Ghz未満だったもんなｗ

8500なら全然ましだぞ？
ｴﾛｹﾞやってるヤツの中にはMatroxのG400とかもいたりする。

G400なんて、もう絵描きくらいしか使わんよなｗ

>ＡＤＶは仕方ないとしても、戦○ランスはＳＬＧなんだから
>幾らでも３Ｄ演出の必要性があるはずなのに、

いや、面白かったよ。
面白さは２Ｄ、３Ｄあんまり関係ないなと思った。

戦略SLGでマップを３Dにしても見づらいだけだからな・・・。

どう見づらくなるのか理解できん
３Ｄの舞台に板ポリゴンを配置するだけでも、臨場感は
全然違うものになるはずだが

3Dにして見づらいのは全部そうだから逃げにすぎない。
プログラマの社内権力は>>459の思想でガッチリ固めてるだろうな。
でももう偏屈な頑固職人でしかないだろ。あんまり誉めそやしてもな。
Ｌｅａｆなんかはもっと柔軟そうじゃないか。

エロゲはもういいよキモヲタども

Leafは調べもしないでGPLのライブラリ使って
関連ゲーム全部ソース公開する羽目になったジャマイカ。

ソースは実費負担だったけど誰か応募した？

エロゲーなんて全くやらない

GPLだから普通にその辺で誰かが配布してたよ
つかLeafもDirectXとかに頼らず自前で描画してたと思うが

GamDevPukiWiki - ToHeart2ほかAquaPlus/LeafのGPLゲーをいじるスレ
http://gamdev.org/w/?%5B%5BToHeart2%A4%DB%A4%ABAquaPlus%2FLeaf%A4%CEGPL%A5%B2%A1%BC%A4%F2%A4%A4%A4%B8%A4%EB%A5%B9%A5%EC%5D%5D
ToHeart2 ほか AquaPlus/LeafのGPLゲーをいじるスレ
http://pc11.2ch.net/test/read.cgi/gamedev/1134405228/

>MatroxのG400
それでも３Ｄは頂点シェーダまで普通に動く

>>499
GeForce3から4世代ぐらい前のボードで
シェーダー動かせる訳ないだろ、このマンカスッ！！

>>499
G400はHardwareTnLすらないからCPUでエミュレートだぞｗ

さすがにもうシェーダー1.1も搭載してないのは切っていいと思う

G400みたいな糞、見捨てればいいじゃない

1.1も微妙じゃない？
6600レベルで3.0積んでて5000円ちょいで買えるし其の位を最低基準にしてもらいたい・・・

G400は別に糞じゃないだろ
古いから乗り換えした方が良いと思うけど

G400は当時のビデオカードとしては2Dそこそこ、3D激遅、唯一バンプマップの対応だけ早かった。

誰かパフェリアのコトを思い出してやれ

>>504
とはいっても、どの世代でも廉価版カードのメモリ帯域とフィルレートは最低だからなぁ。
ファン無しロープロファイルの最新のカードでSM3.0動きますよーたって本当に「動くだけ」。
結局、重いのに耐えられなくて2世代前のカードのような使い方しかしない。
SM3.0対応ゲームを買っても画質設定を最低にして遊ぶでしょ。

ちなみにゲフォ6600ってメモリバス64bitの地雷カードあったでしょ。

２Dスプライトメインなら6600でも十分だぜ
拡大縮小回転はバーテックスシェーダーに、
加算合成やモーフィング、トランジエントはピクセルシェーダーに投げてやれば
4年前買った安物PCでも500fpsとか出てうっひょーってなる

64bitあればマシだな。
俺が買った牛丼PCに入ってる6200TCはメモリバス32bitだよ。
画面のプロパティ->アダプタ ではメモリサイズ128MBって表示されるけど
実際にはローカルメモリ16MBだから。オンボじゃないのにUMAだから。
SM3.0対応だけどIntel製チップセットの内蔵グラフィックス機能より重いから。

あぁ、でもフルスクリーンモードでテクスチャ最小限で
ローポリモデルを複製描画すると超速だよー。
市販ゲーでは考えられない運用方法だから気を付けようねー。

>>510
6600でなくても十分だからｗ

固定機能のレンダリングパイプでも余裕で出来るエフェクトまで
わざわざピクセルシェーダを組んでやろうとするのは不毛。ただのイジメだよ。

だって楽じゃん。

[Geforce4MX].｡oO（ﾎﾞｸは要らない子。。。ﾎﾞｸは要らない子。。。ﾌﾞﾂﾌﾞﾂ

SetTransformすら面倒なんだもん。だから固定機能いらない

２DゲームならGeForcre2でも十分だ。
そんなん作りたくないけど。

>>517
SetTransformはあまり関係ねーな。
あれはジオメトリパイプラインに渡すデータだから頂点シェーダーの話。
頂点シェーダーはソフトウェアエミュレーションで対応できるから問題なし。

あれはジオメトリパイプラインに渡すデータだから頂点シェーダーの話。
　↓
あれは固定機能のジオメトリパイプラインに渡すデータだから
お前の話は単に頂点シェーダーを使いたいってだけの話だろ。

>>500-501
だから、動くだろ？

動くわけがねぇｗ

CPUでエミュレートすれば動くだろ。

CPUエミュはハード関係ないじゃんｗ

>>524
だから動くだろ？っていってるわけ。大丈夫？
べつにハード使って動くとは言ってない

シェーダってDirect3Dでソフトウェアエミュレーションできるんですか？
知らんかったっていうか自分のコードだとDrawSubset(i)でバグる・・・
何か指定せんとあかんのでしょうか？

バグってるのはあーたのソースだ。

出来ました、CreateDeviceでD3DDEVTYPE_REFを指定するだけじゃなくて
D3DCREATE_HARDWARE_VERTEXPROCESSINGを指定しないとダメなんですね。
理屈はよくわからんけど・・・
リファレンスラスタライザの中で、ハードウェア頂点処理（のエミュレーション）を
させることにしておかないと、プログラマブルシェーダのエミュレーションも
出来ねーよ、ということかな。

>>526
＞シェーダってDirect3Dでソフトウェアエミュレーションできるんですか？

スレ嫁この文盲。
「シェーダー」じゃなくて「頂点シェーダー」のソフトエミュの話だよ。

>>528
なんでリファレンスラスタライザなんて糞重いものの話になるんだよ。
「頂点シェーダー」はHALデバイスでもCPUで処理させることできるだろ。

>>529
やってみたんですが出来んかった・・・

・D3DDEVTYPE_HALとD3DCREATE_SOFTWARE_VERTEXPROCESSINGを指定してCreateDevice
・ピクセルシェーダは使わずに頂点シェーダのみ指定
これ以外に何か条件あります？

自分のコードがDX9のHLSL用なんでエフェクトファイルの中で
アセンブリ記述のVSだけを
VertexShader = <asm_hoge_vs>;
みたいに指定してやってみたんですが動きませんでした・・・

HLSLのSetTechniqueじゃなくて従来のSetVertexShaderとかじゃないと
ダメってことですかね。
できれば詳しいこと教えて欲しいっす

>>530
SkinnedMesh Sampleも動かないの？

＞SkinnedMesh
むむ、HLSLで動きました・・・原因がよくわからないなぁ・・
ありがとうございます、色々書き直して試してみます〜

原因ってそんな難しいことはしてないと思うぞ・・・・・・

いや、自分のソースで動かない原因ですｗ
多少ごちゃごちゃしてるので見直さないと・・・

Displacement mappingってあるっしょ
あれって前もってある程度ポリゴンが細かくないと凹凸は表現できない？
それともかなりのローポリでも自動でポリゴン分割とかしてくれるわけ？

>>535
自動的に分割される。
そして分割をﾊｰﾄﾞｳｪｱ的にサポートしてないと利用できない。
さらに分割をﾊｰﾄﾞｳｪｱ的にサポートしていたのはパフェリアしかなかった悪寒。

今はSM3.0を使えば頂点テクスチャが使えるので、ディスプレイスメントマップは
自分でシェーダーで組むのがスマート。

皆さん学歴高いですね

低学歴は生きていて恥ずかしいから自殺しちゃうんじゃない？

なんでいきなり学歴の話になるのか

いまは誰でも入れるから＞大学

その割には予備校は依然儲かっているようだがな

予備校に入ればが前提なんだろう

人間の価値は学歴です
私は死ななければなりません
私はゴミです私はカスです
皆さんエリートです

ああ、MIT以外は虫けらだｗ

>>372
>>375
>>382
>>454
>>480
>>537
>>543

そのネタもう秋田から。

インド人が脳ミソ、学歴ともに最強なので、我々低脳民族は死ななければならないな。

MITよりインド工科大が最強ってあったな

はいはい。武蔵工武蔵工。

IQ高くて賢くても、現実では余り生産性に繋がりにくいよね。
まぁ大学の研究室でシコシコ教授の手伝いして十年位奉仕してから独自の
研究とかして日の目を観るみたいな事で還元はできるだろうけど、
必ずしも万人がその事に従事するわけではないので大半の人間が学歴は高い
けど中途半端な業で終わってしまうという現実。

>>544-549
釣る奴も釣られる奴も荒らしなんだぜ

■学歴板
　　http://tmp6.2ch.net/joke/
■大学受験板
　　http://ex21.2ch.net/kouri/

荒らし認定されるのを恐れることなく、書きたいことは書くべき。

なぁ、SM4.0がVistaでしか使えないのは何でなんだぜ？
未だにEAXもまともに使えないVistaになんか移行できねーよ。

>>552
Direct3D10がVISTAでしか動かないから。

というのはいいとしてXPのときだって最初かカオスだったんだし
MSのOSはSP1がリリースされてからが本番さ。

俺はXPで8800の新機能を使うためにOpenGL使い始めたよ。

そういや二強GPUメーカーのガチ対立の構図になって以来
OpenGL対Direct3DみたいなAPIの比較論はすっかりどうでもよくなったな。

技術的にはＷｉｎ９８でもＤｉｒｅｃｔＸ１０動くの？ＭＳが出し渋ってるだけで。

そりゃ頑張れば対応できるけど
頑張っただけの対価に見合わないとかいろんな事情があるんだろ

>>555-556
そんな話にはならんだろ
そもそもグラボ、オンボードならマザボのドライバがwin98に対応してないじゃん
ＭＳだけ頑張っても駄目だし、ドライバだけ作っても駄目だし。

>>555
つーか、お前。未だにWin98とか使ってるゴミユーザーが
DirectX10必要だと思うか？SM4.0使わない限りDirectX9以下で
十分なんだぞ？Win98ユーザーがゲフォ8800買うか？ｗｗｗｗ

とりあえずSM4.0がXPで使えないまま放置になったのはMSの都合だな。
Vistaへの乗り換えを促すため。それ以外に何があるってんだ。

NVIDIAは8800用にOpenGL拡張命令を定義してるし。XPでも使えるし。

>>557
だからそういうのを含めて頑張ったところで対価に見合わないってことだよ

つか>>556の書き込みってMS様の忠犬ぶりを無駄にアピールしてて
釣り臭いんだがｗ

＞そりゃ頑張れば対応できるけど

テメェごときがMS様の気持ちを分かったつもりになってんじゃねーよカスｗ

＞頑張っただけの対価に見合わないとかいろんな事情があるんだろ

テメェごときがMS様の気持ちを分かったつもりになってんじゃねーよカスｗｗ

>>560-561

お前達は黙ってゲイツ様のチンポでもしゃぶってろです。
Win98環境はネットに接続せずにレトロゲー(Voodooゲーとか)
専用機として使うのが通のたしなみ。

Voodooﾅﾂｶｼｽ
Voodoo系のゲームって、なんか画面が明るくて
テクスチャが細かくて、Direct3Dのゲームとは違う味があったような。
ああいうのってどういうとこから来るんだろう？
テクスチャのサイズ制限がきついからどうしても
小さいテクスチャを敷き詰めた感じになりやすいのかな
それを差し引いてもなんか独特の味を感じるんだよなぁ

Windows2000ですら何年前のOSだと思ってるんだｗ

>>563
ビデオカードによって色味が違うのは基本的にはDACの違い。
Voodoo系カード独特の発色はDACでのガンマ補正・コントラスト調整が
ちょっとおかしかったから。（フレームバッファのカラー値は平凡なもの）
16bitカラーのフレームバッファを綺麗に出力するための工夫だと思う。

今時のGPUでもドライバ設定でガンマ補正やコントラストを調整すれば
Voodooぽい色味で出力させることができるよ。

他人を罵るしか脳がない低学歴が湧いたかと思えば、
次の瞬間には技術トークに戻っている…。
ダブルバッファリングかよ。

...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
..................................................................................................................................

...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
..................................................................................................................................

...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
..................................................................................................................................

...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
..................................................................................................................................

...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
..................................................................................................................................

もう飽きたのか

>>559
OpenGL/GLSLならWinXPでもジオメトリシェーダーでウハウハみたいだな。
HLSLとGLSLの文法がほぼ同じだし、移行は案外楽そうだね。

どっちみちハードウェアが1種類しかないし。
10.1がリリースされるあたりまでは微妙だねぇ。

研究用にはいいがゲームは使えないんじゃしょーがない。

...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
..................................................................................................................................

Displacement mappingってマトモに使われてるタイトル無いな
nVIDIA DemoのLunaしかしらねえ
なんかDx11でも未だにDisplacement mappingとか出てるし

DirectXの機能として実装されたDisplacement Mappingは確かにぜんぜん使われてないが、
頂点テクスチャ参照機能を使ったものなら幾つかあるぞ。

汎用性をみても頂点テクスチャを使う方法が今後の主流になると思われ。

ポーズしたときその時点の画面をぼかしたりセピアにしたりのエフェクトかけたいんですけど
テクスチャのピクセルはどうやったら直接いじれるんでしょ？無理？

画面全体にエフェクトをかけるのなら
テクスチャのピクセルをいじる必要がないと思うんだが

そんなエフェクト使ったところでゲームの面白さとは全く無関係。
やろうとするだけ無駄。別の部分に労力を割くべきだな。

A StretchRectでバックバッファをテクスチャにコピーしてピクセルシェーダで色々する
B GetFrontBufferDataでシステムメモリのサーフェイスに取り込んで手動で加工

>>581
Aは最初からテクスチャにレンダリングしたほうがよくね？

まぁ普通はピクセルシェーダー使うよな。

・R8G8B8A8のフォーマット
・変換擬似HDR
・アルファブレンディング対応

以上の条件で良い方法を探しているんだが
何かありますか？

< 単位ベクトル, 長さ >
< 指数, 仮数 >
この変換ではアルファブレンディングに対応できないようで・・

エンコード
Color.rgb /= MAX_HDR_RANGE;

デコード
Color.rgb *= MAX_HDR_RANGE;


フィルタリングやアルファブレンドが可能で、
クロック数も少ない方法でございます。

>>584
単位ベクトルなら1成分省略できるが。 z=√(1-x^2-y^2)

...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
...................................................................................................................................
..................................................................................................................................

>>585
その方法は思いつきませんでした。
例えば8倍のダイナミックレンジを要する場合
R5G5B5の精度まで落ちるということですか？
んー微妙な値ですね。

>>586
それは知ってます。
さらにルックアップテーブル化するといい感じですよね。

精度がほしけりゃ素直にA16R16G16B16使いなさいよ。

ピクセルシェーダーでの圧縮解凍が必要な時点でPS2.0は
最低条件なんだから浮動小数点バッファが使えないわけないじゃろ。

浮動小数点バッファでメモリ使用量を気にしてるのか、
バンド幅を気にしてるのかはしらんが、
圧縮解凍のコストが高くなると結局処理は遅くなる。

>>589
自分の描画エンジンはマルチパスブレンディングが主になってます。
1パス目：ポイントライト
+ 2パス目：スポットライト...
+ nパス目：デカーリング　のような感じです。

LDRではこれで問題なかったんですが
HDRではFPバッファへのレンダリングが必要となり
自分のマシンではFPバッファのアルファブレンディングが出来ない為
何か打開案が必要になったという理由です。

マルチパスブレンディングをシェーダ代替することは出来なくはないですが
エンジンの大幅な改修を要すること、LDRの場合無駄が大きい、描画負荷が大きい
以上の理由でなるべくやりたくないんです。

んじゃ素直に精度を犠牲にするかPPP法あたりを使うかじゃね。

PPP法ってなんすか？

光ファイバーが当たり前の時代にPPPって…

http://www.google.co.jp/search?hl=ja&rlz=1T4GGLJ_jaJP176JP176&sa=N&resnum=1&q=ppp%20method%203d&ie=UTF-8&oe=UTF-8&um=1&tab=iw

分からん。もっとヒントくれ

正規化して保存するやつっすね

PPPが何の略かくらい教えてくれよ

PPP、PPP、PPP、PPP

ろくなもんじゃねぇ！

prerenderred perspective primitives

右下のテクスチャ座標を(2.0,2.0)とかにすると元のテクスチャを4個並べたテクスチャで
いっきに描画されるんですけど、この挙動って保証されてないんでしょうかね？

>>599
テクスチャアドレッシングモードとテクスチャラッピングの設定による。
ttp://msdn.microsoft.com/library/ja/DirectX9_c/directx/graphics/programmingguide/fixedfunction/textures/basic/textureaddressmodes/addressmodes.asp
ttp://msdn.microsoft.com/library/ja/DirectX9_c/directx/graphics/programmingguide/fixedfunction/textures/texturewrapping.asp
っていうかヘルプくらい嫁。基礎すぎる。

3dsmaxからXproterを使用して出力したＸ形式のファイルを読込み、座標変換することなく
画面出力したら、正面ではなく真下から見下ろした画像が出力されたのですが、これは仕様
なのでしょうか？

===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================
===========================終了===========================

MAXは座標系が独特。
特許の問題で金払うのが嫌でそうなってるとか

>>603
そうだったんですね…。諦めて座標回転させようと思います。
ありがとうございました。

MAXが独特とか何でそんな無茶苦茶な発言が出るのか全く理解できないが、
単に右手座標系と左手座標系の違い。
Direct3Dのサンプルと座標系が逆になっていて、奥行きと高さの軸が入れ替わっているだけ。
モデラーとしてはMAXの方がスタンダード。

俺が知る限りZが奥行きじゃないのはMAX含むCAD系だけ。
左手右手に関してはどっちもあるが殆どのソフトやAPIがZ=奥行きだし。

左右の違いなら別に面倒なことは何もないが、
MAXが特殊だっていってるのはZが高さになってる所だよ。

スタンダードとかどうでもいい

右手座標系 - OpenGL
左手座標系 - Direct3D

>>606
＞左手右手に関してはどっちもあるが殆どのソフトやAPIがZ=奥行きだし。

OpenGL等のAPIで「Z=奥行き」の規定があるのはビュー変換以降（カメラ空間・同次クリップ空間）だけで、
ワールド空間でZ軸をどっちに向けようが勝手なんだけど・・・。
（厳密に言えば、射影行列に回転要素を含めればカメラ空間さえも「Z=奥行き」である必要はない。）
ただ単に、ゲーム系ではワールド空間でY軸を上方向にする慣習が根付いてるというだけで、
APIの仕様とは一切無関係の話として理解すべき。

同様に、右手系・左手系についても、
APIの仕様で縛られているのは射影変換後の一番最後の同次クリップ空間だけなので、
それ以前のカメラ空間やワールド空間に関しては、
Direct3Dで右手系を使ったりOpenGLで左手系を使ったりも自由にできる。
そのためにD3DXに*LH系と*RH系の関数が用意されているわけで。

プログラムを作る上では、右手か左手かは自由に決めることができるが、
モデラーの仕様は自分で自由にカスタマイズというわけにはいかないからな・・・

最終的にメタセコに通して座標変換すりゃおｋ

>>611
ボーンアニメーション付きのものとかどうするんだよｗ

>>612
mikoto

全てはメタセコで解決。maxはどうもなぁ…shadeはお話にもならない。

俺は、半分くらいはposerで解決。

Xproter自体にも問題ありだよな。テクスチャ情報は関連付けられないし。
maxダメポ。

ぷよーん作？
サイトの色彩感覚とかもそんな感じなんだけど

>>616
テクスチャ情報はちゃんと入ってるぞ。
なんか情報が逆っぽいから読み込んだ後プログラム側で直してるけど。

DirectShowサンプルのVMR9Allocatorで使ってる
IVMRSurfaceAllocatorNotify9::SetD3D()がE_NOINTERFACEを
返す原因を誰か知りませんか？

リファレンス見てもS_OKしか返さないとか書かれていたり、
サンプルは動いているのでウィンドウの作り方か。

グラボに依存して出たりでなかったりのようなので、
デバイスの作り方が怪しいのではないかとおもって色々変更しても分からず・・・。

ヘボいオンボードのビデオカードとかサポート切りたい。
でもスペック表見ないで買うバカもいるからなぁ・・・。

透明で発光してるレーザーとかどうしたらきれいに描画できるかね
普通にBLEND_ONE + BLEND_ONEだとどうしても白飛びしすぎる気がするんだ
DEST INVSRCALPHA + SRC BLEND_ONE だと素材作りがめんどい

手を抜くな

死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね

「透明で発光してる」て何だ？

透明ならアルファを０にして描画すればいいよ。
たぶんすっごく速いよ

>>621
背景を暗くしろ。

DirectsoundでADPCMのデータを再生したい場合、
自力でPCMにデコードしないとダメなんでしょうか？

DirectSoundを使う場合は、そうです。
DirectShowを使う場合ｈ

>>627
thanks

ADPCMのデコードか…。
アルゴリズムの情報全然見つからないし、きついですね…。

ADPCMなんて小学生でもデコードできると思うが

うーん、
概要だけで具体的な圧縮方法がわからないから、結構苦戦。（ググっても見つからないし）
soxのソースとか見たんだけど、
「こうすればうまくいくっぽい」って事が分かっただけで、
結局意味はわからないし。

ACM使うんじゃ駄目なん？

えーマジADPCM !?
ADPCMが許されるのは小学生までだよねー

DiretctMusicでよめばかってにデコードしてストリーム再生してくれるだろ。
いまさら圧縮WAVなんて使わないけど。

DiretctMusictってまだMicrosoftが見捨ててないの？

見捨ててないっつーかDirectXAudioに統合されてそれっきり。
その時にDirectMusicでのWav読み込み＆再生がサポートされた。

とはいっても大体市販も含めてゲームで使うならOggが殆どじゃね。

Geforce7900GSに換えてからDirectX Texture Toolを使うと
Unable to create Direct3D Device. Please make sure your desktop color depth is 16 or 32 bit.
と16bitか32bitか、確認して下さいとでので
カラー品質を弄くってるのですがなかなかエラーが消えない

これは新しいＳＤＫ入れるとかしないといけないのでしょうか
ググっても日本語は１件しか引っかからない、しかもスルーされていた・・・！

カラー品質ってどんな頓珍漢なところをいじっているんだ？

>636
そのエラーメッセージに続きは無いの？
d3dref.dllとか

>>637
なんと・・・！
>>638
続きは無いです、Unable〜のみです。

>>646
カラー品質とか関係ないだろ。

>>636
> ググっても日本語は１件しか引っかからない、しかもスルーされていた・・・！

http://www.gamedev.net/community/forums/topic.asp?topic_id=255261

>>640
color depth とあったもんで
>>641
エキサイトにぶち込んだ所再インストールをやってるみたいですね。
ダウンロードに４時間かかるみたいなので、結果はまたその内

３０分だった、変な所みてたなｗ

４時間とか表示されてた割には速く済んだ
Feb2007のを入れたらDirectX Texture Toolは問題なく起動しました。
数々のレス有難うございました。

>>642
＞color depth とあったもんで

depthに品質という意味は全く無い。
color depthは直訳すれば色「深度」。
色「品質」ならcolor qualityだよ。

LightWave上で作成されたNULLオブジェクトをXファイルで出力して、
プログラム上でそのXファイルから座標を取り出す方法ってあるんですか？

NULLオブジェクトつってもXファイル上じゃただのFrameなわけで、
普通に座標とってくりゃいいだろ。


まぁLightwave使ってるならそのままコンバーター書いたほうが便利だけど。
UV複数持ったりアニメーションの補間処理も細かく制御できるし。

Frameっていうとスキンメッシュのフレーム関係と同じ意味ですか？

つーかBBXとのマルチやめろ

内容読んでも答えてやる人に対しての敬意がまったく感じられん

SDKのヘルプのXファイルの項目を読んでいないのなら問題外だし、
読んだ上で理解できないのなら頭が悪すぎる。

Directplay Voiceを使ってボイスチャットを実装したいと思ってるのですが
マシンAで開いたセッションに、

lpDirectPlayVoiceClient->Connect( &sndConfig ,&clientConfig, DVFLAGS_SYNC );

って感じの関数で、マシンAとマシンBからセッションに接続して

DVID dvid = DVID_ALLPLAYERS;//全員と会話
hr = lpDirectPlayVoiceClient->SetTransmitTargets(&dvid, 1, 0);

で話し相手を指定してあげればボイスチャットが開始されると思って
いたんですが、相手のPCに声のデータが届きません。
会話の開始にはさらに何かの処理が必要なのでしょうか？

接続やマイクテストは上手く言っており、ボイスチャットに利用したピア
インターフェースを利用して文字列データ等は相手のPCに届くのですが…。

ボイスチャットの良いサンプルソース等無いでしょうか？

DiretPlayを使うなんて、神々しくて直視できないくらい眩しい。

>>652
まぁ、DirectPlayはメモリリーク等の悪い噂も良く聞きますね。
メインの通信にはwinsockを使っているのですが、ボイスチャットに関しては
Directx以外の手段を知らないのでとりあえずDirectPlayを選択しています。

とはいえ、セッション開始マシンが抜けた後のセッション引き継ぎ処理
なんかを自動でやってくれるのはなかなか良さ気な気配はしてます。
（まだ動くとこまでいってないので説得力無いですが…）

ボイスチャット関連で他に良さそうなライブラリ等ありましたらご教授
くだされ。

DiretPlay!!!!
DiretPlay!!!!
DiretPlay!!!!
DiretPlay!!!!
DiretPlay!!!!

何このDirectPlayのおちょくられっぷり。

やっぱり。「DirectX9実践プログラミング」もう一冊買うしかないのか！？
あれにDirectPlayVoiceのサンプルがあるのは知ってるんだがCDを
紛失してしまったんだよなぁ…。orz

誰か！DirectVoiceのサンプルソース知ってたらご教授くだされ！

DirectVoice!!!!
DirectVoice!!!!
DirectVoice!!!!
DirectVoice!!!!
DirectVoice!!!!

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

　 DXreadme (December 2004) より。



なるほど、そういうことかー。（＾＾

Fuck!

サンプルはDirectXSDK2003summerのサンプルの中にありましたので自己解決です。

いや、しかしですよ。winsockは低レベル言語過ぎて、実装が結構大変。
そう考えるとセッションとかその辺をDirectX側でやってくれるDirectPlayは
悪い選択ではないと思うのです。

ボイスチャットはSkypeAPIとかで代用できるとしても、データ転送は
DirectPlayの選択肢が無くなったら大分マズいというか、何か他に便利な
通信ライブラリとか存在するんでしょうか

ないない
無いから作って

嫌味でもなんでもなくID:LAL+zJf0氏にはDirectPlayを極めて、
伝道師になってもらいたいくらいだが、
何かで躓いた時に原因追求or回避策を練るくらいなら、
WinSockで書いたほうが早いと信じきってる俺ガイル。
なんと言っても既に使い尽くされて、
バグの泉が枯れきってるあたりがいい。

>>658

＞悪い選択ではないと思うのです。
悪い選択か良い選択かは最終的にお前さんが判断するべきことだろうが、
ヘルプははかなり以前からDirectPlayの項目が存在しないだけでなく
明確に「使うな」と書いてある。（日本語ヘルプは知らん）

３年前のヘルプなんぞ読む暇があるのなら少しは
今の時代の資料を調べることに費やそうとは思わないのかね

DirectPlayのロビーとボイスチャットは魅力的だけどねぇ。
ボイスチャットはともかく、ロビー機能はMSが作ってくれないと
どうしようもないな。
まぁ、DirectPlayのロビーが流行ってたのなんて8年くらい前の話だが。

ま、個人開発≒個人運営＝個人回線だから、
ボイスチャットなんて重くなりそうなものは、
メッセンジャーでもなんでも他の鯖上で動くモノを使うのがいいし、
ぶちゃけﾒﾝﾄﾞｳ。

>>658
データ転送こそWinSockの方がらくだと思うんだが。
VoiceChatをWinSockで実装するのはﾃﾗﾒﾝﾄﾞｸｻｽだが・・・。

SDK(April 2007)でまたHLSLコンパイラの挙動が変わったようだ。

以前は以下のパスはOKだった。
#include "HLSL Programs\SkinningFunctions.hlsl"

今回はこうしなきゃNGになった。
fxc ... /I"HLSL Programs" ...
#include <SkinningFunctions.hlsl>

いい加減、VerUPの度にソース修正させるのは
やめよろよといいたい・・。以上グチ

外部から入ってきた連中が主導権を握るようになってからDXはボロボロ
98荒してDX荒してXP荒して・・・何がしたいのかね

今のDLL祭りとか最低だしな

>>665は変更ではなく機知の問題だそうだ。
いずれ直るかな？

>>外部から入ってきた連中
誰？

CAsyncSocket はダメですかねぇ？

おま、、、まさかMFCじゃ、、、

>>667
ちゅーか、DirectXのWebUpdator再配布させろと・・・

みんなでoct2004と心中しようぜ

ROやスターオーシャンセカンドのキャラクターってビルボードで実装されているんですかね？

当たり判定とかってやっぱり３Ｄ座標軸で行っているんですよね

行っているんですよね、ってあんたはそのゲームの開発者がここにいると思ってんの？

ROに関して言えば、どう見てもビルボードだけど
スターオーシャンはプレイしたことないから分からん。

ROって当たりは取ってるの？あれって立体交差なかったよね？
それなら単なるHeightFieldみたいなのを使えばいいだけの話のような。
(そのデータが狂ってれば、キャラが埋まったりするはず。
そういえば以前そういうマップがあったような…)

ROはどう考えても単純な二次元配列でしょ
ファミコン時代のFFとかと大差ない

あ、そういやカーリッツバーグとか出てくる場所って立体交差あったっけ？
それだと単なる二次元配列だと上手くいかないかも。
もう何年も前のことで正確に覚えてねぇ

ROクライアントのデータの中に各マップのグレイスケール画像があったような
あれが高さ情報になってるんかなと思ってたよ

RO厨UZEEEEEEEE!!!

ROは立体交差ないよ。俺の行った範囲内ではね。
高度は表示上の問題で、鯖処理では考慮されてる形跡はない。
進入不可セルは高度差を考慮して定められているようだけど、
ウンバラは高度差無視して往復できる場所があるし、
たぶん手で設定してるし。
つかキャラが埋まるセルもあったし高度も手で設定臭い。

>>673
スターオーシャンは見た目3Dだけど判定はどう見ても2Dだろｗ

SO2は単純にビルボードじゃん。
一応戦闘では高さの概念があるけどあれは単にAABBで判定してるだけじゃん。

グラフィックが2Dなら、普通はビルボードだろうな

多間接もビルボードって言うんだろうか？

立体交差のフィールドってどう持つのが一般的なの？
ポリゴンから直接計算？

単純に上下2階層分の配列を持って、坂道の途中で切り替えりゃいいだろ

変なのやらせんで普通に3Dやれって

ポリゴンとレイの判定直接取るのが一番簡単だろうな。
コリジョン用に別にまびいたデータもっときゃいいし。

>>188
恐らくLuaの事だと思われ
ツクールのRGSSはRubyよん

誤爆

3Dでも立体交差の無いほうが微妙に単純だし、処理もある程度早い。

DirectPlayのPeerセッションについて質問させて下さい。

Peerセッションが下の三人つのマシンで構成されていた場合
●（静的IPアドレスを持つユーザーA「ホスト」）
○（静的IPアドレスを持たないユーザーB）
○（静的IPアドレスを持たないユーザーC）

Aのマシンがセッションを抜けた場合、ホストの引継ぎが行われ、以下の構成に
なります。

○（静的IPアドレスを持たないユーザーB「ホスト」）
○（静的IPアドレスを持たないユーザーC）

この場合、両者共に静的IPアドレスを所持していないマシン同士での
通信になりますが、通信できるのでしょうか？
（一度静的IPアドレスを持つマシンを介せばskype等のように静的IPアドレスを
　持たないマシン同士でも通信ができる手法があるらしいので恐らくは可能
　だと思うのですが…）

そして、その場合ユーザBのWAN上でのIPアドレスが分かれば別のマシンから
セッションに参加する事が（理論上）出来ると思うのですが可能なのでしょうか？

Winsockなら
・Bのポートを開放済み
・BのIPアドレスをCに通知
でいけると思うが、DirectPlayは全く知らないし知りたいとも思えないスレ違い。

>>691
すいません、どこに書き込んだら良いものか迷ったもので。

ちょっと思ったのですが、ホストであるAのマシンはBCのマシンのWAN上の
IPアドレスと接続ポート番号を把握しているはずです。
という事はホストであるAのマシンが抜けた後も次にホストとなるBの
マシンにCのIPアドレスと接続ポート番号を通知してあげればBとCの
マシンで通信が可能だと思うんです。
（DirectPlayはこのホスト引継ぎ作業をDirectX側でやってくれる）

この場合、Bのポートを開放しておく必要は無いので面倒なポート開放の
作業をカットできるはず＆上記の理論が証明される（？）と思うのですが
テストする環境が無く、なんともかんとも。

いや、すまん。俺の書き込みのほうがスレ違いなんだｗ

Bのルーターでポートブロックしてたらだめなんじゃないかな？

かと思ったがピアツーピアなら、ポート開放しているはずだから、
問題無いのかｗ失敬失敬。

スレ違いではないんじゃないか

>>694は>>691

いや、DirectXスレなんだからWinSockネタはスレ違いｄ(ry

誤解されてるようだがまあいいや

そもそも制作メーカー自らDirectPlayは廃止するから使うなと言っているのに、
未だに使い続ける脳味噌の構造が理解できない。

世の中にはWinSockが使えない方のたくさんいるんです。
通信までサポートしてるライブラリってのもあんまり見かけないしね。

DirectXに長けてらっしゃるスレ有志の方々にお願いがあり
書き込みをさせていただきます。

今まで枯れていなさそうなライブラリをつかって開発してきたのですが
最近パソコンの機種により画像が乱れてしまうバグを見つけてしまいましたorz

ttp://wahiko-web.hp.infoseek.co.jp/cppdou.lzh

ここまで開発してきましたが（注、洞窟物語のクローンです）
枯れているＤＸライブラリで１から組みなおそうかかなり悩んでいます。
今期冬コミに向けて販売する予定なので、かなり切迫しています。
何卒、アドバイスをお願いいたしますm(__)m

ソース無しでどんなアドバイスを期待してるのかわからん

>>700
DXライブラリってコレ？
ttp://homepage2.nifty.com/natupaji/DxLib/
名前はしってるが、俺は使ったことない。

てか、スレちがいじゃねーか？ｗ

>>700
冬コミ諦める

>>701
すみません、
ライブラリの方は
ttp://www.plustarnet.com/aspil/Programming/
の方のを利用させていただいてます。

実装の方はここに書いているとおりにしてみました。
（DirectXはライブラリ任せで直接弄った経験が無いです）

バグは拡大、縮小するときに強制終了してしまうのと
　　　　　　拡大時に画像が乱れてしまうバグの二つです

ＯＳかグラボの仕様で出るのかと考えましたが詳しいことは
分かりません、同じような経験をされた方がいましたらぜひ
ご教授をお願いいたします。

>>704
つーか質問下手だな。
どの環境で強制終了・画像が乱れるのかわからんし、
そもそもそのHPのどこを見てどういう実装したんだよ？

ライブラリってのは
自分でも作れるけど時間がないからとりあえず使う
くらいの心持ちで使うのが常套

手に余る内容なら背伸びし過ぎたと諦めろ

回答側がエスパー能力全開しないと話が進展しない希ガス。

>>705
ＯＳはＭeのノートパソコンで画面乱れ
９８のデスクトップで拡大縮小時以上
ＸＰのＤＥＬＬパソコンでも画面乱れ
グラボは勉強不足でよく存じていません

>>706
たしかに
箴言です。

>>708
逆にどの機種なら正常にでるんだ？

というかビデオカードの名前も知らないでゲームプログラムできるのか・・・。

>>700
グラフィックとかマップとか、ほぼ、そのまんまなクローン・ゲームを
冬コミで販売するのはマズイだろ･･･常識的に考えて･･･

>>709
詳しくは知らないのですが
ライブラリ本家サイトではV-Syncの有無で結構差があるらしく
ハードウェアＴ＆Ｌ、３Ｄハードウェア・アクセラレーション
という機能が導入されていないと難があるようです。
（２Ｄでの開発なので些事なことと考えていましたがorz）

少々スレ違いではありますが、キーレスポンスや画像がしっかり描写
されているか書いていただけるとありがたいです。

失礼ではありますが、明日早いのでそろそろ落ちます。
有難うございました

>>710
無償目的で借りることで承諾をいただきました。
有償目的には使いません。

>>712
許可もらってるなら、いいけど、そういうことは付属のテキストにでも
書いておいたほうがいいよ。

Geforce7600＋XPではキーレスポンス、画像描画共に上手くいってるっぽい。

それにしてもなんという質問下手…
「画面の乱れ」っていうのがどんな症状なのか具体的に書いてあればアドバイス
しやすいかもね。

そのくせ下手に触るとすぐ暴発するパターンだから、
暴発上等で触るべきかどうか、他の住民の出方待ちｗ
半年ROMれとは言わないが、もうちょっと過去ログ読んで、
他の質問者のやり取りを研究したほうがいいのにな。

質問の書き込みをした者です

>>713
次回、気をつけます

>>714
９８は短冊状にぶつ切りにした状態で現れます
ＭＥのノートでは描写がうまくいっていないのか
ぼやけた状態で描写されるときがあります。
DirextXのバージョンを最新版にしてみても、状態は変わりませんでした

Winmainでは以下の関数でウインドウ作っているようなのですが

g_pFormat->Init(MainWndProc, hInstance, nCmdShow, WINDOW_NAME, MENU_SETTING, SAVE_CONFIG, CONFIG_FILE_PATH,
WAIT_V_SYNC, WINDOWED, WIDTH, HEIGHT, FILTERING_ON, ACTIVE_SOUND, &g_pSprite)

仕様が無いのでどう処理しているのか詳しく分かりません


情報が少なくて申し訳ないです
スレ汚しになるのでＲＯＭしなおします

>>716
こういう事がありえるから使うライブラリには気をつけたほうがいい。
「ソースが公開されていない」
「ソースの変更が認められていない」
「作者がすでにサポートを打ち切っている」
このどれかに当てはまるような無償のライブラリは使うのは危険。
有料のミドルウェアなんかは話は別だけどそんなん趣味で使う人いないし。


個人的な偏見と評価

EL：無料、サポート×、ライセンス○、使い勝手△「hにすべて書かれていてインクルードするだけ、作者製作サポート打ち切り」
DX：無料、サポート○、ライセンス○、使い勝手○「ごく普通のhとLibで提供、C言語ベース、開発も活発で３Ｄやらないなら有力」
Lamp：無料、サポート×、ライセンス○、使い勝手△「フレームワーク形式、2年位前から放置されてる」
Luna：無料、サポート○、ライセンス○、使い勝手△「C風で書かれてC++、中身がでかすぎて分かりづらい」
Selene：無料、サポート○、ライセンス○、使い勝手？「インターフェイス形式ですっきりしてるが、C++前提、ツール系そこそこ、3D含めると一番？」
Lue：無料、サポート○、ライセンス○、使い勝手○「知る限り完全にC言語オンリーで利用可能な唯一のライブラリ、ツール系そこそこ、3D含めると一番？」
YJ：有料、サポート○、ライセンスは知らん、使い勝手？「まったく知らん、ツール系は充実してるらしい、３Dもかなり対応ぽい」

海外製のものだとSDLやIRRなんかもあるね。

>>717
詳しいライブラリスペック表、ありがとうございます。
おかげで問題が絞り込めてきました。

問題のライブラリはソース、プログラム共、フリーですが
最終更新が2004.01.08ですから頻繁に更新していないようです

ライブラリから組みなおす改善案となると
枯れてそうなDXライブラリかSeleneがよさそうですね。

>>700
>ここまで開発してきましたが（注、洞窟物語のクローンです）
>枯れているＤＸライブラリで１から組みなおそうかかなり悩んでいます。
>今期冬コミに向けて販売する予定なので、かなり切迫しています。
~~~~~~~~~~~~
>何卒、アドバイスをお願いいたしますm(__)m

>>712
>無償目的で借りることで承諾をいただきました。
~~~~~~~~
>有償目的には使いません。

販売するのに無償って意味不明、俺が読解力がないだけ？

無償目的で借りて、有償で売るんだろ？

良心的に判断すれば、素材は一時的に借りただけで、
販売するまでには、自分で素材用意するって事だろうが、
クローンで「自分で素材用意」しましたって言われても、
誰も信用しないよなｗ

フリーゲームの劣化移植を
金を出して買う奴がいるとは思えん。
が、元が良いだけにちょっとはいそうだね。

なんだかんだで一番かれてるライブラリってWinGLな希ガス

それは枯れ過ぎw

質問。DirectX7で、DPlayで、IDirectPlay4インターフェイスが取得できません。
ヘルプにあるコードをコピペしてやってますが、エラー値が帰ってきます。
エラー値の値は、-2147221008　です。
どうやればうまくいきますか？

CO_E_FIRST -2147221008 0x800401F0 CoInitialize は呼び出されていません。

COMの初期化してないのかｗ

そうです。初期化してませんでした。i|||i
ついでですが、ヘルパー関数を使用せずに、使わないでいるＮＩＣのＭＡＣアドレスを取得するにはどしたらいいですか？

WinSockで取れなかったっけ？

netbiosじゃね？

NetBIOSでできるのは、実際にＩＰアドレスを取得してるとかのＮＩＣだけで
機能しないで刺さってるだけのＮＩＣは取得されません

http://msdn2.microsoft.com/en-us/library/aa394216.aspx
これは？

DirectXを使ってキャラクターをレンダリングしたいのですが、どこから手をつけていいのかわかりません。
作りたいのはゲームのキャラクターを１体表示してそのまわりをカメラでぐるぐる回るアプリケーションです。
基礎的な3Dの知識（透視変換とかｚバッファーとか）は勉強しましたが、
ボーンとかメッシュとかデータ構造（テクスチャーをどういう形で誰が保持するのか）がわかりません。
そこでキャラクターを１体表示する完全なサンプルとその解説が欲しいのですが、
どなたか手に入る場所を教えていただけないでしょうか？

>>732
よく分からんけど、Ｃ＋＋のコードから実行できる形オンリーで。

キャラクターよりまず、
三角ポリゴン1枚を描画して、それの周りをカメラが回るのは作れるのか？

それは作れました（OpenGLで）
サイコロ＋テクスチャーまでは作れました。

>>728
#pragma comment(lib, "Iphlpapi.lib")

>>733
DirectXのSDKのサンプルじゃだめなの？
メッシュ表示できるよね？

あれは何をやっているのかわかりません。

>>739
あのサンプル(DXUT部分は置いておいて）で何やってるか分からないと言われちゃうと・・・

http://twin-tail.jp/
ここの
http://luna.sumomo.ne.jp/
このライブラリをお勧めするよ
3DEX_00.exeあたりのサンプルで実現できるでしょう？

追加

メッシュなんてXファイル吐けるモデラ使えばすぐ作れるので（技量にもよるけど）キャラ表示させたいなら。まず、モデリングからじゃないかな
まあ、どうしてもプリミティブ使ってキャラを表現したいなら話しは別ですけど・・・

人体モデルのスケルトンを動かすには、色々な手法があって
１）CADでメッシュ作って、骨入れて、モーション入れて、Xファイルを出力する。Xファイルをアニメする。
２）プログラムでスケルトン作って、読み込んだメッシュをコントロールする。
他にも新しい技術が色々あるけど、最終目的に繋がる方法を選ぶことでしょう。

>>704
ここのライブラリって、他のスレでも、バグ持ちなんで使うなって言われてたけど。
どこだったかな？

>>716
よかったら、こっちも更新してあげてください

GamDevPukiWiki - ライブラリ
http://gamdev.org/w/?%5B%5B%A5%E9%A5%A4%A5%D6%A5%E9%A5%EA%5D%5D

D3DX使ってると、CPUごとの勝手な最適化のために、
環境によって、リプレイがずれる問題があるようなのですが、
この辺は、みなさんどう処理しておられますか？

参考URL

NyaRuRuの日記 - Deterministic Bullet Works - ■[DirectX]PSGPの無効化
http://d.hatena.ne.jp/NyaRuRu/20040819

CodeZine：DirectX Graphicsの隠し設定を利用した開発テクニック（API Hook, DirectX Graphics, D3DX, C）
サンプル3. DirectXランタイムのProcessor Specific Graphics Pipeline（PSGP）を無効化する
http://codezine.jp/a/article/aid/235.aspx?p=4

とびつきひめ＆まじあん けいじばん - ご意見ご感想スレ
http://www.01step.net/tobitsuki/bbs/test/read.php/tobi_bbs/1116256631/1-19

フレーム毎に各キャラクターの絶対座標をシリアライズ

解決策としては、

・D3DXの算術演算ライブラリをエンテティの実行処理に使わない
　つまり、D3DXの計算をリプレイの影響範囲には使わない
　算術周り自前処理？
・>>744にあるように、APIをHookして、PSGPを無効化
・レジストリ書き換えで、PSGP無効化('A`)
・面倒なので無視('A`)


サンプル3. DirectXランタイムのProcessor Specific Graphics Pipeline（PSGP）を無効化する
http://codezine.jp/a/article/aid/235.aspx?p=4
とりあえず、↑ページのサンプル3の実行結果を貼ってみる。

環境: Windows XP SP2 Pen4 2.66GHz
　　　　　　　　case 1 　　　　　　case 2 case 3
PSGP ON： 　0 　　 　　　　　　1.#INF 　1.#INF
PSGP OFF： 2.22045e-016 　1.#INF 　1.70141e+038

>>744
最初からズレない形式で保存しておく。

固定小数点

>>740-743
ありがとう。
とりあえずライブラリは使わない方向で考えてます。
あと表示するだけでないDirectXの本とかゲーム開発の本とか教えてください。
理想はゲーム１本まるごとソースが入っていて解説がある本がいいです。
値段はいくらでもいいです。

沖縄県の方へ（命に関わる注意事項です）

沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度　沖縄　三千万」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…

※一国二制度
　簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
　（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
　さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
　3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
　そして反日教育を受けた中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。

今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。

少しは自分で（ｒｙ

>>745
マジでそれやってるの？
それやってるの見たことないんだけど('A`)
つーか、座標以外の状態もシリアライズしないといけなくないですか？


リプレイって、キー入力とか、イベント処理を記録して再生するものだと思ってました。

>>747
kwsk

>>748
マジデ(ﾟДﾟ)

>それやってるの見たことないんだけど('A`)
まるで全てを知り尽くしたような言い方だな

>>749
SDKのサンプルが訳ワカメでライブラリも使いたくないって言う時点で
もう自力でどうにかするのも難儀だと思うんだが・・・

自力でやることにはそれほど意味はないぞ。
まずは完成させることに意味がある。

ゲームの作り方を教えてくれる所があるんだよね。費用が数十万円から数百万円だけどね。

>>754
「まずは」が重要だな
この副詞がないといろいろ曲解されてしまいそう

>>755
9割がゲーム製作に挫折する人である環境で、その悪影響が怖い。

遊ぶのは好きだが作るのは好きじゃなかった、それを教えてくれるんだよ。

ゲームやるのが好き＞途中で断念
ゲーム作るのが好き＞適当なフリーのライブラリを使って作る
プログラムが好き＞DirectXを叩くようになる。

>>754
Direct10のサンプルはいきなり WNDCLASSEX とか LPDIRECT3D9 とか出てきて初心者が一から勉強するにはつらいなと
この通り見ていけばDirectXが理解できる解説ないですか？
やる気だけはあります。
目標はUnrealEngineよりすごいものを３年後ぐらいに完成させたいです。

>>760
本買ったほうが良いかも。
WEB上にも解説してるところあるけど。内容が中途半端で更新が終わってたり
テクニックがDirectX7とか8とか古かったりするから

良書にめぐり合えばWEBを数時間巡回するより簡単に答えに行き着くよ

その良書を教えていただけますか？

>>760
良書っていうのは抱えてる問題やその人のスキルのレベルによって違ってくるから
自分で大きな書店に行ってパラパラめくってみるのが一番はやいと思うけど

例えばで良いなら最近のでは
「工学社のDirectX9実践プログラミング」
かな。あとは
「秀話システムのDirectX逆引き大全500の極意」
は、あれ？どうやるんだっけ？ってときに使います

ただし、何度も言うけど小説とかと違って技術書は個人個人、良書が違うと思うから
参考程度に聞いて下さいね。
自分で読んでみるのが一番良いと思います。参考書選ぶのと同じ感覚ですｗ

>>762
http://www.amazon.co.jp/dp/4797303522/

これ一冊で全てが学べる。後は全部ゴミ。

>>764
WNDCLASSEX とか LPDIRECT3D9 が出てくるのがつらいってヤツがその本読めるのか？
MSDNもDirectXのヘルプも読まないようなヤツが対象ってことだぜ

>>764
まて、それは、「ゲームプログラマになる本」に並ぶゴミぼ（ｒｙ

Amazon.co.jp： ゲームプログラマになる本: 本: 山崎 由喜憲
http://www.amazon.co.jp/gp/product/4789835642/

山崎式正弦跳躍法でぐぐれ

>>767
2chのスレしか出てこなくてワロス

ボケたのにつまんないマジレスが返ってきたときは
どうしたもんかと思ったよホント、助かった

みんな冷たいね (´・ω・`)
結局みんな俺流できちんと教わってないから
初心者に適切なアドバイスができないわけだ
日本のゲーム開発者のレベルが低いわけだ

そう煽る文を最後に載せるなよ鎖国ってるけどさ

日本には、3Dの基盤が無いからほとんど情報が無い。
洋書ではやたら多く出版されているので英語を読んだ方がいい
プログラム書のほとんどが、
ソースリストを付けるから勝手に理解してくれよのスタンスだ
Windowsの時代になってからは、APIに振り回されるくらいなら
ライブラリーに全部を任せてしまう方向にある。
現実にiAPX386の時代も終わろうとしているし

>>770
>みんな俺流で
右へ倣えがお好みで？

>きちんと教わってないから
誰か教えてくれるとでも？

>あれは何をやっているのかわかりません。
>理想はゲーム１本まるごとソースが入っていて解説がある本がいいです。
君にはゲー専がお似合いだよ
努力せず他人頼って何かを得ようとするやつにはゲー専がお似合いだ
金はかかるが入社に必要なゲームプログラムを丸ごと貰えるぞ

>値段はいくらでもいいです。
じゃあ大丈夫だな

今すぐ行け
早く行け
行け

２ｃｈでの回答が冷たいってのも鎖国ってるってのも一応同意しとく

>>770
お前痛いな
びっくりするほど昨日からみんな親切に対応してくれてるのに
サービスを無償で受けるのが当たり前の
ガキかにーと君だろうが
真面目に答えてくれてる人にありがとうの一言も言えないようじゃ
どこ行っても相手にされないよ

>>770
マジレスするとゲームプログラムって総合芸術みたいなもので、
3D・AI・サウンド・スクリプト・ネットワークetc いろんなものを抱えすぎてる。
これを見ればOKって本を作っても内容が薄くなって実用性がなくなるだけ。
地道に個々の分野を漁るしかないよ、みんなそうやってる。

まぁまぁ、一生ゲーム作れないタイプの人間の遺言なんだから、
生暖かく見送ってやれよ。
むしろ「日本のゲーム開発者のレベルが低い」には同意する。
初心者向けに綺麗に切り分けして動作確認までしたソースコードを、
ボランティアで用意しろと要求するとか、日本の教育制度の歪みだよ。

DirectX10

うは
煽られたら一斉にレス付くってｗ

>>770
自分が理解できないことを人のせいのように書くのはよくないよ

さっきも書いたけど。自分にあった本でも探してがんばりな。

>>770
とりあえず適当なライブラリ使ってやってみればいいだろう。
そこにはある種求めている答えがそのままあるんだから。

できるようになったらそのライブラリの中を見て具体的に理解すればいい。

まずはＥＬでも使って望みのものが作れるかやってみれ。

綺麗なモーションブラーのやり方教えてくれよー

カレイでなくともヒラメでいいだろう。

DirectX8あたりから始めた俺としても、正直>733の書き込み見て
「あぁ、今時のクールなやり方ってどうだろう？」とは思って静観はしても、
手持ちのソースコードを整理して出す気にはならなかったな。（解説付きで？ｗ
そもそもアニメーションがDirectXの範疇かどうかも知らんし、
自分でやるもんだと思ってる。いや、オールドタイプの愚痴書いてすまんねｗ

プログラムが好きな奴じゃないとどうせ続かないだろ
>733がしたいこと程度ならぐぐってれば調べられる程度のことだし

>>773
これはひどい。

本気にする奴いるから、書いとくけど、
ゲー専だけは絶対にやめとけ。

情報系の大学のコンピュータ系サークルにもぐりこむ方が、仲間も見つけられて、手っ取り早い。

両方いったことがあるのか

>>785
俺ゲー専だけど一応就職はできたｗ

まぁ、説明する為のコードと実際に使うコードは別物だから
丁寧に説明されるほどにそのコードは使えない。

スケルトンモデルについて他の人で知りたい人もいるだろから、
書いとく 研究用には使えると思う。
DirectX9 3Dゲームプログラミング〈vol.2〉C#によるキャラクタの歩行アルゴリズム

>>787
一般学生は就職できなかったことが最低の恥になる。
ゲー専生は就職できたことが最大の自慢になる。

>>789
わかる気がするｗ
大抵は実家に帰るとか全然ＰＧ関係ない職に付くとかだしな。

結局は本人のやる気次第だけどな。
まあ、そのやる気を削ぐ環境が
バッチリ揃っているのがゲー専なわけだが。

>>788
その本はオススメできない。
無駄にハードコーディングしてるし、同じようなコードをまとめずに
ダラダラとコピペしてあったりと、コードのできが悪すぎる。
あと、スキンメッシュも扱ってないし、他にも問題がありまくり。

普通にDirectX SDKのサンプルやMSDNの記事を読んだほうが良いと思う。

DirectX関連の本は大抵、説明をわかりやすくするために
わざとハードコーディングのサンプルを載せてるものが多いと思うんだが。
とかなんとか書いていたら>>788が1〜2行目で言ってるじゃないかorz

>>792みたいな奴がイチイチ状況を理解せずに文句を言うから、
アメリカのマニュアルみたいに最初に注意書きをいっぱい書いておけば良いんだよ。
生き物は乾燥させられません、説明用にコーディングしているため最適なコードではありませんと。

分かりやすくなっているのなら良いけど、>>788の本に限って言えば
特に分かりやすくなっていなかった。（だから「無駄に」って書いた）

その本とDirectX SDKのサンプルやMSDNの記事を両方を読んでみて
SDKのサンプルやMSDNの記事の方が分かりやすかったし、役にも立った。

そりゃSDKサンプルとかMSDNの方が分かりやすいとは思うけども、やっぱ本は必要だよ
画面小さいといちいち窓切り替えて見比べたりしづらくて、うがー、ってなる
あと暇なとき寝ながらでも読んでいられるし

WUXGA+UXGAの環境だと
窓を切り替えたり画面小さくしたり
することに逆に憧れる

環境は人それぞれ


ゲーム作って実感しましたorz

エグゼクートバッハー復活希望。

外人のコミュニティで言って来い

スキンメッシュのフレーム情報の管理に関して質問でつ。
ボーンとか仕込むとメッシュが階層構造持つことになるけど、
それぞれのフレームが持つ情報へアクセスする方法はどうやるのが一般的？

自分はいま全フレームへのポインタを一次元配列で確保しといて、
そのポインタを通じてフレーム内情報の読み書きをしてるんだけど。。。
階層構造とか再帰とかあんまり経験無いからどうすればいいのか……。

一番簡単な実装方法は再帰でツリーをたどる関数を作る
オーバーヘッドが気になるならば
ロード時にフルパス名を作ってそれをキーにしてマップに登録

好みの問題じゃないか？

基本は１つの頂点バッファで管理。
派生クラスでは体のパーツ（ボーン？)毎に、
頂点バッファ上での範囲を管理していて、
体の中心から変換マトリックスを更新しつつ、
範囲ごとに表示。

ローポリでいくつもりなので、
俺の場合はこんなもん。

DirectX 9.0cでアプリケーションを作ってるのですが
普通に動かすと40FPSぐらいですが
Windows Media Player11を起動させておくと
60FPSに跳ね上がります。なんで？？

普通に動かして40fpsってどんなスペックやねん

>>804
タイマーの分解能の設定は？

>>806
timeGetTime()で設定とかはとくにしてないですが
40FPSだと見た目でガタガタになるのがわかるので
おおよその値はあってると思います。

>>807
いや・・・・・・・・そうではなくて
設定してないなら設定しろと言っていると思われます

>>806、808
はうあ！　MediaPlayerを立ち上げなくても速くなりました！
MediaPlayerが共通のタイマーの設定をしてたということでしょうか。
ふしぎふしぎ。ありがとうございました。

ふしぎーのもーりーはー

メディアプレーヤーを起動してると速くなる系の質問はかなり頻出

某掲示板で検索してもわんさか出てきた
ttp://bbx.hp.infoseek.co.jp/cgi-bin/bbx.cgi?log=49&vew=100

様はtime＊＊系の設定はシステムグローバルだってことね

>>804
もう解決したが、
timeBeginPeriod(1)
timeEndPeriod(1);
だな

これ、Win98から、Win2000に移ったころハマったよ。懐かしい（昔話）

自分の環境では、サイズを自由にしてテクスチャを生成できるのですが
そういう環境でも、テクスチャサイズを２のべき乗にした方が
スピードアップできるのでしょうか？

何故実験環境があるのに、自分で測定しようとしない？

今は、指定数値のままの自由サイズでテクスチャを作成できるように
してるだけで、それを２のべき乗に拡大して（余剰分は透明色にする）
生成するルーチンの実装はまだやってないのです。
２のべき乗にした方が速くなると分かれば、そのように実装しますが
そうでないなら無駄な労力を使いたくないという事です。

じゃぁ、お前の環境とやらを住人全員に配布しないとだめだな。

>>817
>>816は別に配布するんじゃなくて自分専用の何かを作るってるんでないの

2の整数乗でないサイズのテクスチャに対応したハードなんて
持ってる人どんだけいるんかね

２のべき乗の方が速い。

おお。サンクスです。
自分のＰＣのグラはオンボードなので、現代じゃ一般的だと思ったのですが
そうじゃないのですかorz

速い遅いというのが何を指しているかによるが
Directt3Dサーフェイスには幅の他にピッチという概念があるので
テクスチャ作成に関わる部分では、サイズがいくつだろうが変わらないと思う。
フィルタリング(ミップマップ)は2^nサイズだと、最適化ルーチンが使えるので
そっちの方が速そうだ。
テクスチャサンプリングはGPUのリッチさによりけりだな。

自分で試すまでどっちが早いかなんて分からない。

＞速い遅いというのが何を指しているかによるが

テクスチャの表示です

>>804-813
自分も同じことにはまってました。
なぜか特定のマシンだけ極端にFPSが上がらなくて、VirtualPCを立ち上げると
FPSが高くなってました。

timeBeginPeriod、timeEndPeriodはアプリケーションの開始と終了に書いてましたが、
それを変更したら直りました。
どうもありがとう。

>>816
テクスチャの内容なんて影響ないと思うから重要なのはテクスチャのサイズだけじゃないの？
サイズが２のべき乗かそうでないかの違いしかないんじゃない？
だから現状指定数値で実行できるなら

わざと２のべき乗のサイズにしたテクスチャの場合
と
２のべき乗のサイズでないテクスチャの場合
と
で速度を測ってみればいいじゃない
とりあえず表示はちゃんとしてなくても速度だけ測れればいいんでしょ？
ならこれで測れば問題ないんじゃない？

ただ、上の人も言ってるけど何が影響するのか要素が多すぎて
やってみてナンボってところあると思うよ
ミップマップとか、バイリニアフィルターとか、ＵＶのアドレッシングモード、
１フレームでテクスチャ切り替えを頻繁に行ったとき、
１フレームでテクスチャ切り替えを頻繁に行わなかったとき
とかなんかちょっとした条件の変化で速度変わるかもわからんしね
テスト画面作ってるときは影響なかったけどゲーム作ってみたらモリモリ重くなったとかありがち。

ちなみに俺の環境ではたいして違いは無かった

>>818
GF6600以降のグラボは全部自由サイズのテクスチャに対応してる。
ただし範囲外サンプリングはCLAMPに限定され、
ピクセルシェーダー命令が一部使えないけどな。

>>826
GF6600は含まれてますか？

GFは、か・・・

これがゆとりか。

>>826
制限があるのはNONPOW2CONDITIONAL
これはGF6600どころか、もっと前から使える。
というのも、この機能の制限をよく考えれば分かるが、POW2テクスチャの
一部を使えば実装できるようになっているので、ドライバが対応すれば
どんなチップでも対応できる。

GeForceは6シリーズから、真のNon-Pow2テクスチャに対応したから
細かい制限は無いよ。（仕様上テクスチャ圧縮は使えないが）

TextureCaps の D3DPTEXTURECAPS_POW2 と D3DPTEXTURECAPS_NONPOW2CONDITIONAL は
(Yes, No)、(Yes, Yes)、(No, No) の3パターンがあるから注意しないとね。

dxinfoで調べた限りでは、無条件の (No, No) なのはNVIDIAのGeForce6シリーズ以降だけで、
ATIは最新のRADEON X1000シリーズでもいまだに条件付きnon-pow2しか使えないみたい。
http://www.netsphere.jp/dxinfo/

自分で3Dエンジン組めば分かるけどpow2のテクスチャはビット演算だけでrepeatとか可能で非常に便利。

俺はゲームで使うテクスチャは3D絵はpow2、2D絵は自由サイズにCAMP限定でエンジン組んでる。
non-pow2対応してない場合はpow2のテクスチャに拡大転送してUVは内部で自動再計算。

GetIndicesについてなのですが、英語版MSDNでは引数が二つで、日本語版では一つです。

英語版MSDN
ttp://msdn2.microsoft.com/en-us/library/bb174391.aspx
日本語版MSDN
ttp://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/directx9_c/directx/graphics/reference/d3d/interfaces/idirect3ddevice9/getindices.asp

D3D8からD3D9に書き換える上でこの問題にぶつかりました。
D3D8では英語版のものと同じで引数が二つです。

二つ目の引数を取得したいのですが、GetIndicesで取得する方法、もしくは他の関数がありますか？
よろしくお願いします。

ヘルプが間違っているんだから、ヘッダを確認するのがプログラマの常識。

ヘルプが間違っているのですか…。ということは英語版のMSDNも。
ヘッダの確認もしたのですが、なにぶんあまり知識がないものでよくわからなかったのです。
なのでこちらで質問させていただきました。

BaseVertexIndexの取得についてですが、自己解決しました。
この引数を検索したら、DrawIndexedPrimitiveで使ってますね。

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

２のべき乗にしたがるのはswizzlingを一発で通したいからなんじゃないの

RTSみたいなゲームを作ってる者なのですが
描画速度が思うように速くならずに、非常に困っております。

画面サイズは800×600で、フィールドは32×32の板ポリゴンをタイル状に敷き詰めてます。
その上で動くユニットと小物オブジェクトも全て板ポリゴン（一部ビルボード）です。
それを１フレームごとに
Clear
フィールド描画　＝　SetTexture()→DrawPrimitiveUp()を各タイルごとに約500回
ユニット＆オブジェ描画　＝　Vertex配列に座標数値を代入して
　　　　　　　　　　　　　　SetTexture()→DrawPrimitiveUp()を平均500回（500ｵﾌﾞｼﾞｪ分）
Present
と描画してるのですが、当方の環境はP4 1.8GHzでオンボードのグラボですが
せいぜい２８FPSまでしか出せません（ポーズ中の描画Onlyのみで）。

たかだか１０００個の板ポリゴンを描画するだけでFPS30もいかないものなんでしょうか？
これで本来の内部処理を加えると、20FPSが限界になってしまいます。
１フレームごとに
頂点配列に数値代入（フィールドタイル以外）→SetTexture()→DrawPrimitiveUp()
を板ポリの数だけ繰り返すやり方では駄目なのでしょうか？

Direct3Dはテクスチャの切り替えとDraw系関数のコールがびっくりするくらい遅いので、
板ポリゴンはなるべくひとつの頂点配列に溜め込み、
テクスチャはなるべく一枚のテクスチャに詰め込み座標ずらしで対処して、
Draw系関数のコールとテクスチャの切り替えを少なくすればそれなりに改善されると思うよ。
まぁ1000回程度ではそこまでガタ落ちしないから、他にも問題抱えてそうだけど・・・。

パフォーマンスまわりの話は文面だけだと話しが拗れがちだから、
こーゆーとこで質問するよりプロファイラの読み方覚えた方が良いかと。

２ｃｈでDirect3Dのパフォーマンス絡みの話題となると、
ステートの変更を減らせとかDraw系関数の呼出回数を減らせとか、
結局そんな一般的なことしかなかなか書けないんだよね

プロファイラの読み方というかプロファイリングについての基本的なことなら、
とりあえずここを最後まで読んでみることをすすめてみる。

http://msdn2.microsoft.com/en-us/library/bb172234.aspx

長いけど、中でやってることは単純

グラボの名前とテクスチャの解像度も書こうぜ
トライアングルセットアップがボトルネックとは限らん

IDirect3DDevice9::CreateOffscreenPlainSurfaceで作った
サーフェイスにレンダリングすることってできますか？

no you can do it

>>842
僕の質問に対する回答でしょうか？

no i did

英語の "Yes/No" は、日本語の「はい／いいえ」と
厳密に対応してはおりません。

842と844は
"All your base are belong to us"
レベルの英語もどきですね。

no this engrish is yours

>>845
842も844もネタだろ？
そのまま「はい」「いいえ」に置き換えたとしても
質問文の内容から考えて意味が通ってないしｗ

>>841
できません。

>>841
できないし、そんなことをするような状況が存在しないだろう。

>>849
GPU使った汎用演算で使いたいのかも。
まあ、その場合でも普通のテクスチャ使うか。。。

>>848,849,850
ありがとうございました

>>838
>>839
どうもありがとうございました。

>>838-839
>>837の問題に対してまとめたところで意味あるのか？と聞きたい
例えばこの処置で速度が２〜３倍になったとしてもそれでも60FPS多分届かないぐらいなんだぜ
チップを敷き詰めるならロード時にチップ敷き詰めたデカイテクスチャを作ることだってできると思うんだが
こういうゲームではどうなんだろうか？
まあ、ゲームのマップ全体を作れとは言わんがある程度のまとまりで逐次ロードしつつ作れれば
描画時のポリ数に悩まされることはないんじゃないだろうか？

少なくとも俺はDrawPrimitiveにポリゴンをまとめて突っ込むなんてのはなんの解決策にもなってないと思うんだけど？
だってDrawPrimitiveって普通に何回も呼ぶぜｗ
呼ばなきゃゲーム作れねぇじゃんｗ
エフェクトによって２度描き３度描きよくやるぜｗ
やっぱさ、このまとめる形の最適化ってなんかおかしいと思えってｗ

そうえいば、DirectX10でDrawPrimitiveのボトルネックが無くなるとか
噂を聞いたがどうなったんだ・・・・？

>>853
いやー、結構効果あると思う。以前おれも同じ状況になったし。
その時はスプライト？(ポリゴンx2の四角形、画面上で32x32ピクセルくらい)
一枚一枚でDraw〜()呼んでたら数百枚で60fps割った。

でもテクスチャが同じスプライトをまとめて、Draw〜()の回数減らしたら
30000枚くらい描画しても60fpsをキープできるようになった。

なんか思い出してきた。

たしかその時は同じ頂点バッファを使いまわしてたんだ。（＝頂点４つを数百回反復使用。。。）
1フレーム間に同じバッファで何回もLock → Drawを繰り返したのが悪かった気がする。
だからDraw〜()の回数もあると思うけどバッファのLockにも注意すべきかと。

>>853
おたくのゲームの作り方に関係なく「DrawPrimitive」には
相当のCPU負荷が存在するのは現実世界での事実だ。

だからあの手この手でDrawPrimitiveを減らすための努力や
システムを組むのに時間をかけるんだろう。

そのためだけにわざわざMSが専用APIが実装したり、
GPU Gemsにそれを扱った章が掲載されたりしている。

DirectX10では改善されているが、DirectX9まではそこがボトルネック
なのだからそこをいかに減らすのかもプログラマの腕の１つ。

fbxやtga等のファイルを作成する開発環境でフリーで良いのありませんか？

>>857
いや、重いのはわったけどさ
劇的に早くはなんねーってことよ。

なんつーの？DrawPrimitiveにまとめて突っ込むとかやりだすようになったら
手法を根本的に変える必要があるときだと思うのよ（まあ、例として>>853つーことで）

例えば、ソートをバブルソートが遅いからってクイックソートに変えて解決する問題って少ないと思うんだよね。
そりゃオーダーが全然違うし、クイックソートの方がはるかにはえーよ。それはわかる。
でも、実用的じゃないでしょ？
そういう話よ。

ゲームに限らずよ、ただ目先の数値につられてホイホイ最適化しちゃうのってまずいと思うぜ。
もう、これやるっきゃねーよ。って状況が意外と少ないと思うのよね。

>>858
http://goldenstudios.or.id/products/GTGE/

でだ、そうはいってもまとめなきゃ動かんようなものもある
弾幕ＳＴＧの弾とかやるっきゃないね
ただ、こういうのは俺の中ではええねんｗ

だってこんなのもともと普通じゃできねぇような量を描画しようとしてるじゃん
しかも、普通だったら全部カメラに入るなんてまずないのに２Ｄであるために全部描画しなくちゃいけないとか特殊事情
だからこれはどうでもええねん。
できないような量を無理やり動かすんだから大いに最適化してくれって感じじゃん。
魂までもすり減らせって感じだ。

ただ、マップなんかは普通じゃん。

俺がいうところの何を普通っていって何が異常かってのがわからん？
これはオブジェクト単位で普通とかどうとか言ってると思うｗ

パーティクルやらちょっとまとまった単位でのもんってのは他のやり方があると思うんだよね。
もう、パーティクルなんてやめてアニメーションテクスチャにとっかえちゃうとか、
マップチップも３Ｄ空間にもってきたら下地じゃん。これもやりようがあると思うんだよね。
ただ、弾幕ＳＴＧの弾は弾１つでオブジェクトなんでやりようがないと思うんだよね。
この場合は妙ちくりんなワザ使って最適化する必要があると思うんだよね。
って感じ。

だからやらなきゃいけんところはやらなきゃいけんと思うんだけど
そういうところって少ないと思うんだよね。
ああ、で、やっちゃいけないところをやっちゃうと
今度は身動きとれなくなっちゃうって感じなので（やってることが最適化なので当然だが）あんまりこの
DrawPrimitiveにまとめて突っ込む手法ってのはやる前に別のやり方がないかちょっと考えたほうがいいと思うんだよね。

凄いぞ。書けば書くほど論旨がぼやけていく。

噛めば噛むほど旨みが出てくるのなんてするめくらいだろ

大抵のものは噛めば噛むほど不味くなる。
それと同じ

またこの話題か
CPUがネックになってるかGPUがネックになってるかでどっちがいいのかなんて変わるだろ

バッチの話題になると妙に血気盛んに意味無い論語り出すアホがいるよな

そんなもんケースバイケースだ、で終わるのに

>>865
>ケースバイケース
それだってある程度法則があると思うんだけど
まあ、こんなDrawPrimitiveに全部突っ込むなんてのは稀だよ

まぁ、少なくともこのケースはDrawPrimitiveが原因だと思うが・・・。

ケースバイケースでもあるし程度の問題でもある。
何も画面描画を1回のDPで行えなんて無茶は誰も言ってないだろ。

描画数が多くてある程度まとめられるものをまとめようぜ、って話だろ。
背景のマップチップや弾幕STGの弾みたいなものはソートがそれほど重要でもなく
数だけはべらぼうに必要な場合が多いからそういうものはまとめる。

フォント描画のときだって1文字ずつDP呼び出すなんてまずしないだろ。
最近のD3DXFontですらキャッシュするように改良されてるんだから。

GPUがネックの場合はまとめようがまとめまいが処理落ち確定だから意味ないけどな。
GPUがネックなら基本的に数を減らすしかねぇ。

>>867
解決策のアプローチの話なんだが・・・

>>868
>数だけはべらぼうに必要な場合が多いからそういうものはまとめる
こうかくと１フレームのこういうモデルの描画すべてをまとめようとする奴がいる
あくまでオブジェクト単位でまとめるだけって書いておきたいｗ

>>868
日本語読解力の欠けた俺に
ケースバイケースと程度問題の違いを教えてくれ

なんて不毛な論争なんだろうか

通訳しよう。

「他人の話はどうでもいい、俺様の話を聞け」

>>871
横から突っ込むけど明らかに違うだろ、日本語的にも

アイデンティティの問題ってのもあるから難しいよね。

身の程に合わないほど自意識を肥大化させたオッサンって、
現実では、　実際の待遇＞＞＞自己評価　　という状況に必ず直面する。
そうなると、普段抑圧している分、こういう場で
必要以上に自尊心を満たそうとし始める。

メンツに固執し、自分がトップに立つ形で決着がつかないと暴れ始める。
自分が一番でないとアイデンティティが崩壊するから、妥協できない。
相手の意見を認める、見解の違い・表現の違いを容認する柔軟性がなくなる。
そしてネットでも加齢臭をまき散らし、嫌われる。

「匿名の状況下では君の自尊心は何の意味も持たない」
という単純な現実を受け入れてくれればよいのだが。

このタイミングでそのレスはさすがになにがいいたいのかわからない

実際の待遇＞＞＞自己評価　なら文句ないぜ

あーもー、この流れが嫌だからわざわざ予防線張ってアドバイス書いたのに・・・。
相変わらずID:LW0FYzwBは意味不明だな。

>>853
＞描画時のポリ数に悩まされることはないんじゃないだろうか？
>>837は少ないポリ数なのに遅くて困ってると書いてるのに
どうしてポリ数削減の最適化をお勧めしてるんだろうか。人の話を全然聞いてない。
仮に>>837が>>853の方法を適用したら、結果としてDPコールも減るから
問題の切り分けができないまま状態が改善してしまうかもしれないよ？

最適化の一般論を語るその口で出てくる具体的なアドバイスが
「目先の数値につられてホイホイ最適化」そのものってのが涙を誘う。
毎回思うんだが、あんた本当に2Dゲーム作ったことないだろ？

no i have never and will never do any of them

>>877
でも、DrawPrimitiveにまとめて突っ込むだけじゃここまでの速度はでないよね？
また、それで解決するかも怪しいよね？
>>853の方法なら確実でしょ。
その件に関しては文句あるの？

>>879
そのやりかたの場合システムが複雑になる。
別スレッドでリアルタイムに状況判断して新しいテクスチャ作らないといか。
間に合わない場合なども想定して組まなければならないわけだしな。

あと使うかどうかは別として高速スクロールが出来ない。

ポリゴン数には悩まされなくてすむがテクスチャメモリや
テクセルレートに関しての悩みがあることを忘れてもいかん。

だからケースバイケースだというわけで。

>>880
>あと使うかどうかは別として高速スクロールが出来ない
いや、できると思うけど俺は

どんな精度の絵を描こうとしてるんだ？？？

>>881
やったとこないけどできると思うとか
んな推測をもとに今までグダグダ言ってたのか？

STGスレで「DirectXはスクリーン限定でラスタースクロール可能」等と
胡散臭い主張して突っ込まれてフェードアウトしたロートルがいたが
お前はとてもよく似ている

s/スクリーン/フルスクリーン/


で、質問者>>837の数値を参考にして
例えば800*600フルカラーのゲーム画面で
フィールド一画面分（27x18のマップチップ）を描くとして
例えば以下の２つの手法を検討したとする

　�@テクスチャにSetRenderTargetでスクロール分差分更新
　�A30*20のメッシュのUVをスクロール分だけ差分更新

口先だけでないならこの両者のパフォーマンスを速やかに比較して
速やかに結論が出せるはずだ

前者について補足すると、これはおそらくお前がやろうとしてる
画面と同じかそれよりも大きいサイズのテクスチャにフィールドを
描いて、それをフレームバッファに転送とかいう方法

後者について補足すると、これはおまえが嫌っている
一画面分のマップチップをマテリアル単位でまとめて
DrawPrimitiveする方法だ。比較の便宜上差分更新としてるが
予めフィールド全域分を用意しても構わない。

>>883
君、そうやっていつも掲示板で見えない敵と戦ってるの？ｗ

いきなり高速スクロールを適用ことを前提にしてるけど
ＣＤなりＤＶＤなりＨＤＤの容量が許す限りどこまでもいくんだから
環境の制限でもしない限りなんでもできるだろｗ

スクロールなんて貧乏臭いことしなくても、
市販のゲームのアリガチ演出みたいに背景にムービー流してもいいぜｗ

別にロード時にテクスチャこさえなくてもすでにこさえたもん保存しておいてもいいわけだし
また、別にスクロールするときにテクスチャを生成しなくちゃいけないなんてのはお前だけの妄想だ
別にあらかじめすべての絵を完成させた状態でもいい

それとこの条件だとお前に振りだぜ、俺は別にチップにこだわらなくていいって考えだし
でかいテクスチャをチップ的な使い方もできるから要はお前のやり方も俺のやり方の中に含まれてしまっている

それと30*20のメッシュとか条件ついてるけど
俺の方法なら４頂点の２ポリでもいいしｗ
この場合のパフォーマンスは最速だ。
もっと変化がほしけりゃ好きにサイズを変えたらいいし、その場合ゲームによりけりになってしまうな。

要はチップってのがどういう性質のもんかってことだよね？ちがう？
昔はメモリが少なかったからできるだけ使いまわしていい絵を完成させようってのが
あったけど今は容量はアフォみたいに増えちゃったけど処理速度はそれにおっつくぐらい
上がってないって状況じゃないの？

こんな時間に質問です。

今、"Special Effects Game Programming with DirectX"って本を読んでいるんですが
添付されているCDのDirectXはVersion 8.1です。
ネットで検索すると最新はVersion 9.0cらしいですね。

皆さんならどちらをインストールしますか？
(それらの違いをよくご存知の方が答えてくださると光栄です。)

>>888
マップチップでやるっつーのは質問者の意向だろう
その前提を覆すなら初めからそういっときなよ
苦しくなったからって今更一枚絵でーとか逃げんな

お前の主張

一枚絵でやってもいんじゃね。ローカルメモリに全部読み込むと楽でいいよ

で片付く話。長文でぐだぐだ書かなくていいよ

>>888
お前まさかマップチップの利点がVRAMの節約だけだと思ってんのか？

すくなくとも画面いっぱいにチップ描画をする程度なら素直にバッファまとめてDPすりゃいい。
1024ｘ768程度の画面を32ｘ32のチップで埋め尽くしても余裕で60FPS出る程度の速度にゃなる。

元のチップを1枚のテクスチャにまとめるというデータ的な最適化は必要だがな。

背景に動画だとかユーザーの入力に反応してスクロールするときとか、
地形が変化するときどうするつもりだよ。
そもそも画質が劣化するしチップごとにアトリビュート持たせるために別のエディター用意すんのか？

>背景に動画だとかユーザーの入力に反応してスクロールするときとか、地形が変化するとき
質問者はそこまで想定してんの？

＞DrawPrimitive
結局、頻繁に呼ぶと遅く、まとめて呼ぶと早いのなら、
APIそのまま使わず、
ラッパー一段かませれば済む話でもないのかな？
まあ、構造同じにならないから、同じようには組めないだろうけど

あと、試すのもいいけど、他の3DライブラリでDirect3Dの扱いどうなっているかも見た方がよさげですね。

普段OpenGL使ってて、DirectX使うおうか悩んでて覗いている者なので適当に流してくれていいけど。

>>892
え、RTSってそういう処理が必要な筆頭じゃないの？

>>893
まあそのラッパー内部をどう実装するかの話でもあるわけで。
GL実装のシーングラフでも、ステート変更削減を優先としたソートと
遮蔽カリングを優先としたソートみたいなのがあるじゃん。
あれに「DPコール数」が加わる感じ（実際にはステート変更削減にほぼ含有されるけど）。

>>891
>背景に動画だとかユーザーの入力に反応してスクロールするときとか、地形が変化するとき
これでも問題ないぜ
動画はユーザーの入力に反応させて再生時間を進めてやればいいぜ
地形が変化するときは変化するときするところだけポリ数が多いもん使えばいいぜ

>>894
いや発端の837にそこまで書いてなかったからさ
どの程度までやろうとしてるのかは質問者じゃないとわかんないでしょ
やりもしないことに対してアドバイスしてもと思って

>>895
おまいさんは地形が変化する場合の全パターンを動画でつくるのか？

あと地形に高低差があって前後関係からソートが必要なときどうすんだ・・・
対応するZバッファも動画に作っておくのか？

>地形が変化するときは変化するときするところだけポリ数が多いもん使えばいいぜ
2Dのマップチップの話でポリ数？

>>897
地形の話と動画の話は別でなｗ（別にやってもかまわんけどｗ）
なんでくっついたんだ？ｗ

>対応するZバッファも動画に作っておくのか？
そういうライブラリあったなぁ・・・自分で作りゃいいけどｗ

>2Dのマップチップの話でポリ数？
そうそう、マップチップてのも所詮格子状のメッシュを表示してるに過ぎない
だから変形させるときだけ変形させたいメッシュに挿げ替えてもいいわけ
地形が変形するのはこれで対応できる

>>889
>出版社: Premier; Pap/Cdr版 (2001/12/1)
古！もっと新しい本読んだほうがいい。
グラフィックス技術に関する本は進歩が早い。3年も経つと役に立たないとおも。

DirectX8 → 過去の遺産
DirectX9 → 現役
DirectX10 →　？

DirectX9の最新を入れるのが望ましいけど、
初めての場合は日本語マニュアルのあるバージョン入れればいいんじゃナイン？
（今見た感じではOctober 2004か？これも結構古いね。。。）

確かに古いグラフィックス技術は役に立たなくなるな
業務系はMDXからWPFに変わるだろうし、
ゲームはMDXからXNAに変わるからな。
基本的にDirectXをラッピングしただけなんだけどね。

C++をそんなに切り捨てたいのかな