09/08/01 19:25:30
>>625
>頂点バッファに全ビルボードの移動後の頂点を入れておくとかですか？
それでOK。
頂点バッファを毎フレーム「作り直す」のはつらいので、500ビルボード分作る。
MSのヘルプによると、一回のDrawPrimitiveでは1000ポリくらいが適切だということなので、ビルボは三角形二つだから500ビルボード分ね。
ミサイルの煙を半透明でやるのね。OK。
「気にすんな」でOK
とりあえず試してみ。前後関係が狂っててもまったく気にならないから。
「気にならない」正確さより、「気になる」処理落ちを防ぐのを優先。
>煙１と煙２が重なった場合板ポリの輪郭が見えてしまいます。
半透明の物体を描くときは、Zバッファへの書き込みをOFFにするべき。
そうすればこの現象は起きないよ
628:デフォルトの名無しさん
09/08/01 19:28:30
>頂点バッファを毎フレーム「作り直す」のはつらいので、500ビルボード分作る。
500ビルボード分の大きさで作る。のほうがわかりやすかったね。補足。
描画するたびに中身を書き換えて使うべし。
ロックする際D3DLOCK_DISCARDを指定すれば、ロック待ちも発生しないので早いぞ。
629:デフォルトの名無しさん
09/08/01 19:33:42
>>626
毎フレーム書き換えるのは頂点バッファをLock,UnLockして書き換えるより
頂点シェーダでやったほうが高速だと思ってたので、すべて頂点シェーダでやっています。
それはスキンメッシュのスキニングをシェーダでやったほうが
何倍も高速だったのでそう思っています。
DrawIndexedPrimitiveを何回も呼ぶより
バッファ作ってLockして書き換えたほうが速いということですか？
上のほうで言ってたことは
結局はDrawIndexedPrimitiveもUPも大して速度は変わらないという結論ですよね。
630:デフォルトの名無しさん
09/08/01 19:43:28
>DrawIndexedPrimitiveを何回も呼ぶより
>バッファ作ってLockして書き換えたほうが速いということですか？
書き換えたほうが速い。
というのも、DrawIndexedPrimitiveの呼び出しオーバーヘッドは遅いので。
頂点シェーダでやると高速化するのは確かにそうだが、やるなら281法をやることになる。
確かにID3DXEffect::SetVectorArray()で座標情報を渡すのが大抵のグラボで最速。
ただ、定数レジスタの数の制限を考えるに1回につき250ビルボ程度しか描画できない。
あとは場合によりベターな方法は変わる。
まとめて描画する単位が250ビルボ以下ならこちらでいいと思われ。
631:デフォルトの名無しさん
09/08/01 19:50:21
固定的な頂点バッファとは別に、毎フレーム書き換わるデータ向けの動的頂点バッファがあるの。
その違いを分かってないから、スキンメッシュとの比較検証も、効率悪いやり方でやった場合の結果にすぎない。
632:デフォルトの名無しさん
09/08/01 19:59:06
>>630
複数の頂点情報ストリームを登録しておいて、片側を毎回書き換えるという方法が考えられるな。
（で、VertexShaderで合算する）
計算がいくらか楽になるかもしれない。どれくらい速度が変わるかは試してみないと分からないけど。
633:デフォルトの名無しさん
09/08/01 20:02:57
とりあえず、281法含めて色々実測した身としては、
UPだろうがUPじゃなかろうが、頂点シェーダを使う方法だろうが
「沢山のビルボードを、まとめて一回のDrawIndexedPrimitive*で描画する」という基本を守っている限り、
速度誤差は0.1%にも満たないということだ。
小難しいことを考えるが面倒なら、DrawIndexedPrimitiveUP使っておくといいよ。
（レガシー関数だから嫌というこだわりがなければ。ね）
本気で速度の差はほっっっっっとんどでないから。
まぁ、流石マイクロソフト。DrawIndexedPrimitiveUPの中身もちゃんと最適化されてるんだなといったところ。
634:デフォルトの名無しさん
09/08/01 20:11:38
>>627
>一回のDrawPrimitiveでは1000ポリくらいが適切
それは知りませんでした。
>半透明の物体を描くときは、Zバッファへの書き込みをOFFにするべき。
>そうすればこの現象は起きないよ
そうですよね、なるほど！
>>630
>書き換えたほうが速い。
>というのも、DrawIndexedPrimitiveの呼び出しオーバーヘッドは遅いので。
そうなのですか。
>>631
Lockして書き込む際のD3DLOCKの種類のことですよね？
ここはよくわかっていませんでした。
D3DLOCK_NOSYSLOCKを指定していました。
Lockの際に、D3DLOCK_DISCARDを指定すれば動的頂点バッファになるということですね。
CreateVertexBufferの第二引数はD3DUSAGE_WRITEONLYでOKですか？
いろいろやり方が見えてきたので早速試してみたいと思います。
ありがとうございました。
635:デフォルトの名無しさん
09/08/01 20:55:13
WRITEONLYが適切。
だけどこのスレで「間違えて読み込みしてて、性能だだ落ちしてた」ってのが実例としてあったから気をつけるこった。
636:デフォルトの名無しさん
09/08/01 21:10:38
質問です。
2D描画時のテクスチャー矩形転送のお約束として、
転送先座標を-0.5ｆするというのがありますよね。
あれの意義はわかりますし、そうやっているので普段は良いのですが、
拡大転送する際「テクスチャーの参照の際、隣のドットの色が影響してしまう」現象が起きるようです。
これを回避する方法はないでしょうか？
LINEARを使わず、NEARPOINTでやればいいのでしょうが、拡大の粗が見えてしまいますので・・・。
637:デフォルトの名無しさん
09/08/01 21:19:08
一枚のテクスチャの中で別パーツと混ざるのが嫌なケース？
そりゃ周囲には1ピクセルずつ余白を置くとかじゃね。
昔の2Dゲームのような32x32のチップをぎっしり敷き詰められたデータなら、諦めるか、34x34で置き直すとか。
638:デフォルトの名無しさん
09/08/01 21:36:52
はい、そのケースです。
やっぱり余白しかないですか･･･。
縮小ならわかるのですが、拡大でも周りを参照しちゃうのがちょっと納得いかないところなんですが・・・
639:デフォルトの名無しさん
09/08/01 21:39:12
状況が許すなら、まず拡大しないブリットでチップを
レンダーターゲットのテクスチャに敷き詰めて
そのテクスチャを拡大するって手はある
640:デフォルトの名無しさん
09/08/01 21:46:51
>転送先座標を-0.5ｆするというのがありますよね。
そのやり方は正しいと思えないんだが。
むしろUVを半ピクセルずらすのが正しいやり方だろ？
UVをそのままで表示座標を変えてごまかしたりするから、表示倍率を変えると狂っちゃうわけで。
UVマッピングの詳細はMSDNにちゃんと書いてあるので確認すること。
ちゃんとやったらチップを画面いっぱいに並べようが拡大しようが、ずれたりすることはないよ。
現に手元で動いてる。
641:デフォルトの名無しさん
09/08/01 22:03:18
>>640
0.5ずらすのは
「バイリニアフィルタを適用している時に」
「頂点座標をスクリーン座標に直接マッピングすると」
ピクセルがテクセルの中心にマッピングしてしまい、拡大してなくてもぼやけてしまうのを防ぐためでしょ。
だから表示倍率を変えると云々はそもそも文脈としておかしいんだが。
642:641
09/08/01 22:06:18
うん、俺の文もおかしい。
x テクセルの中心
o 4テクセルの中心
643:デフォルトの名無しさん
09/08/01 22:16:46
>>641-642
オレの言ってることと君の言ってることはほとんど同じような気がするんだが、どうだろうか。
当倍表示の場合は636でも640でもいいが、拡大表示したら636ではおかしくなる。
そういうことだろ？
というか、そんな細かい処理をするときはフィルタはNoneにしたほうがいいと思うんだが。
拡大・縮小はきたなくなるけどな！
644:デフォルトの名無しさん
09/08/01 22:20:30
>>640
一応
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
これには目を通しています
これでも、ほかのサイトでも、転送先座標を + xy(-0.5f, -0.5f) するように思えます
640さんの方法は、拡大しても隣の色を巻き込んだりしないのでしょうか？
一応「座標はそのままに、UVを半ピクセルプラスする」方法でもやってみましたが、やはり拡大時には隣の色を巻き込んでしまうようです。
645:641
09/08/01 22:29:42
>>643
拡大するとおかしくなるんじゃなくて隣の色を拾うんだから
アルゴリズム上は正確な挙動だよ。
てゆーか言ってるのはテクスチャ座標を0.5テクセル分ずらす方法だよね？
言い忘れてたけど、その方法だと拡大はせずに反転した時に
完全なミラーにならずに一ピクセル分表示がずれちゃうよ。
そっち方法で隣の色を巻き込まないってのは、うーん、
手元で試せないので「そんな馬鹿な」としか言いようが・・・
646:デフォルトの名無しさん
09/08/01 23:11:12
ＦＦＴ式に回転させるとそんな苦労も水の泡だぜ
647:デフォルトの名無しさん
09/08/01 23:29:58
周りからそんなに反論されると、なんか自分も自信がなくなってきた。
まあそれはともかくとして、
表示を10倍くらいに拡大すると、もはや直角二等辺三角形２つを並べたテクスチャの斜めの辺の挙動が無視できなくなるな。
大体10x10にならんでるけどところどころ９になったり１１になったりする。
それに斜めにずれているところがあることに気づく。ちょうどポリゴンを斜めに並べたところだ。
なんだかどうにもならないことのような気がしてくる。
頂点を共有せずに微妙に１ピクセル分ずらしたりの調整が必要になってくるのかも。
648:デフォルトの名無しさん
09/08/02 00:21:13
とりあえず軽く実験してみたが、
転送先スクリーン座標を-0.5f, -0.5f しただけでは、拡大転送時に周りの1ドットの影響を受けてしまうな
649:デフォルトの名無しさん
09/08/02 00:33:43
>>648
そうだなぁ。例えば１０倍拡大したときは0.1f、0.1fくらいでちょうどいいようだ。
微妙に9倍や11倍されてるピクセルがあるようだが、
こんなに拡大されたＣＧを凝視するようなことはないだろうから実用上は問題ないだろう。
２Ｄ表示における倍率に指定すべきUVオフセットが影響を受けるのかもしれない。
しかしGPUの機種の差異もありそうだしなぁ。
650:デフォルトの名無しさん
09/08/02 14:36:23
>>641が言っているように、0.5ずらしは
本現象とは何の関係もない。
D3DTEXF_LINEARが、2x2エリアをサンプルするのが原因。
一応、UV座標を半テクセル分内側にずらすことで回避出来る。
float texture_width = 512;
float texture_height = 512;
float wh = 1.0/(texture_width*2);
float hh = 1.0/(texture_height*2);
float uv_quad = { u0 + wh, v0 + hh, u1 - wh, v1 - hh };
ただし、ずらす分マップするエリアが狭まるので注意。
651:デフォルトの名無しさん
09/08/02 15:24:25
状況や描画させ方によるので
唯一これが最速だという答えは出せません。
ゲーム、あるいはエンジンに合わせて最適化がそれぞれ必要です。
652:デフォルトの名無しさん
09/08/02 15:28:10
それでも、Direct3D9で2D等倍表示をするときだけしか正しくない「頂点座標を0,5ずらす」を
後生大事に信じ込むのは馬鹿だろう
653:デフォルトの名無しさん
09/08/02 15:40:27
基本的な質問で申し訳ないんだが、
GPUの機種によって描画できる場合と描画できない場合ができていて困っている。
原因は何が考えられるだろう？
動作条件は
・DirectX 9使用
・Vertex/PixelShader使用
・FVFはPosition|DiffUse|UV
・空間座標変換はCPU側で事前に合成してから単一の4x4行列としてID3DXEffectに入力。
現行のプログラムでRADEON HD4850だと正常にポリゴンが描画できるが、
Intel GMA950では描画されない。Device->Clear()は動いてる。
また、FVFがPositionRhw|DiffUse|UV のときは描画できることも確認している。（座標変換が利かなくなるが）
シェーダー使ってなかったころのプログラムやシェーダーを使ってる
サンプルプログラムでは描画できてるから、ハードウェアのせいではない。
654:デフォルトの名無しさん
09/08/02 15:45:16
きわめて一般的な描画方法だからどこかおかしいんと違う？
655:デフォルトの名無しさん
09/08/02 17:51:26
>>653
それだけの情報で分かるわけないだろう。
デバッグランタイムも何も文句言わないの？
656:デフォルトの名無しさん
09/08/02 19:32:40
>>655
デバッグランタイムは動かしたことないな。試してみる。
開発マシンじゃなくてテストマシンだったからDirectX SDKは入れてないので。
vs/ps3.0を指定してたら描画結果が真っ白になってしまったことはあったけど、
今回はそんなわかりやすい現象じゃないからなぁ。
657:デフォルトの名無しさん
09/08/02 23:00:15
URLﾘﾝｸ(developer.download.nvidia.com)
Stencil Routed K-BufferってDirectX9では出来ないんでしょうか？
マルチサンプルへのアクセスが必要でDirectX9では出来ない、というようなことが書いてありますが
マルチサンプル使わずに出来たりはしないんでしょうか。
658:デフォルトの名無しさん
09/08/03 00:21:35
ここで質問していいのか微妙な内容なのですが
スレ違いでしたらスルーしてください。
DirectXを使用するとどうしても気になってくるんですが
プログラムで使用されているVRAMの消費量を調べる方法はありませんか？
メモリ使用量を調べるような関数があるのかと思ったのですが見つけられず…
よろしくお願いします。
659:デフォルトの名無しさん
09/08/03 02:01:17
DeviceCaps取得すれば
ＶＲＡＭ容量わかるお
660:デフォルトの名無しさん
09/08/03 13:27:18
nai
661:デフォルトの名無しさん
09/08/03 13:27:58
このスレにいる人レベル高いなぁ
多分大学生が多いだろうから、大手狙いなんだろうなぁ……負けないように何か作るか
662:デフォルトの名無しさん
09/08/03 14:04:14
Zバッファがうまく動かないんですが
環境
WindowsXP VisualStudio2005 MFC Geforce9600GT
初期化
m_d3dPP.EnableAutoDepthStencil = TRUE;
m_d3dPP.AutoDepthStencilFormat = D3DFMT_D16;
LINE_VERTEX line[6] = {
{-1 , 0, 0, 0xFF00FF00},
{1 , 0, 0, 0xFF00FF00},
{0 , 0 , 0 , 0xFFFF0000} ,
{0 , 1 , 0 , 0xFFFF0000},
{0 , 0 , -1 , 0xFF0000FF} ,
{0 , 0 , 1 , 0xFF0000FF}
};
CreateVertexで書き込み
663:デフォルトの名無しさん
09/08/03 14:06:11
視点の初期化（マウスで回転した時も）
D3DXMatrixLookAtLH(&d3dm , &D3DXVECTOR3(0, 0, 6) ,
&D3DXVECTOR3(0, 0, 0) , &D3DXVECTOR3(0 , 1 , 0));
m_pDeviceD3D->SetTransform(D3DTS_VIEW , &d3dm);
D3DXMatrixPerspectiveFovLH(&d3dm , D3DXToRadian(45.0) ,
(float)rect.right / (float)rect.bottom , 0 , 1000);
m_pDeviceD3D->SetTransform(D3DTS_PROJECTION , &d3dm);
D3DXMatrixRotationYawPitchRoll(&Rot, D3DXToRadian(m_AngleY), D3DXToRadian(m_AngleX), D3DXToRadian(0.0f));
m_pDeviceD3D->SetTransform(D3DTS_WORLDMATRIX(0) , &Rot);
m_pDeviceD3D->SetRenderState(D3DRS_CULLMODE , D3DCULL_NONE);
m_pDeviceD3D->SetRenderState(D3DRS_LIGHTING , FALSE);
m_pDeviceD3D->SetRenderState(D3DRS_ZENABLE, TRUE);
m_pDeviceD3D->SetRenderState(D3DRS_ZWRITEENABLE, TRUE);
664:デフォルトの名無しさん
09/08/03 14:09:05
描画
m_pDeviceD3D->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(20,0,50),1.0f, 0);
m_pDeviceD3D->BeginScene();
m_pDeviceD3D->SetStreamSource( 0, g_pVB, 0, sizeof(LINE_VERTEX) );
m_pDeviceD3D->SetFVF( D3DFVF_XYZ|D3DFVF_DIFFUSE );
for(int i=0; i<3; i++)
m_pDeviceD3D->DrawPrimitive( D3DPT_LINELIST, i*2, 1);
XYZの軸を引いてマウスで回転させてるだけなんだけど
角度によって後ろの線が前に出てきたりZバッファが機能してないみたいなんだけど
どこが間違ってるんでしょう？
665:デフォルトの名無しさん
09/08/03 15:40:38
D3DXMatrixPerspectiveFovLHの第4引数（znear）が0になってますがな
666:デフォルトの名無しさん
09/08/03 19:40:54
>665
ゼロからじゃだめなんですか？
667:デフォルトの名無しさん
09/08/03 20:22:40
だめ。
視錐台の前面が面積0になってしまう。
668:デフォルトの名無しさん
09/08/03 20:49:46
>>665
ありがとう、とりあえずそこを1.0にしてみたら出来たけど
いまいち原理が良くわからないから調べますわ
669:デフォルトの名無しさん
09/08/03 23:17:36
質問です。
川瀬式MGFを実装しようと思い、ここを参考にしながら
URLﾘﾝｸ(journal.mycom.co.jp)
やってみたのですが、うまくいきません。
低解像度テクスチャに書き出し拡大しても
こんな風に●の中心を中心に、拡大されたようにならないんですが
何かご存知のであればアドバイスをいただきたいです。
670:デフォルトの名無しさん
09/08/03 23:33:29
きみがやってみて失敗した結果の画像をどこかのアプロダに張れないか
671:デフォルトの名無しさん
09/08/03 23:35:04
ちょっと待っててください
672:デフォルトの名無しさん
09/08/04 01:58:54
そして>670は待ち続けた。
雨が降ろうと、風が吹こうと、雪が積もろうと、>671が帰ってくるのをずっと
待ち続けた。
スレの主人はそんな>670を不憫に思い、毎晩、スレを畳む時間になると、残り
物のレスをそっと脇に置いて帰ったが、翌朝までに手をつけられていたことは、
一度も無かった。>670は、ただひたすら一つのレスを見続けていた。
結局、>671が帰ってくることは、二度と無かったのだ。
なぜなら、>671は
673:デフォルトの名無しさん
09/08/04 08:48:32
（続き） なぜなら、>671は>672だったからなのだ。
674:デフォルトの名無しさん
09/08/04 10:00:36
UV値を入れずにポリゴンを書くとテクスチャを指定しても表示されないんだけど
大きさを可変にしたいからタイルパターンでテクスチャを貼り付けたい時はどうすればいいの？
675:デフォルトの名無しさん
09/08/04 10:03:27
そういうふうにUVを指定しろ
676:デフォルトの名無しさん
09/08/04 17:30:35
>674
テクスチャ画像を作る段階でタイルパターンの画像にしておけば良いのでは？
677:デフォルトの名無しさん
09/08/04 17:36:42
シェーダー使えば可能だろ
678:デフォルトの名無しさん
09/08/04 17:51:34
いろいろあるよ
679:デフォルトの名無しさん
09/08/04 18:17:51
２Ｄを扱う場合、高速で描画できる方法を教えてください。
一応自分なりに調べて、描画をさせてみたのですが
ＤＸライブラリというライブラリを使った場合と比べるとかなり差が出てしまい
原因を探しています。
描画方法は、頂点バッファを使いDrawPrimitiveで画像を１つずつ描写しています。
よろしくお願いします。
680:デフォルトの名無しさん
09/08/04 18:26:04
頂点バッファを使い1回のDrawPrimitiveで全部の画像を描画すると速いと思うよ
必要な絵全部を1枚のテクスチャに詰め込んでおくと良い
681:デフォルトの名無しさん
09/08/04 18:44:55
>>頂点バッファを使い1回のDrawPrimitiveで全部の画像を描画すると速いと思うよ
このやりかたが分からず…方法の載っているサイトなどありましたらおねがいします。
DirectXによる２Ｄゲーム制作サイトなど見たのですが、１フレーム分描画するのに何度もDrawPrimitiveしているものばかりでした
682:デフォルトの名無しさん
09/08/04 19:00:41
画像数×6個の頂点が入る大きさの頂点バッファを作って、
全部の頂点を書き込んで、DrawPrimitiveするだけ
683:デフォルトの名無しさん
09/08/04 19:15:58
頂点バッファを一つにまとめて、テクスチャも一つにし
それを一度にDrawPrimitiveすればいいってことですよね…
つまりDrawPrimitiveの呼び出し回数が描画速度に関わってるって
ことですか…
複数のテクスチャを扱っているので、できるだけ呼び出し回数を減らしてみます。
684:デフォルトの名無しさん
09/08/04 19:25:00
>>683
↓まだ読んでないなら、読んでおくといい
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
685:684
09/08/04 19:47:36
>>684
ありがとうございます。複数のテクスチャを扱うときは
グループ化すれば、描写速度があがるんですね。非常に勉強になりました。
686:683
09/08/04 19:51:33
>>685は名前ミスです。
早速、現状と比べてきます。
687:デフォルトの名無しさん
09/08/05 01:40:39
表示中のモデルに直接色を塗りたいんだけど
爆発で黒く焦げたりとかしたい
決まった場所じゃないし、同じモデルがいっぱいあるから
テクスチャをいじるわけにもいかないし
どうすればいいんですか？
688:デフォルトの名無しさん
09/08/05 05:35:12
頂点カラーを使うとか
689:デフォルトの名無しさん
09/08/05 07:36:02
マルチテクスチャで加工用のを重ねる。
洋ゲーでキャラを血まみれにするので使ってた実例もなんかあったはず
690:デフォルトの名無しさん
09/08/05 09:51:18
質問です。
>>684でもあがっているこの最適化ページに
＞できるだけ正方形テクスチャーを使用します。ディメンジョンが 256 × 256 のテクスチャーが最速です
とあるのですが、
今までパーティクルに使うテクスチャは32x32くらいのなるべく小さいものにしていました。
もしかして256x256のほうが良いのでしょうか？
691:デフォルトの名無しさん
09/08/05 10:07:16
色々な環境で実測してから言え
692:デフォルトの名無しさん
09/08/05 10:18:23
32x32のテクスチャをたくさん使ってるなら256x256の1枚だけにまとめた方がいいかもしれないが、
32x32のテクスチャをひとつしか使ってないならそのままでよい
693:デフォルトの名無しさん
09/08/05 10:45:30
>>691
お前何しにこのスレ来てんの？
694:デフォルトの名無しさん
09/08/05 11:06:40
>>690
どうでもいいが、DirectXヘルプでよく出てくるこの「ディメンジョン」という訳が気持ち悪い。
dimensionの発音はディメンションだし、寸法という適切な日本語もあるのに。
695:デフォルトの名無しさん
09/08/05 11:56:10
>>694
昔、FORTRANの時代にSIONをTIONと間違わないためにあえてディメンジョンと言ってた名残かと
696:デフォルトの名無しさん
09/08/05 13:31:59
ディメンジョンが何を指しているのかもよくわからんしな。
＞できるだけ正方形テクスチャーを使用します。ディメンジョンが 256 × 256 のテクスチャーが最速です
画像サイズが。という意味でいいんだろうかｗ
X軸とY軸のことをディメンジョンと呼んでいるような気はするんだがｗ
697:デフォルトの名無しさん
09/08/05 13:36:26
>>696
>>694 がいってる、寸法っていうのがしっくり来るな。
698:デフォルトの名無しさん
09/08/05 13:48:54
日本人にとってはdimensionというと数学用語の「次元」のほうが馴染みがあるけど、
英和辞典で最初に出てくるのは「寸法」だね。
699:デフォルトの名無しさん
09/08/05 13:49:46
訳した人がよくわからなかっただけじゃねえの？
700:デフォルトの名無しさん
09/08/05 15:30:30
マイクロソフトの翻訳が糞なのは仕様
surfaceの正確な発音はサーフィスだけど
サーフェイスと書いてあったり
701:デフォルトの名無しさん
09/08/05 15:33:21
それって翻訳なのか？
702:デフォルトの名無しさん
09/08/05 15:44:19
>>700
まあまあ。最近は歴史学でも用語発音の厳密化の流れはあるけど、
『サーフェイス』か『サーフェス』、『サーフィス』かというのは和製英語のレベルだよ。
（両方でググると引っかかる結果が違って興味深い）
英語的に考えると『サー』の部分も『フィ』の部分もむかつき音だから
「セーフェス」のほうがむしろ近いわけだが、読んでも意味がわからなくなる。
個人的にはサーフェスくらいかな。でもサーフェイスで覚えてしまってる。
703:デフォルトの名無しさん
09/08/05 16:11:46
"むかつき音"の検索結果 2 件
URLﾘﾝｸ(www.google.co.jp)
704:デフォルトの名無しさん
09/08/05 16:19:28
そもそもMSDNの翻訳って、機械翻訳じゃなかったっけ？
705:デフォルトの名無しさん
09/08/05 16:25:06
MSの機械翻訳はそこまで優秀じゃないよ
少なくともDirectX部分に関してはMSKKの川西さんが最終的な監修をしているはず
706:デフォルトの名無しさん
09/08/05 17:02:58
やってる奴が、有能か無能か、業務か無料奉仕かなんて関係無く
機械翻訳にしか見え無いとは酷い話だ
707:デフォルトの名無しさん
09/08/05 17:05:05
くだらねえ
708:デフォルトの名無しさん
09/08/05 20:52:40
初心者のばかな言動を叱り付けると爽やかな気持ちでプログラミングに励むことができます
709:デフォルトの名無しさん
09/08/06 14:46:35
RPG風なダメージを表現しようとして敵が表示されているときのみ数字を表示って考えてるんだが
if D3DXVec3Dot( &敵, &カメラ )>0
ってやるとカメラを回転させたときに数字が出ずに困ってる。
方向ベクトルの符号を変えればよいっぽいんだが変えるタイミングがわからない。
710:デフォルトの名無しさん
09/08/06 15:17:27
数字の表示を独立するんじゃなくて
敵の表示処理のときに一緒に処理すればいいんじゃないの？
711:デフォルトの名無しさん
09/08/06 15:45:35
質問させて下さい。
固定機能パイプラインのディフューズ、インデックスバッファを使用して
描画しているのですが、頂点に設定した色で面の色は補間されてしまいます。
頂点毎の色ではなくて面毎に色を設定したい場合は頂点シェーダを
使用するしかないのでしょうか？
712:デフォルトの名無しさん
09/08/06 16:02:59
>>711
D3DRS_SHADEMODEをD3DSHADE_FLATにすると、最初の頂点の色で
面が塗られる。
713:デフォルトの名無しさん
09/08/06 16:17:44
>>712
ぬおおお！！本当だ！！知らなかった！！
本にも載ってなかった、ありがとうございます！！
714:デフォルトの名無しさん
09/08/06 17:26:22
その本を捨てるか
俺のチンコをしゃぶるか
選べ
715:デフォルトの名無しさん
09/08/07 08:52:57
>>714 氏ね
プリミティブ数より頂点数が少ない場合、
（インデックスバッファを使用して頂点を共有しまくってる場合）
どうすればいいんですかね？
こういう場合はFLATでのシェーディングは不可能という事ですか。
716:デフォルトの名無しさん
09/08/07 10:34:40
>>715
そんなにFLATにこだわるならポリゴンごとに頂点を分割したらいいんじゃないの？
何をそんなにこだわってるんだか。
717:デフォルトの名無しさん
09/08/07 10:51:09
>>716
こだわってるはモデラー的なものを作りいんですよ。
モデラーってスムージング角度を指定して、FLATかスムースになりますよね。
頂点数がどれくらい多くなるか分からないので、
効率考えてインデックスバッファは使いたいんですが、
今のやり方ではDirectXの仕様的に無理そうな感じですね。
718:デフォルトの名無しさん
09/08/07 10:52:02
面ごとの色を決めて描画という方法は無い。
少なくとも頂点カラーは使えない。
やるならマテリアルわけするしかあるまい。
俺も昔OpenGLで同じことをやりたくて探したが、OpenGLにもDirect3Dにもなかった。
頂点カラーならぬ、面カラーがあるに違いないと思っていたが、幻想だったよ。
719:デフォルトの名無しさん
09/08/07 11:03:07
質問です。
テクスチャに対して、マルチサンプリングを行っての描画をしたいのですが、可能でしょうか？
以下のことは調べました。
・CreateTextureしたテクスチャからGetSurfaceLevelし、それをSetRenderTargetして描画
マルチサンプリングは効きませんが、描画がちゃんとできるのを確認しました。
・CreateRenderTarget したサーフェイスをSetRenderTargetして描画
描画後、LockRectなどで描画が確かに行われているこを確認しました。
マルチサンプリングも効いています。
後者で描画した後、LockRectして手に入れた内容を、テクスチャーに転送する。
という手段でとりあえずは可能なのですが、いかにも周り道です。
ダイレクトにテクスチャにマルチサンプリング描画を行うにはどうしたらよいのでしょうか？
720:デフォルトの名無しさん
09/08/07 11:03:58
シェーダーを使えば可能
721:デフォルトの名無しさん
09/08/07 12:32:00
>>718
そうなんですかorz
ありがとうございました。
722:デフォルトの名無しさん
09/08/07 17:33:45
>>718
>>720
当然じゃないか。
３Ｄの基本単位は頂点なのであって、
３つの頂点の配置からポリゴンの位置・大きさ・向きを判定するんだ。
面が先にあるわけじゃない。
723:デフォルトの名無しさん
09/08/07 17:47:35
別に当然ではないだろう。
どうせ描画時には面単位で描画していくのだから。
DrawPrimitiveの引数だって、頂点数じゃなくて「プリミティブ数」じゃないか。
724:デフォルトの名無しさん
09/08/07 23:47:44
DirectSoundってボリューム増幅させることできます？
IDirectSoundBuffer8::SetVolumeは増幅はサポートしてないって書いてあるけど
725:デフォルトの名無しさん
09/08/08 00:44:07
アプリケーションのデフォルトを50%相当の音量にすればよい。
726:デフォルトの名無しさん
09/08/08 18:39:50
ウィンドウモードで画面サイズが変わったらバッファをリセットするんだけど
テクスチャとバーテックスバッファを登録した状態でResetを呼び出すと失敗するんだけど
全部ReleaseしてResetして再登録しろってこと？
727:デフォルトの名無しさん
09/08/08 18:41:59
D3DPOOL_DEFAULTは全て
728:デフォルトの名無しさん
09/08/08 18:50:58
なるほど
729:デフォルトの名無しさん
09/08/08 19:40:06
いつもテクスチャはD3DPOOL_MANAGEDしか使わないんだが、
RenderTargetに指定できない以外は別に問題ないよな？
730:デフォルトの名無しさん
09/08/08 19:47:48
問題ない
731:デフォルトの名無しさん
09/08/08 20:51:41
D3DPOOL_MANAGEDに変えたらテクスチャが真っ赤になったんだが
どういうこと？
732:デフォルトの名無しさん
09/08/08 20:54:16
これまで初期化を怠ってきたから環境依存してる
733:デフォルトの名無しさん
09/08/08 21:52:12
LPDIRECT3DTEXTURE9 pTex;
HRESULT hr;
hr = D3DXCreateTexture(dev, img.GetWidth(), img.GetHeight(), 1,
0, D3DFMT_A8R8G8B8, D3DPOOL_MANAGED, &pTex);
D3DLOCKED_RECT pLockedRect;
hr = (*pTex).LockRect(0, &pLockedRect, NULL, D3DLOCK_DISCARD);
unsigned char *dest = (unsigned char*)pLockedRect.pBits;
unsigned char *src = img.GetData(); <- imgはRGBの24bit画像データが入ったクラス
int j;
int dest_pos=0;
int src_pos=0;
for(j=0;j<img.GetWidth() * img.GetHeight();j++){
dest[dest_pos] = src[src_pos+2];
dest[dest_pos+1] = src[src_pos+1];
dest[dest_pos+2] = src[src_pos];
dest[dest_pos+3] = 0xff;
}
dest_pos+=4;
src_pos+=3;
}
hr = (*pTex).UnlockRect(0);
734:デフォルトの名無しさん
09/08/08 21:54:32
dest[dest_pos] = src[src_pos+2];
dest[dest_pos+1] = 0xff;
dest[dest_pos+2] = 0xff;
dest[dest_pos+3] = 0xff;
こうすると真っ白
dest[dest_pos] = src[src_pos+2];
dest[dest_pos+1] = 0xff;
dest[dest_pos+2] = src[src_pos];
dest[dest_pos+3] = 0xff;
こうすると紫
dest[dest_pos] = src[src_pos+2];
dest[dest_pos+1] = src[src_pos+1];
dest[dest_pos+2] = 0ｘｆｆ;
dest[dest_pos+3] = 0xff;
こうすると水色
dest[dest_pos] = src[src_pos+2];
dest[dest_pos+1] = src[src_pos+1];
dest[dest_pos+2] = src[src_pos];
dest[dest_pos+3] = 0xff;
これで青
どういうこと？まじで分からない
735:デフォルトの名無しさん
09/08/08 22:08:18
srcの中身なんだかわかんねーしよ
それはそうと、D3DFMT_A8R8G8B8であればdestのオフセットは 0=B 1=G 2=R 3=A
736:デフォルトの名無しさん
09/08/08 22:20:35
というか、あれだけ優秀なD3DXライブラリを使わない理由がわからない。
737:デフォルトの名無しさん
09/08/08 22:33:14
せめてビットシフトのマクロ作れよｗ
なんだその無様なコードは
738:デフォルトの名無しさん
09/08/08 22:35:24
原因判明 UV座標が狂ってたｗ
739:デフォルトの名無しさん
09/08/08 22:37:15
>>736
モデルファイルのコンバーターを作ってるから専用のライブラリで統合してるんだ
740:デフォルトの名無しさん
09/08/08 22:39:31
>>737
別に無様とは思わないが？
741:デフォルトの名無しさん
09/08/09 14:11:40
ポリゴンが透けてしまう原因として何が考えられますか・・・？
アバウトな質問ですいません。
742:デフォルトの名無しさん
09/08/09 14:16:01
アルファブレンドの値や設定が透過するようになってるとか？
743:デフォルトの名無しさん
09/08/09 14:33:09
>>742
アルファブレンドは使っていないんです。
744:デフォルトの名無しさん
09/08/09 14:53:23
>>741
われわれはエスパーではないのでそんなアバウトな説明では何もわかりません。
745:741
09/08/09 14:58:32
透けてしまうというか奥にあるはずのポリゴンが
手前に表示されてしまうという現象です。
頂点座標は間違っていないので、何故かまったく分からないです。
同じ現象にあった方が居たらと思いまして質問しました。
746:デフォルトの名無しさん
09/08/09 15:08:36
Zバッファおかしんじゃね
747:デフォルトの名無しさん
09/08/09 16:22:23
>>745
Zバッファが有効になってないと、前後関係無く最前面に描画されてそうなる。
748:デフォルトの名無しさん
09/08/09 18:17:40
>>746
>>747
ご指摘の通りでした、ｚバッファ有効になってなかったです。
原因は視錐台の前面をゼロにしていました。
過去ログ見れば一発でしたね、お手数お掛けました。
749:デフォルトの名無しさん
09/08/09 23:27:48
ライトがXファイルによって反映されるのとされないのがあるのはなぜですか？
アンビエントはかかるんですが･･･
750:デフォルトの名無しさん
09/08/09 23:29:03
マテリアル関係かな
751:デフォルトの名無しさん
09/08/10 09:45:58
法線がないんじゃあるまいか？
確かデフォルトだとオートノーマライズもOFFだし、初心者ひっかかりやすいよね
752:デフォルトの名無しさん
09/08/10 14:09:07
それでした
ずっとアンビエントでやってたから気が付かなかった・・・
753:デフォルトの名無しさん
09/08/10 15:34:01
オートノーマライズって何？
754:デフォルトの名無しさん
09/08/10 15:38:53
glEnable(GL_NORMALIZE) のことでは
755:デフォルトの名無しさん
09/08/10 15:39:35
ごめん、DirectXのスレだった・・・逝ってくる
756:デフォルトの名無しさん
09/08/10 17:08:21
>>753
頂点の構成要素には、位置座標ベクトルや法線ベクトルがあるが
これらはレンダリングパイプライン通過時に、頂点変換行列によって変換される。
この頂点変換行列の内容によっては、法線ベクトルが単位長でなくなることもある。
パイプライン内のライティング処理は法線ベクトルを利用し計算を行うが、
そのとき法線ベクトルは単位長でないと正確な計算が出来ない。
よって、ライティング処理時、法線ベクトルを自動で正規化し単位長にするのがオートノーマライズ機能。
757:デフォルトの名無しさん
09/08/10 18:35:44
なんだ左手系とかで面の向きが分かるから勝手に法線を生成してくれるのかと思った
自分で作らないとだめなのかな？
758:デフォルトの名無しさん
09/08/10 18:50:39
頂点は複数の面で共有するケースもあるので、
法線を動的に生成するのは、重い割に得られるものが少ない。
759:デフォルトの名無しさん
09/08/10 19:21:48
出来ると思うのなら、鋭角と鈍角が入り交じった立体から、
何の情報もなく法線を自動生成するプログラムを作ってみろ。
760:デフォルトの名無しさん
09/08/10 19:29:03
何の情報も無かったら法線以前に描画出来ないだろｗ
761:デフォルトの名無しさん
09/08/10 19:33:49
立体なんだから頂点情報があるのが前提だと想像できないのは、
プログラム云々以前だな。
762:デフォルトの名無しさん
09/08/10 19:36:20
法線の生成なんて何十年も前から論文が何十本と出ていて、未だにコレという決定的な方法がない領域だからな。
763:デフォルトの名無しさん
09/08/10 22:24:55
右回りになる方向のベクトルでいいんじゃないの？
764:デフォルトの名無しさん
09/08/10 22:47:33
>>763
１つの頂点を共有する３つ以上のポリゴンの頂点における法線のことだろ？
765:デフォルトの名無しさん
09/08/10 22:53:10
>>763
鈍角をどうやって認識するつもりなんだ？
体験版でもいいから、まともなモデリングソフトを使って勉強し直せ。
766:デフォルトの名無しさん
09/08/10 22:55:58
球体を外積で出した法線で描画すればいかに間抜けなのかが分かるよ。
767:デフォルトの名無しさん
09/08/11 00:19:26
話が噛み合ってないのか？
URLﾘﾝｸ(homepage1.nifty.com)
こういうことじゃないの？
768:デフォルトの名無しさん
09/08/11 02:46:04
包丁一本～さらしに巻いて～
769:デフォルトの名無しさん
09/08/11 09:35:29
>>767
だからそれじゃ鈍角の法線が出ないんだよ。
かみ合っていない以前に、分かっていないのなら勉強し直せ。
770:デフォルトの名無しさん
09/08/11 09:39:28
なんで鈍角が出ないかといえば、そこが鋭角なのか鈍角なのかを頂点座標だけでは判断できないから。
771:デフォルトの名無しさん
09/08/11 10:12:57
鈍角の法線って何ですか?
772:デフォルトの名無しさん
09/08/11 10:14:51
内積とれば鈍角か鋭角は判断できる。
でも鈍角だったら、なんなんだ？
773:デフォルトの名無しさん
09/08/11 10:55:42
凹多角形の事でも言ってるんだろうか？
774:デフォルトの名無しさん
09/08/11 11:14:06
出ないっていう奴が問題だして
出るって言ってる奴が解けば結論でる
775:デフォルトの名無しさん
09/08/11 11:57:10
>>772
鈍角鋭角というのは角度の話じゃない。
法線を出すときに頂点座標だけでは、
周囲の頂点と平均をとるのかとらないのかが判断できないということだよ。
だから一般的な3Dフォーマットは、法線をデータとして含めるか、
頂点に対してスムージングをかけるか判断するための情報を入れるんだよ。
776:デフォルトの名無しさん
09/08/11 12:30:56
1行目がわかりません
角度じゃない鈍角鋭角って何のことですか
777:デフォルトの名無しさん
09/08/11 12:51:49
曲線のなす角と平面のなす角を言いたいんじゃないのか？
778:デフォルトの名無しさん
09/08/11 13:07:02
すいません、質問したいのですが、
現在外部ファイルを読み込みたくて
APIのGetOpenFileNameを使っているのですが
この関数を使った後だと何故か
D3DXCreateTextureFromFileEx や
D3DXLoadMeshHierarchyFromX が
失敗してしまうみたいなのですが原因が分かりません…。
779:デフォルトの名無しさん
09/08/11 13:22:57
たぶんカレントディレクトリが変更されている
780:デフォルトの名無しさん
09/08/11 13:27:29
>>779
カレントディレクトリで検索してみたら
確かにGetOpenFileNameが成功するとディレクトリが変わってしまうそうですね。
恐らくこれが原因だと思います、ありがとうございました！
781:デフォルトの名無しさん
09/08/11 13:28:02
現行のやつをカレントディレクトリに依存しないようにするのがいいけど、
とりあえず OFN_NOCHANGEDIR で試してみそ
782:デフォルトの名無しさん
09/08/11 13:40:30
>>781
ちゃんと動くようになりました！
ありがとうございます、昨日ここで1日詰まってたんで助かりました＾＾；
普段からフルパスで書いてるほうがいいんですかね・・・？
ほとんどの場合カレントディレクトリ前提でソース書いてましたが…
783:デフォルトの名無しさん
09/08/11 13:46:14
>>782
別にいい悪いはないが、相対アクセスをするときには常にカレントディレクトリがどこかを把握しておく必要がある。
784:デフォルトの名無しさん
09/08/11 13:49:25
なるほど、たしかに相対する時はカレントディレクトリだとやりにくそうですね…
ありがとうございます、すごく参考になりました。
785:デフォルトの名無しさん
09/08/11 14:04:09
>>784
老婆心ながら蛇足を描くと、
ゲームのようなデータファイルの多いソフトを開発する際は、相対アクセスの方が便利かもしれない。
VisualStudioのデバッグ時に作業ディレクトリを指定できるのでそこでカレントディレクトリを設定しておくと、
必要に応じて複数の動作環境を用意できる。
サンプルゲームが複数になってきたらそれで切り替えられる。
786:デフォルトの名無しさん
09/08/11 14:44:23
Xファイルを別フォルダに入れて読み込んでも問題ないのに
テクスチャをXファイルと一緒に入れるとテクスチャだけ読み込まないのはなぜですか？
一応Xファイル内にはA.BMPのように書いて同じところにあるファイルを読むようにしているんですが・・・
787:デフォルトの名無しさん
09/08/11 15:04:19
X-File内の画像のパスを画像ファイルのあるパスに設定しろ。
X-Fileを読み込むときに勝手にカレントディレクトリを移動してくれる訳じゃないぞ。
788:デフォルトの名無しさん
09/08/11 15:09:49
やっぱりそれしかないですか・・・
わかりました
789:デフォルトの名無しさん
09/08/11 18:01:10
やっぱりパス関連の面倒を見てくれるローダは、さっさと自分で作るべきだよな
790:デフォルトの名無しさん
09/08/11 18:04:54
>>775
ようするにその角が丸みを帯びてるのか鋭いままなのかは計算では設定出来ないと言いたいのか？
791:デフォルトの名無しさん
09/08/11 18:11:54
その通り
792:デフォルトの名無しさん
09/08/11 19:19:55
どうでもいいが、頂点法線のスムージングの話で「鈍角」「鋭角」という用語を使うやつは初めて見た
793:デフォルトの名無しさん
09/08/11 19:52:30
「どうでもいい」のにレスする意味が分からない
794:641
09/08/11 19:59:15
なんにしろ、読み返してみれば鈍角さんがなんのことを言っているのかを
解明するだけの流れだったな。
795:デフォルトの名無しさん
09/08/11 21:08:11
>>792
鈍角は90度を超える角で、鋭角は90度未満の角だよな、
小学校かどっかで習う範囲だと。
796:デフォルトの名無しさん
09/08/11 22:46:42
だから誰もそんなことは問題にしてないんだって
797:デフォルトの名無しさん
09/08/11 22:53:36
スムージングを使わずに単にポリゴン数を増やせばいいだけじゃん
798:デフォルトの名無しさん
09/08/11 22:55:37
本当にそれでいいと思うのならそうすればいい。
799:デフォルトの名無しさん
09/08/12 00:42:40
必要になったら実装すればいいだけで、大抵は平均化だけで十分。
というかデザイナとの相談だな。
800:デフォルトの名無しさん
09/08/12 00:54:41
D3DXLoadMeshHierarchyFromX(
の
LPD3DXFRAME* ppFrameHeirarchy,
LPD3DXANIMATIONCONTROLLER* ppAnimController
この部分をXファイルじゃなくて計算で組み立てたいんだが
どっかに解説したサイトとかサンプルとかありませんかね？
この単語で検索すれば出てくるとかヒントでも
801:デフォルトの名無しさん
09/08/12 00:56:39
平均化だけで十分って、立方体とかが悲しいことになるぞ。
相談も何も普通に法線を含めればいいだけの話だろ。
802:デフォルトの名無しさん
09/08/12 00:59:11
>>800
自分でモデリングソフトのアニメーション部分を作るつもりなのか？
というかそれ以前にプログラム云々以前で、
アニメーションを作る工程をやったことがあるのか？
803:デフォルトの名無しさん
09/08/12 01:02:34
>>802
モデリングソフトのようなものを作ってまして
804:デフォルトの名無しさん
09/08/12 01:10:48
またお前か
805:デフォルトの名無しさん
09/08/12 02:07:36
DirectXのプログラミングはすぐに次のバージョンに移れるものですか？
最近DIrectXを始めたばかり、というか 9 か 10 を勉強するかで悩んでいます。
現在使用しているPCがWindowsXPで10が扱えまないので9にしようと考えていたのですが、
今後新しいOSが普及して10以降が主流になったりすると置いてかれるような気がしまして。
そのPCも大分ガタが来たので10が対応しているPCに買い替えることも考えています。
今は10対応といえばvistaくらいでしょうが・・・
806:デフォルトの名無しさん
09/08/12 05:09:57
FromX使わない方が勉強になるね
頂点情報をバイナリ化したりとか色々出来るようになるし
807:デフォルトの名無しさん
09/08/12 05:15:28
>>805
10はシェーダ必須だから敷居が高め。
まず9をFVF使用で書けるようになってから、9のシェーダ、10のシェーダと行くのが比較的平坦な道のりだと思う。
多分言ってる意味分かんないと思うけど要するに9のチュートリアルから始めていいんじゃないかなということだ。
808:デフォルトの名無しさん
09/08/12 08:52:28
Easy Link Libraryの他にdirectx用のライブラリってありますか?
809:デフォルトの名無しさん
09/08/12 08:56:42
たくさんある。
810:デフォルトの名無しさん
09/08/12 09:07:07
9でやった方が楽。
10は抽象化されていて、慣れてないと途方に暮れる。
10を改造して11にするのは難しくはなさそう。
製品を売るなら9。
趣味のライブラリなら、9&10共用。将来は10を捨てて9&11でもいい。
811:デフォルトの名無しさん
09/08/12 09:30:14
将来を見据えるなら11オンリーだろｗ
Windows7が出てしばらくすればさすがにXPはかなり数が減るし
その頃にはDirectX9世代のビデオカードなんて淘汰されてるよ。
現状でさえ３世代前の代物なんだから。
812:デフォルトの名無しさん
09/08/12 09:40:05
11は今日からプログラムに取り掛かれない
813:デフォルトの名無しさん
09/08/12 11:20:14
>>811
>Windows7が出てしばらくすればさすがにXPはかなり数が減るし
そうかな？
814:デフォルトの名無しさん
09/08/12 11:24:58
自分が必要だと思う環境でプログラムを組めばいい。
他人に対してどうこう言う問題じゃない。
この分野の人間は自分がやっていることを他人に押しつけたがる者が少なからずいるが、
それは誰のためにもならない。
815:デフォルトの名無しさん
09/08/12 11:32:41
DirectX9
・情報が豊富
・今からでもプログラム可能
・ゲーム作って配布するとしても、流石にDirect9対応必須をうたっていいと思う
DirectX10
・情報そこそこ
・Vistaなら今からでもプログラム可能
・ゲームなどを売るにはつらい（XPユーザーが多いから）
DirectX11
・情報少ない
・将来的に主流になりそう
・今からプログラムするのは困難
とりあえず9で勉強して、おいおい必要に応じてうつればいいかと
816:805
09/08/12 11:54:56
レスありがとうございます。今は9で勉強しておくことにします。
817:デフォルトの名無しさん
09/08/12 11:59:13
おまいらってやたら詳しいけど、趣味なの？本職なの？
818:デフォルトの名無しさん
09/08/12 12:51:59
うるせえ黙れ
819:デフォルトの名無しさん
09/08/12 18:29:21
こんなマッチョじゃ感情移入できない
アドルは永遠の優しい夢見る少年だろう
どうみても童貞じゃないし
820:デフォルトの名無しさん
09/08/12 21:33:17
>>813
いずれにしろDirectX10やDirectX11対応のゲームが増えてくれば
Vistaか７のどちらかにするしかないがVistaは選択肢にはいらないだろ。
どうせ２，３年もすればXPも売られなくなるし
新規でPC買えば全部Windows7化されてるだろ。
いつまでもDirectX9＋XPにしがみ付いて技術的に取り残されるのも馬鹿らしい。
趣味でやる分にはDirectX9でぜんぜん問題ないと思うけどね。
821:デフォルトの名無しさん
09/08/12 21:56:00
固定機能でお茶を濁したクズ本が消えるかと思うと
清々するわ
822:デフォルトの名無しさん
09/08/12 22:04:30
逆に本がぜんぜんでなくなってるよな。
もうついていけてないんだろうか。
823:デフォルトの名無しさん
09/08/12 22:06:45
ていうかゲームなんて作るのやめろ
ゲーＰＧなんてまったく金にならないし
本とか買ってまで作るなマジで
824:デフォルトの名無しさん
09/08/12 23:13:49
金が目的なら株でもいじってろよｗ
825:デフォルトの名無しさん
09/08/13 11:28:23
3Dゲームのエフェクトを強引にキャンセルさせてCPU負荷を下げる方法ってないですか？
826:デフォルトの名無しさん
09/08/13 11:35:32
>>825
えーと、それは自分が作ってるゲームに関する質問？
827:デフォルトの名無しさん
09/08/13 12:45:36
某エロゲのモザイク的な修正がパーティクルで実装されているので
828:デフォルトの名無しさん
09/08/13 13:00:53
実行ファイルを書きかえれ
829:デフォルトの名無しさん
09/08/13 16:10:27
工エｴェｪ(´д｀)ｪェｴエ工工
830:デフォルトの名無しさん
09/08/13 23:35:07
あそこが見たいだけじゃないのか？
831:デフォルトの名無しさん
09/08/13 23:40:13
>>828
長門さんがこちらを見ています
832:デフォルトの名無しさん
09/08/14 07:20:57
脳内変換だ
833:デフォルトの名無しさん
09/08/14 11:11:36
アニメーションコントローラーを使ったアニメーションで
1ループ分のアニメーションの完了を検知したいのですが、
// if(アニメーション時間 >= 1ループかかる時間)
if(AnimationSet(AnimationID)->GetPeriodicPosition( ? ) >=
AnimationSet(AnimationID)->GetPeriod())
このような判定で合っているでしょうか？
合ってる場合、「？」の部分の引数にはなにを指定したらいいのでしょう？
msdnの解説では「アニメーションセットのローカル時間」と書いていますが、
GetPeriodicPosition()の戻り値こそがローカル時間ではないのでしょうか？
834:デフォルトの名無しさん
09/08/14 11:34:13
なんかもう、誰も使ってない、仕様があやふやだし自分で作らない限り無間地獄から抜けられない
という結論が数年前から変わってない。
835:デフォルトの名無しさん
09/08/14 11:56:07
いやいやDirectX使わないとXBOXやWindowsでゲーム作れないって
836:833
09/08/14 12:32:32
自己解決（´・ω・｀）
GetPeriodicPosition()はグローバルな時間をローカル時間に変換するメソッドのようで？
参照すべきだったのはトラックの方でした
837:デフォルトの名無しさん
09/08/14 21:41:02
シェーダーで描画してるんですが
固定機能のフォグって同時に使えるんですかね？
やってみたらかからないので、
やはりピクセルシェーダーで自前でかけるんでしょうか？
838:デフォルトの名無しさん
09/08/14 21:53:15
ピクセルシェーダを自前で書くのなら、自前でかける
839:デフォルトの名無しさん
09/08/16 02:53:20
DirectXのプログラミングを始めようとおもうのですが
これはSDKのチュートリアルにのってる最新のもの？から勉強していって良いのでしょうか？
それとも以前のバージョンから順に勉強していくほうが良いのでしょうか？
840:デフォルトの名無しさん
09/08/16 02:55:23
>>839
通常はそんなめんどくさいことはする必要はない。
ただしバージョンごとにできることと動かせる環境に差異があるので、
DirectXのバージョンを比較した記事をいくつか読んで、
自分の作りたいものがバージョンいくつがふさわしいか最初に決めること。
後々でバージョンを変更するのはプログラムを作り直すようなことと等しい。
841:デフォルトの名無しさん
09/08/16 02:58:53
directxを更に使いやすくしたライブラリって通称名とかありますか?
また鉄板の物はありますか?
842:デフォルトの名無しさん
09/08/16 03:05:53
>>841
山ほどある。
が、結局DirectX自体と直接格闘したほうが得るものが多い。
お勧めのライブラリはほかのヤツらよろしく。
843:デフォルトの名無しさん
09/08/16 03:07:37
>>842
なるほど、ありがとうございます
ある程度作れるようになったら、改めて探してみることにします
844:839
09/08/16 03:10:57
>>840
なるほど、勉強になりました。
ありがとうございます
845:デフォルトの名無しさん
09/08/16 03:53:38
directx自体を理解してないとライブラリの使い方も理解出来ないからライブラリは無駄ｗ
846:デフォルトの名無しさん
09/08/16 03:57:10
そうそう、面法線を計算して頂点を共有する面頂点の合計を正規化したものを頂点の法線に設定してみたけど
球体の見た目はかなり綺麗に仕上がる
角度で適用するかどうか判別すれば尖った部分も表現出来るんじゃないか
847:デフォルトの名無しさん
09/08/16 07:25:33
>>845
さすがにそれはない。
もしそうならＥａｓｙＬｉｎｋＬｉｂｒａｒｙはあんなに流行らなかった。
848:デフォルトの名無しさん
09/08/16 08:04:06
>>846
モデルデータ制作者の意図のをエスパーのごとく判断するプログラムを作らない限り無理。
だったら普通に法線をデータに含めればいいだけだろ。
いったい何がしたいんだ？
849:デフォルトの名無しさん
09/08/16 08:05:14
大抵のライブラリは自由度を優先しててただのDirectXラッパーで終わってるから意味ないんだよ
例えば視点移動とかエフェクトとかがすべて内包されてて使用者はその中から選ぶだけとか
そこまでやってあるライブラリなら意味があると思うけどないでしょ
仮に誰かが作ったとしても無料では出さないでしょ
850:デフォルトの名無しさん
09/08/16 08:06:43
>>849
それもうライブラリじゃなくてただのツクールだから。
851:デフォルトの名無しさん
09/08/16 08:07:12
>>848
とりあえずただの頂点データだけのメッシュをフォトリアルに表示する方法を模索してる
852:デフォルトの名無しさん
09/08/16 08:09:38
>>851
だからなんで頂点データだけにする必要があるのかを聞いているんだが。
853:デフォルトの名無しさん
09/08/16 08:11:10
>>849
Irrlichtとかがまさにそれじゃないか？
854:デフォルトの名無しさん
09/08/16 08:13:38
>>852
ただのモデルビューアだから、決まったものを表示するわけじゃないので
最終的にはゲームを作りたいけど、とりあえずビューア作って勉強しつつライブラリに包括していってる
ツクールの心臓部分になるかもしれない
855:デフォルトの名無しさん
09/08/16 08:14:47
法線がなかったらライティングしない、
あるならライティングする、が普通のモデルビューアーの挙動だと思うが
856:デフォルトの名無しさん
09/08/16 08:17:19
だから最終目標がツクールレベルだから、法線さえ知らなくても最新ゲーム並みの画像が出せるライブラリを作ってる
自分用にｗ
857:デフォルトの名無しさん
09/08/16 08:22:21
法線なしで最新ゲームなみの画像とはこれはこれは大したもんだ。
デザイナーだったら3秒で投げ捨てろって言うライブラリだな。
858:デフォルトの名無しさん
09/08/16 08:23:54
自動生成した感じでもかなりリアルだけどな
859:デフォルトの名無しさん
09/08/16 08:35:18
エッジの抽出をどうすんだって話じゃねえの
860:デフォルトの名無しさん
09/08/16 09:13:15
モデリングソフトで簡単に出力できるものを、わざわざ利用しない理由の答えになっていない。
カラーで出力できるのに、わざわざモノクロ写真からカラー写真にしろと言っているのが理解できているのか？
861:デフォルトの名無しさん
09/08/16 09:55:00
モノクロ写真をカラーにする技術は重宝されてるし、画像処理では主流の研究課題ですけど
862:デフォルトの名無しさん
09/08/16 10:00:14
頂点法線の取り扱いについて、多少話しが振れてくれれば
得るものもあるが、デザイナとかモデリングソフトとか
得るものが何もない。
>>モデルデータ制作者の意図のをエスパーのごとく判断するプログラムを作らない限り無理。
別にモデルデータ制作者の意図を反映する必要はない。
863:デフォルトの名無しさん
09/08/16 10:35:16
>>861
元のツールがカラーで出力できるんだからそれでいいだろって話してんだろ。
864:デフォルトの名無しさん
09/08/16 10:36:12
>別にモデルデータ制作者の意図を反映する必要はない。
デザイナーに言ったら殴り飛ばされそうなセリフだな
865:デフォルトの名無しさん
09/08/16 10:49:53
何小難しい討論してんだ
正確に描画したいなら法線をつけて出力する。
法線がない時は「とりあえずそれなりに描画する」ってやりたいだけだろ？
別にD3DXにだって、法線の自動生成機能はあるけど、別に批難するやつはいないだろ
866:デフォルトの名無しさん
09/08/16 11:17:19
そもそも法線を自動化することも出来るってだけで法線入れればそっちを優先するだけだがｗ
867:デフォルトの名無しさん
09/08/16 12:48:52
質問です。
DrawTextを使って計算したFPSを表示したいのですが、LPSTR型に変換すると動かなくなります。LPSTR型にうまく変換する方法はありませんか？
868:デフォルトの名無しさん
09/08/16 12:58:51
>>867
逆だ。プログラム全体をLPWSTRで統一するんだ。(Unicodeビルドしてるなら)
オレはそれが嫌になってC++でWindowsプログラム書くのをやめた。
869:デフォルトの名無しさん
09/08/16 13:01:04
なんでこのスレにいるの？
870:デフォルトの名無しさん
09/08/16 15:45:23
ﾋﾄﾘﾃﾞﾓ ｵｵｸ ﾉ ﾜｶﾓﾉ ｦ ﾕﾆｺｰﾄﾞ ﾉ ｼﾞｺﾞｸｶﾗ ｽｸｲﾀｲ
871:デフォルトの名無しさん
09/08/16 15:47:40
時代に取り残された老人は消えるべきだ
872:デフォルトの名無しさん
09/08/16 17:19:28
SJISがデフォルトのOS上でプロジェクト新規作成したらユニコードデフォルトとか嫌がらせ以外の何者でもない
873:デフォルトの名無しさん
09/08/16 17:36:36
時代に取り残された老人は消えるべきだ
874:デフォルトの名無しさん
09/08/16 17:42:06
もはやSJISがデフォルトにはなっていないが、いったいいつの時代の話をしているんだ？
875:デフォルトの名無しさん
09/08/16 18:31:50
今時のOSはユニコードが基本ってばっちゃが言ってたけど
876:デフォルトの名無しさん
09/08/16 19:42:12
最近のOSがどうだろうが関係ねえ。
社内のツールがすべてSJIS前提だから選択肢ねーんだよ。
という会社けっこうあるんじゃない。
877:デフォルトの名無しさん
09/08/16 19:57:32
オープンソースのぜんぶSJISなのにどうすんの
878:デフォルトの名無しさん
09/08/16 20:00:01
ゲームのパラメータファイルとかは、基本SJISだからなぁ
わざわざユニコで書く奴いるか？
879:デフォルトの名無しさん
09/08/16 20:07:20
ツールが吐き出すXMLもUTF8が使われている時代に何を言ってるんだろう？
880:デフォルトの名無しさん
09/08/16 20:18:40
XML厨のプログラマが自己満足で環境を整備しないとSJISでズルズルいくね。
そして、運用する側はタイプ総量とタイプミスが激増して精神病むの。
881:デフォルトの名無しさん
09/08/16 21:18:14
普通XMLはUTF-8で書くだろアホか
882:デフォルトの名無しさん
09/08/16 21:19:58
UTF-8なら何も問題ないんだが、WindowsはUTF-16LEなわけよ。
883:デフォルトの名無しさん
09/08/16 21:28:43
3D空間で人が平面上を動き回れる状態で色々試しています。
人が2m弱として、地面を1000m四方と巨大な板を置いているのですがバンプマップが上手くかかりません。
バンプマップで凹凸を表現するには細分化しないと効果が出ないものなのでしょうか。
テクスチャスクロールだけで地面の上を動いているように見せたかったのに
同じ絵(凹凸)の部分を色んな方向から見ても大して変化せず違和感があります。
884:デフォルトの名無しさん
09/08/16 21:36:59
>>868
unicodeは使ってないです。あと、LPCWSTRじゃ引き算とかが出来なくて困ります。他に解決方法はありませんか？
885:デフォルトの名無しさん
09/08/16 21:42:55
色んな方向から見て変化させるのは、パララックスマッピングとかでは？
バンプマッピングなら、光源の位置と向きを変化させると、見え方が変わると思います。
886:デフォルトの名無しさん
09/08/16 21:43:32
>>884
というか、MBCSとUTF-16は相互に変換するAPIがあるぞ？
引き算の意味するところは分からんが。
887:デフォルトの名無しさん
09/08/16 21:52:26
>>884
fpsをLPSTRに変換するというのは、もしかしてこういうことをやってるとか？
int fps = ..... ;
LPSTR lpstr = (LPSTR) fps;
DrawText( .... );
888:デフォルトの名無しさん
09/08/16 22:13:19
文字コードの変換すら出来ないのはDirectX以前の問題だろ。
基本からやり直せ。
889:デフォルトの名無しさん
09/08/16 22:13:48
>>887
大体そんな感じです。INTのポインタを入れたりしてみましたがダメでした。
漢字とかに変換するのが正解なんですかね？
890:デフォルトの名無しさん
09/08/16 22:18:00
>>889
まずはC言語の入門書から読もうな。
このスレに来るのは３ヶ月くらい早すぎた。
891:デフォルトの名無しさん
09/08/16 22:26:21
>>888
どうか可能か不可能かだけでもご教授を…
892:デフォルトの名無しさん
09/08/16 22:41:28
叶
893:デフォルトの名無しさん
09/08/16 22:41:50
これは酷い
894:デフォルトの名無しさん
09/08/16 23:56:53
木曽がわかってないのに応用問題を解こうとして話を難しくしてる
895:デフォルトの名無しさん
09/08/17 00:02:15
初心者は死ね
それがこのスレの掟だ
896:デフォルトの名無しさん
09/08/17 00:07:01
それはまた、エラいスレのタイトルと矛盾する掟だな。
897:デフォルトの名無しさん
09/08/17 00:09:14
sprintf発見！確かに論外だ。
DIRECTXは続けるので、また詰まった時はお願いします。
898:デフォルトの名無しさん
09/08/17 00:12:04
流石にCの初心者までは扱いきれんだろｗ
899:デフォルトの名無しさん
09/08/17 00:15:49
CがダメならC#を使えばいいじゃない
900:デフォルトの名無しさん
09/08/17 04:04:17
メッシュコンテナ(D3DXMESHCONTAINER 構造体)から面ごとのマテリアル対応情報を取りだそうとしてるんだけど、
pMesh->GetAttributeTable()メソッドで取り出した、属性テーブル(D3DXATTRIBUTERANGE 構造体)の中の「AttribId」ってのは
pMaterials[i]の添え字(i)に対応してるんでしょうか？
同じ属性テーブル内にある「FaceStart」というのも、インデックスバッファ内の面の構成データの格納順に対応してるのか疑問です･･･
901:デフォルトの名無しさん
09/08/17 05:41:26
プロジェクトの設定をマルチバイト文字を使用するに変更すればいいだけじゃない
902:デフォルトの名無しさん
09/08/17 05:44:49
>>900
出なかったからたぶんマテリアルとは関係ない
メッシュをマトリックスグループみたいに分割することが出来てそのインデックス情報を格納するんじゃないかと
でDraw???って関数でそのインデックスを指定するとその面だけが描画されるという
903:デフォルトの名無しさん
09/08/17 05:49:18
ああ、そうか
マテリアルのインデックスを入れといてSetMaterialと連動させて
その面だけを描画すればマテリアルのインデックスという意味にもなるのか
まあ、ただ数字を入れて描画グループを分割出来るだけの代物だよ
904:デフォルトの名無しさん
09/08/17 06:36:53
うーん、pMaterials[i]の添え字(i)と頂点番号(もとい、面番号)を関連付けるデータは
メッシュコンテナ内には無いのでしょうか？
メッシュデータ内の全頂点から、あるマテリアルが適用されている頂点を特定したいのですが･･･
905:904
09/08/17 08:19:54
多分、自己解決
ボーンコンビネーションテーブル(LPD3DXBONECOMBINATION型)に
サブセット番号からメッシュデータ(最適化後)の頂点インデックスまで全て格納されてたので
そちらを参照することにしました
906:デフォルトの名無しさん
09/08/17 12:04:53
URLﾘﾝｸ(marupeke296.com)
このサンプルプログラムを使って
tiny.xを読み込んでも何もアニメーションしないのですが
なぜでしょうか？
ヒントだけでもいいので後生ですから教えてください・・＞＜！
907:デフォルトの名無しさん
09/08/17 12:37:41
DirectXで直線を引くにはどうすれば？(´・ω・｀）
ポリゴンとかXファイルとかは表示できるのに･･･
908:デフォルトの名無しさん
09/08/17 12:50:40
DrawPrimitiveでいけるやないかアホでんねん(´・ω・｀)
909:デフォルトの名無しさん
09/08/17 13:10:51
>>906
公式ならともかく、そこのページは管理人がちゃんと質問掲示板開いてるじゃないか
そっちで質問しる･;(`ε()ﾞ
910:デフォルトの名無しさん
09/08/17 13:41:09
なんなんだ・・・
釣りなのか本気なのか・・・
911:デフォルトの名無しさん
09/08/17 18:35:49
残念ながら、釣りではありません。
912:883
09/08/17 19:09:07
>>885
ありがとうございます。
基本的にはカメラを固定した状態でも動き回るものはバンプ、
それ以外はパララックスという使い方が良さそうですね。
もちろん場合に寄りますけど。
913:デフォルトの名無しさん
09/08/17 20:17:35
>>907
URLﾘﾝｸ(homepage2.nifty.com)
914:デフォルトの名無しさん
09/08/17 21:41:59
現在DirectXを使ってゲームを作っているのですが、
ボタンが後ろに隠れてしまっています。
なので、ボタンがある位置にスプライトを使ってボタン用の画像を
表示しているのですが、時差が出来たりしてうまく機能しません。
どうすれば、ボタンそのものを前面に表示出るのでしょうか？
915:デフォルトの名無しさん
09/08/17 21:45:23
DirectXにボタンなど無い
DirectXにスプライトなど無い
916:デフォルトの名無しさん
09/08/17 22:07:50
「Direct3Dで作っているゲームのキャラと地形のことで質問ですが…」
「Direct3Dにキャラや地形などない」
917:デフォルトの名無しさん
09/08/17 22:09:25
>>915
ボタンはウィンドウズの標準のもので、
スプライトはID3DXSpriteです。
918:デフォルトの名無しさん
09/08/17 22:21:26
ID3DXSpriteを使ってボタンの画像を描画しているのなら、
そもそも標準コントロールを使う必要性がない。
919:デフォルトの名無しさん
09/08/17 22:51:14
>>918
それもそうですね。
DirectXのサンプルに使われているボタンは
標準コントロールを基にしてるのかと思ってましたが
今調べてみたら違いますね。
ご迷惑をおかけしました。
920:デフォルトの名無しさん
09/08/17 22:53:43
まぁ、ツールを作る際にDirectXで描画されたものとWindosのコントロール併用することがあるから
色々試しても無駄にはならないことだけどね。
921:デフォルトの名無しさん
09/08/18 01:52:08
Vistaか７ならどっちでも同じことだが
922:デフォルトの名無しさん
09/08/18 08:20:52
同じじゃねえよ。
どれだけ馬鹿なんだ？
923:デフォルトの名無しさん
09/08/18 08:36:24
D3DXLoadMeshHierarchyFromX
の必要な
LPD3DXALLOCATEHIERARCHY pAlloc,がインターフェイスのポインタと
なっているのですが
ＣＯＭインターフェイスってなんでしょうか？
調べてもプログラムの再利用としか出てこないので全くわかりません。
924:デフォルトの名無しさん
09/08/18 08:42:21
ＣＯＭインターフェイスで検索しろ
925:デフォルトの名無しさん
09/08/18 09:54:49
Direct3D 11.0, Direct3D 10.1/10.0, DXGI 1.0/1.1, Direct2D 1.0, DirectWrite, Windows Imaging Component (WIC) APIs. (DirectWrite and WIC have partial support)
あたりのサンプル実装がMSから出たぞ。
URLﾘﾝｸ(code.msdn.microsoft.com)
926:デフォルトの名無しさん
09/08/18 10:52:08
>>923
そのあたりは、とにかくまずはサンプルコピペして、動きを見て、内容を理解し、自分で改良するしかない。
マジ。
理解しないままゲームとか作ると、あと後絶対苦労するから
927:デフォルトの名無しさん
09/08/18 15:48:21
１０００に近づいてますが、質問させてください。
２Ｄ板ポリゴンの描画についてなのですが、DrawPrimitive系は重いので
1回で複数枚の板を表示するようにしてみました。
D3DXVECTOR4 vPos;
D3DCOLOR color;
D3DXVECTOR2 vTex;
上のようなメンバーを持った頂点オブジェクトの配列Vertexを作り、
for(int i = 0; i < Max; i++){
Vertex[i*4].vTex=D3DXVECTOR2(0.0f, 0.0f);
Vertex[i*4+1].vTex=D3DXVECTOR2(1.0f, 0.0f);
Vertex[i*4+2].vTex=D3DXVECTOR2(0.0, 1.0f);
Vertex[i*4+3].vTex=D3DXVECTOR2(1.0f, 1.0f);
}
とu, vを初期化。そして、描画処理が入った数だけ
Vertex[Cnt*4].vPos = D3DXVECTOR4(left, top, 0.0f, 1.0f);
Vertex[Cnt*4+1].vPos = D3DXVECTOR4(right, top, 0.0f, 1.0f);
Vertex[Cnt*4+2].vPos = D3DXVECTOR4(left, bottom, 0.0f, 1.0f);
Vertex[Cnt*4+3].vPos = D3DXVECTOR4(right, bottom, 0.0f, 1.0f);
※color省略
Cnt++;
とし、SetTextureして
DrawPrimitiveUP(D3DPT_TRIANGLESTRIP, Cnt*2, Vertex, sizeof(VERTEX);
としたらテクスチャがあらぬ方向に伸びました。何故か正しく表示できてるものもあるのですが･･･。
どこか根本的に勘違いしてるのでしょうか？ご指摘いただけませんか・・・。
928:デフォルトの名無しさん
09/08/18 15:51:04
TRIANGLESTRIPがどういうものか調べてくるといい
929:デフォルトの名無しさん
09/08/18 15:56:02
>>928
さっそくのご指摘ありがとうございます。
全部プリミティブが繋がってると言うことでしょうか？
他の部分は問題ないものとしてTRIANGLELISTで実装してみます。
930:デフォルトの名無しさん
09/08/18 16:36:00
>>928
TRIANGLELISTでできました！1枚の板に６つ頂点使ってますが、
ちゃんとu,vと対応させたらＯＫでした。後は頂点インデックス使ったほうがいいですかね。
どれくらいパフォーンマンスに影響するかはわかりませんが。ともあれ即レス感謝です！
931:デフォルトの名無しさん
09/08/18 16:42:06
>>930
すぐに非効率性に気づいてTRIANGLELIST+IndexBufferに移行するだろうがな。
932:デフォルトの名無しさん
09/08/19 00:54:18
解決したんじゃなくて先送りしただけという事に気づくんだｗ
933:デフォルトの名無しさん
09/08/19 06:23:18
D3DXMATRIX mat;
D3DXVECTOR3 vec;
パターン1:
lpdevice->SetTransform( D3DTS_WORLD, &mat );
→vec(頂点)をDrawPrimitivで描画
パターン2:
vec = vec * mat;
→vec(頂点)をDrawPrimitivで描画(SetTransformしない)
この２つは同じ結果になると思ってたんですが、どうやら違うらしいです。
SetTransformをせず、パターン1と同じ結果を得るためにはどうすればいいのでしょう？
934:933
09/08/19 07:24:03
計算ミスってました(ﾉ∀｀)
ｻｰｾﾝ orz
935:デフォルトの名無しさん
09/08/19 10:33:40
>>933
SetTransformしないってのは、座標変換しないって意味じゃないぞ。
初期値として単位行列が設定されているから、起動時から一度も設定してなければ
結果的に入力と出力が同じ座標になるが。
何もセットしなけいと別の場所でSetTransformした値が残っているので、
明示的に単位行列をセットすべき。
936:デフォルトの名無しさん
09/08/19 14:55:22
ガラスのコップみたいな透明な物体を描画するには、
テクスチャーを透過するだけでいいんだな
937:デフォルトの名無しさん
09/08/19 15:10:03
>>966
DeffUseのαを設定する形にすれば透過率を後から変更できるけどな。
いずれにせよ描画順に制約を受けるので注意。
938:デフォルトの名無しさん
09/08/19 15:46:26
グラスの表現は透過率の調整だけじゃ出来ねえよ
プログラム以前に最低限のモデリングを経験してからにしろ。
939:デフォルトの名無しさん
09/08/19 17:22:15
>>937
deffuseのアルファ値か、ありがとう！
>>938
屈折の話とかかな？
ヒントサンクス！
940:デフォルトの名無しさん
09/08/19 20:09:42
マウスの左ボタンを押しているときにprintfDx関数で"Hello Ｃ World!\n"と出力し、
押してないときはclsDx関数で消すというコードを書いたつもりなのですがうまく消えてくれません。
どうしてでしょうか?初歩的な質問ですいませんが、よろしくおねがいします。
#include "DxLib.h"
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow ){
ChangeWindowMode(TRUE);//ウィンドウモード
if(DxLib_Init() == -1 || SetDrawScreen( DX_SCREEN_BACK )!=0) return -1;//初期化と裏画面化
char Key[256];
//ループ開始
while(ProcessMessage()==0 && ClearDrawScreen()==0 && !GetHitKeyStateAll( Key )){
//↑ﾒｯｾｰｼﾞ処理 ↑画面をｸﾘｱ
//ココ↓
if( ( GetMouseInput() & MOUSE_INPUT_LEFT ) != 0 )
{ // 押されている
printfDx( "Hello Ｃ World!\n" ) ;
}
else // 押されていない
{
int clsDx( void );
}
//ココ↑
ScreenFlip();
}
DxLib_End();
return 0;
}
941:デフォルトの名無しさん
09/08/19 20:18:12
>>940
ここはDirectXのスレです。
942:デフォルトの名無しさん
09/08/19 20:21:55
>>941
スレ違いでしたか、すいませんでした
943:デフォルトの名無しさん
09/08/20 17:55:06
DirectX9とc++でゲームを作っているのだが、ゲーム会社に就職する
には、どれくらいの技術が必要ですか？
よく聞く基準
ライブラリを作れるとか
簡単な３Ｄゲームが必要とか
２Ｄだったら、完成度が高くないといけない
だいたいでいいから基準みたいなものはありますか？
944:デフォルトの名無しさん
09/08/20 17:57:57
ゲーム1本作れればおｋよ
945:デフォルトの名無しさん
09/08/20 19:03:07
人事担当じゃないから詳しいことは分からないけど、DirectXでゲームとして完成度の高いものを作っても意味ないよ。
一番は表現力。HLSLでSDKのサンプル以上の何かを出来ればそれだけで十分だったりも。
小規模な企業ならそれでいいけど、中規模以上の企業であれば数学・物理が人に教えることが出来るレベルじゃないとダメ。
ハードが変わっても求めたい答えとその計算方法が分かっていれば問題ないしね。
ちなみにバンナムは数学・物理中心で、簡単なC言語ソースの問題(穴埋め)。
任天堂は数学・物理中心、あとは一般常識と発想力。
大企業になると技術力をアピールする機会がなかったり、それ以前に蹴落とされるから注意してね。
まぁ、場違いな書き込みなんですけど。
946:デフォルトの名無しさん
09/08/20 19:38:01
板違いな奴は入れないお
レスする方もたいがいだけどな
947:デフォルトの名無しさん
09/08/20 19:45:42
ゲームとして完成度の高いもの(笑)
948:デフォルトの名無しさん
09/08/20 21:04:59
そもそもここは進路相談のスレじゃない
949:デフォルトの名無しさん
09/08/21 00:03:24
>>947
面白いゲーム作れなくて、数学物理が出来ても仕方ないと思うけどな。
単なる技術のデモンストレーションみたいなゲームは嫌だろ。
ゲームとしての捻りが無ければ売れんだろうし。
ま、だからって数学物理がいらないとは言わないが。
950:デフォルトの名無しさん
09/08/21 00:09:04
>>949
そういう人ばかりいたら駄目だろうが、当然面白いゲームを作るための人というのもまた別に雇用するだろう。
951:デフォルトの名無しさん
09/08/21 00:23:24
ゲームが面白いかどうかなんて、グラフィックや企画、仕様による所が大きいだろーが
つーか、ここはプログラマ板だろ
プログラマ(だぶん一人)が作った、転職、就職用ゲームが面白いかどうか、
なんて言ってるのは、ロートルの分って無いオッサンにしか見えん
挙動とかタイミングなんて言うなよ？
それこそ、そのサンプルプログラムで言い訳だろ
つまり、数学物理とは言わないが
技術スキルが分るサンプルやデモで十分
採用に面白い完成したゲームとか言ってる奴は、マジで組織のお荷物ぽっい
いい年して技術が無く、技術的な問題可決もトンチレベルの発想で
結局、若い技術ある奴が残業や休日出勤でカバーとか、ねｗ
952:デフォルトの名無しさん
09/08/21 00:26:00
ゲームってこれからも
どんどんどんどんどんどん
難しくなってくのかな？
昔はフォトンマップとか非線形計画問題とか考えなくても
ゲーム作れたのに。
うざい、皆死ねばいいのに。
953:デフォルトの名無しさん
09/08/21 00:36:28
うんうん、板もわきまえずに語りだす奴は皆氏ねばいいね
954:デフォルトの名無しさん
09/08/21 02:14:38
ツールが増えてるからむしろ簡単になってるんじゃない？
955:デフォルトの名無しさん
09/08/21 03:28:34
Physixスレがないのだがここでいいのかな