DirectX総合スレ (Part5)

**名前は開発中のものです。** · 2006/09/08(金) 23:56:42

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

**名前は開発中のものです。** · 2006/10/21(土) 01:05:12

間違えましたorz
× D3DFMT_A16B16G16R16
○ D3DFMT_A16B16G16R16F

**名前は開発中のものです。** · 2006/10/21(土) 01:12:03

レンダリングは出来るんじゃない？
もっとも意味があるとは思えんが。

**名前は開発中のものです。** · 2006/10/21(土) 01:12:46

>>748
浮動小数点バッファもそもそもフィルタとアルファが使えない。

**名前は開発中のものです。** · 2006/10/21(土) 01:35:28

>>748
HDRレンダリングするんだったらピクセルシェーダ使うだろ？
だったら問題なしだ。自分で実装したまえ。

**名前は開発中のものです。** · 2006/10/21(土) 01:36:21

じゃもうおとなしく描画を全てHLSLとかに移行した方がいいですね．
スプライト関係のルーチンを書き換えてきます……('A`;)

**名前は開発中のものです。** · 2006/10/21(土) 01:40:02

待て待て。
D3DFMT_A16B16G16R16F を使わない、って選択肢はないのか？

そもそも、何のために使おうとしてるんだ？？

**名前は開発中のものです。** · 2006/10/21(土) 01:53:02

具体的にはトーン調整とかブルームとかが使いたくて．

あとHDR対応だと，いろいろ表現力が広がるみたいだし，
後々のことを考えると，今のうちに使えるようにしておいた方がいいかなと．

**名前は開発中のものです。** · 2006/10/21(土) 02:05:17

現時点でHLSLベースで作ってない上にスプライトとか使ってる状態では
FLOATバッファ使ったHDRレンダリングは早いと思うよ。

やりたいトーン調整やブルームは、擬似的に再現した方が絶対に楽。

**名前は開発中のものです。** · 2006/10/21(土) 02:21:36

てかスプライトにHDRなんていらんだろ

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

あうあう．
現在自分のライブラリは3年間改造・増築を繰り返した結果，
モデルの描画がHLSL，2D・3Dスプライト(ビルボード？)が固定機能とばらばらになっていて，
おまけにライトの管理とかビューポートの管理とか，機能を細分化しすぎて，
作った本人にも詳細構造が意味不明な状態になっているので，
とりあえず固定機能の消去とかの機構削減・統合に関しては積極的に行いたいのでつ．

自分もスプライト関係は大昔に書いたコード＆機能追加しすぎて超長いので触りたくないのですが……．

**名前は開発中のものです。** · 2006/10/21(土) 02:53:50

確かに長く書くのは億劫だよねー
答えてもらう側の苦労は自分が苦労するわけじゃないからどうでもいいよねー

**名前は開発中のものです。** · 2006/10/21(土) 02:54:07

3年間も使い続けてるのはｴﾗいと思う反面、古いプログラムにしがみ付きすぎだとも思う。

HLSLに対応した時点でｽﾌﾟﾗｲﾄ関連をまとめるべきだったね。
それは、今からでも全然遅くない。作り直すべき。

**名前は開発中のものです。** · 2006/10/21(土) 03:04:52

3年も弄ってるって事は仕事で使ってるとか、ネット上で公開してるとかそういう類かしら

**名前は開発中のものです。** · 2006/10/21(土) 03:12:17

>>759
ﾑｷｰ（#｀皿´）
書き込み内容が長いと言われるのを恐れただけです．(´･ω･`)

>>760
そうそう，そう思っていま大改装中なのです．
その一環でHDRにも対応させようぜ，と．

>>761
いえ，すごく自分用です．
そのうちネット公開できればいいなとも

**名前は開発中のものです。** · 2006/10/21(土) 03:18:21

>>762
良いｷｬﾗしてるねー面倒みたくなるよ（ ´∀｀）

HDR対応にするなら、現状ではスプライト処理を廃止（ポリゴンに移行）するか、
簡単なところではスプライトはHDRレンダリング対象外ってことにするとか。

トーンマップ後のバッファに描いたらいいじゃん的な。

**名前は開発中のものです。** · 2006/10/21(土) 04:25:01

割り込んでごめんなさいです

ずっと前から疑問なんですが
デバイスにFVFを設定するのとVERTEXDECLARATIONを設定するのとでは
どういう違いがあってどういう意味があるんでしょうか

**名前は開発中のものです。** · 2006/10/21(土) 04:47:59

VERTEXDECLARATIONの方がもっと柔軟なフォーマットを指定できる。
それだけ。

**名前は開発中のものです。** · 2006/10/21(土) 04:52:13

ありがとうございました

うっ

**名前は開発中のものです。** · 2006/10/21(土) 18:54:08

>>746
釣りじゃないです＞＜
わからないんです＞＜
違いは、
・Lock/Unlockできるぐらいしかわからん

描画制限があるとか
演算をハードに任せるとかあるんですか？

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

ああ、DrawIndexPrimitiveじゃなくDrawIndexPrimitiveUpだ

うｐ系ってウンコ？

**名前は開発中のものです。** · 2006/10/21(土) 19:03:43

君がウンコな気がする・・・
初心者スレじゃないんだしリファレンスくらい読もうぜ。

**名前は開発中のものです。** · 2006/10/21(土) 19:08:21

--------------------------------------------------------------------------------
IDirect3DDevice9::DrawPrimitive メソッド
現在のデータ入力ストリームセットから、指定されたタイプのインデックスなしジオメトリプリミティブのシーケンスをレンダリングします。

--------------------------------------------------------------------------------
IDirect3DDevice9::DrawPrimitiveUP メソッド
ユーザーメモリポインタで指定されたデータを、指定されたタイプのジオメトリプリミティブのシーケンスとしてレンダリングします。

IDirect3DDevice9::DrawPrimitiveUP に渡す頂点データは、呼び出しの後も保持する必要はありません。
Microsoft Direct3D は、呼び出しから戻る前に、そのデータへのアクセスを完了します。

**名前は開発中のものです。** · 2006/10/21(土) 19:17:21

ツンデレを垣間見た
ｻﾝｸｽ

>呼び出しから戻る前に、そのデータへのアクセスを完了します。
つまり、Up系は、ユーザメモリをVRAMに完全にコピーしてから処理を返すから、ちょっと反応が遅いってわけなのか

ttp://twin-tail.jp/contents/vsdx8/d3d/020/index.htm
2Dは、うｐれと

ぬああ
よくわからん
じっくりマニュアル読んでくる

**名前は開発中のものです。** · 2006/10/21(土) 20:13:47

2DだとDrawPrimitiveもDrawPrimitiveUPも
大して変わらないとか聞いたような

**名前は開発中のものです。** · 2006/10/21(土) 20:27:22

> Direct3DDevice9::DrawPrimitiveUP に渡す頂点データは、呼び出しの後も保持する必要はありません。
> Microsoft Direct3D は、呼び出しから戻る前に、そのデータへのアクセスを完了します。
ようするにDrawPrimitive呼ぶ度に内部で頂点バッファにコピーしてるって事だ。

２D/3Dのスプライトのような頻繁に書き換えるものならD3DPOOL_DEFAULTにD3DUSAGE_DYNAMICとD3DUSAGE_WRITEONLYをつけて頂点バッファを作れ。
そうするとAGPメモリに展開されてVRAMデータと同じ速度でレンダリングが行われつつシステムメモリと同じ速度で書き込みできる。

ロック時にD3DLOCK_DISCARDを指定すると、ドライバ内で自動的に新しいバッファを返してくるので、
更新＞描画＞更新＞描画とやっても頂点バッファロック時に描画待ちとか発生せずにアクセスできる。

**名前は開発中のものです。** · 2006/10/21(土) 21:52:37

ぶっちゃけ２Ｄの頂点数なんてあんまり関係無いと思うよ。
なにでやってもそんなに速度に差なんてでないと予想。

２Ｄなんか
「お前、それで３Ｄモデル作れるぐらいだすつもりなのかと？
何言ってるのか？わかるか？
普通の３Ｄゲームで３Ｄモデルのポリ数をワンフレームをこさえたとしても
問題ない速度がでるのに、たかだか２Ｄゲームで何糞みたいなこと気にしてるのかと？」
問い詰めたくなる。

これが３Ｄゲームの２Ｄ部分だったとしても２Ｄのポリ数なんぞ
ほとんど影響でないと予想。
ピクセルフィルレートならわかるけどね。

**名前は開発中のものです。** · 2006/10/21(土) 22:53:28

２Dでも各種爆発やエフェクト系のテクスチャを1枚にまとめて、
１，２回程度のDrawPrimitiveで処理するときは数千頂点とかにはなるぞ。

まぁ変換済み頂点だからそもそもバーテックスシェーダーは経由しないけど。

あとDirectX8世代だとUP系の関数は描画完了までブロックしてたってのがある。
DirectX9で内部にバッファ作ってコピーするようになったとかならんかったとか。

まぁ今のDirectXで一番重いのはDrawPrimitive系の関数のコールだから
可能な限りDrawPrimitiveの数は減らせるように作っておいた方がいい。

**名前は開発中のものです。** · 2006/10/21(土) 23:16:50

また知ったかを。
DrawPrimitiveは処理リストに詰めているだけで、実際にそこで処理をされるわけでは無い。
一番重くなるのはPresentをした時。

**名前は開発中のものです。** · 2006/10/21(土) 23:22:46

少なくともUP系は結構重いぞ。
確かにDrawPrimitiveはGPUコマンドを作成するだけだが、
Presentをしないという選択肢はありえないんだから
DirectDrawのBltみたいな気軽さでDrawPrimitive系の呼び出しは
やるもんじゃないだろ。

**名前は開発中のものです。** · 2006/10/21(土) 23:24:21

いちいち後出しで恥の上塗りなんかしなくていいよ、みっともない。

**名前は開発中のものです。** · 2006/10/21(土) 23:38:33

DrawPrimitive佐賀

**名前は開発中のものです。** · 2006/10/21(土) 23:46:13

一番重いのは俺の体重

**名前は開発中のものです。** · 2006/10/21(土) 23:48:22

知ったかはID:NV8Lshdxの方だと思う（俺はID:h4fJ9Plfではないが）

少なくともバッチ数によるCPU負荷のコストが尋常でないのは周知の事実だし、
commandBuffer（pushBuffer）のkick開始がPresentのタイミングと決まっているわけではない
(というか、一般的なドライバでは描画コールの度にkickは発生している)。
そもそも負荷のタイミングがどうこういう話ではなく、バッチにはコスト掛かるよってだけの話だし
見当違いも甚だしい

あと、反論があるなら>>778みたいな間抜けな勝利宣言ではない方法がお勧め

**名前は開発中のものです。** · 2006/10/22(日) 00:13:37

>一番重くなるのはPresentをした時
Presentコールしてから描画してるような言い方は止めてくれ

**名前は開発中のものです。** · 2006/10/22(日) 00:47:09

あー、うぜ。
なんか意地になってどうしなきゃならない的なこという奴いるけど
DrawPrimitiveのコストなんて気にしないほうがいい。

これはDrawPrimitiveのコストがどうのこうのって問題じゃなくて、
まず、「仕様」ありきでしょ？って話。
で、作ってきゃわかるけど、ホントに描画が重くなってるときってこの辺最適化したって
重い動作が快適に変わることってほとんどない。

ぶっちゃけＸファイルのポリゴンのオプティマイズ関数ぐらい無駄。
テスト環境だと数字だけ上がって華やかに見えるけど、実際のゲームだとデザイナの作る物が分かれすぎてて
最適化なんてほとんどきかねーから。
これは凝ってるモデルほど最適化が効かなくのはもはや宿命。
で、快適に動くシーンってのは誰がどんな描画方法でやったって大抵はいい速度で動いちまうもんだ。
変なことしないで普通にやりやすい方法で描画しろ。

**名前は開発中のものです。** · 2006/10/22(日) 00:50:25

>>773
＞そうするとAGPメモリに展開されてVRAMデータと同じ速度でレンダリングが行われつつシステムメモリと同じ速度で書き込みできる。
大嘘もいい加減にしろ。
AGPメモリはメインメモリをビデオカード側から見えるようにマッピングするだけで、VRAMと同じ速度なんて持っていない。
ビデオカード側で頂点処理が出来るだけで、データはバスを超えて取りに行かなければならない。
頻繁に書き替えると言っても、その頻度が毎フレームとかいう状態でない限り、逆に遅くなる可能性すらある。

いつからAGPメモリがVRAMと同じ速度を持つようになったんだ？

**名前は開発中のものです。** · 2006/10/22(日) 01:09:37

>>783
DrawPrimitiveのコールで足ひっぱりのはGPUじゃなくてCPUなんだが・・・
基本的にGPUで足をひっぱるのはピクセルシェーダーだしな。

>>784
毎フレームデータ更新しないポイントスプライトがあるのかと・・・
何のためのD3DUSAGE_WRITEONLYなのかと。

実際のどこのメモリに配置されるからは完全にドライバ依存だし、
システムへの下りがない前提ならDMAでシステム＞VRAMだけですむ様にも最適化されるだろ。

**名前は開発中のものです。** · 2006/10/22(日) 01:25:06

>>776
最近のビデオカードだと、Presentですらブロックは発生しないよ。
Presentもキューに入れるだけ。
そのせいで描画に遅延が発生するという別の問題が発生している。

アクション性の高いゲームだと、その遅延が問題になるから
わざわざブロックが発生するようにLock入れたりしている。
(その方法はMSは推奨していないが)

**名前は開発中のものです。** · 2006/10/22(日) 01:38:56

データがおかしいと
GeForceが表示しなくて
RADEONが無理やり実行するって聞いた。

だいたいあってる？

**名前は開発中のものです。** · 2006/10/22(日) 02:40:09

>>777
>確かにDrawPrimitiveはGPUコマンドを作成するだけだが、
>Presentをしないという選択肢はありえないんだから

バックバッファではなくテクスチャに描画するときはDrawPrimitiveの後でPresentしないで良いんじゃない？

**名前は開発中のものです。** · 2006/10/22(日) 04:40:10

ハードウェア的に浮動小数点のHDRレンダリングターゲットに対する
アルファブレンディングがサポートされていない環境で，
ps_2_0くらいまでのHLSLでHDRへのアルファブレンドを実現する方法はないでしょうか？

HLSLでHDRのアルファブレンディングを実装するために，
ピクセルシェーダでソースカラーとレンダリングターゲットのピクセルカラーを混ぜる方法をとろうとしたのですが，
描画先のピクセル座標はps_3_0で無いと取得できないようで……．
ちょっとps_3_0は今の時期のゲームに使うのは環境的に難しそうなので，他の方法がほしいのですが．
(おまけに自分のグラボでは古くて動いてくれない('A`；；エフェクトエディタではSuccessになったのですが)

>>763
爆発エフェクトとかに対してごちゃごちゃやってみたいので，
なんとか3Dスプライト?も使いたいのです．

**名前は開発中のものです。** · 2006/10/22(日) 04:56:12

>>789
頑張ってますね～

HDRバッファもテクスチャとしてHLSLに渡したら参照可能かな？

**名前は開発中のものです。** · 2006/10/22(日) 05:21:33

>>790
自分もその方法でやってみたんですけど最終的にカラー合成するとき，
HDRターゲットテクスチャ側のピクセルカラーを取ってくるのにtex2D()を使ったのですが，
座標指定が必要になるので，ピクセルシェーダの入力にVPOSを入れたのですが，
このVPOSというセマンティックはps_3_0以降でないとサポートされないようなのです．

**名前は開発中のものです。** · 2006/10/22(日) 07:31:43

>>791
普通にテクスチャ座標で指定するだけでは？
Direct3D使って2Dエフェクト実装したことないの？

**名前は開発中のものです。** · 2006/10/22(日) 08:32:51

>>788
いやいや、結局その後どこかでPresent()はするわけじゃん。

>>789
１．HDRーRT
　　モデルなどをHDRでレンダリング

２．トーンマップなどのHDR処理

３．HDR-RTからLDR-RTへのフォーマット変換転送
　　　StretchRect()

４．半透明を使用したエフェクト描画＆２D描画

５．LDR-RTからバックバッファへのフォーマット変換転送
　　　StretchRec t()

６．Present（）

ようはHDR-RTだけで処理を関係させようと思わなければいい。
パーティクル関係がHDR処理をされる必要はないんだし。

**名前は開発中のものです。** · 2006/10/22(日) 08:47:57

>>793
Presentを一切実行しないDirect3Dプログラムというのも有り得る。
EndSceneの間違いなら分かるが。

**名前は開発中のものです。** · 2006/10/22(日) 09:01:21

あぁそうか画面に描画しねーならPresentはいらねーな。
そもそもDrawPrimitiveしないならBegin-Endもいらんか。

>>776ので勘違いしてた。
Present()が重いのは基本的にそこで全描画を待つからであって、
別にPresent()でkickしてるからではないって話だったな。

まぁこのへんも全部ドライバ依存だから一律決まってるわけでもないが・・・。

**名前は開発中のものです。** · 2006/10/22(日) 09:37:22

>>792
HLSLは正直あんまり使ったことないです．(´･ω･`)
どういう風に実装するものなんでしょ？

>>793
ふむむ，やっぱりエフェクト類は分離させた方が早いですか．
とりあえず動く状態にしたいのでそれでいってみます．

**名前は開発中のものです。** · 2006/10/22(日) 12:54:52

>>791
描画座標をテクスチャ座標に変換してピクセルシェーダに渡すだけだよー
（テクスチャサイズか変換マトリクスをHLSLに渡す必要がある）
頂点シェーダの入力はテクスチャ座標１つでも、ピクセルシェーダは２つとか可能だからね。

基本的に、頂点シェーダが持つ特殊なデータを渡したい時はテクスチャ座標を使います。

**名前は開発中のものです。** · 2006/10/22(日) 13:11:03

> ２．トーンマップなどのHDR処理
> ３．HDR-RTからLDR-RTへのフォーマット変換転送
> 　　　StretchRect()

トーンマップってHDR→LDRを含むよね。

っつーか、その案はすでに出してるんだけど。

**名前は開発中のものです。** · 2006/10/22(日) 13:40:07

GPGPUなんかはPresentしないね。

**名前は開発中のものです。** · 2006/10/22(日) 13:54:46

ID:NV8Lshdxの再登場はまだ？
それとも既にいるなら名乗ってくれよー

**名前は開発中のものです。** · 2006/10/22(日) 13:57:03

AfterEffectﾓﾄﾞｷのエフェクトアニメーション作成ツールを作ったときもPresentは使わなかった。
バックバッファをD3DXSaveSurfaceToFileで取り出してAVIにエクスポートするだけだったんで。

**名前は開発中のものです。** · 2006/10/22(日) 14:09:11

>>801
つまりPresentが要らない分、超爆速ってことだね!
なんてったって「一番重たくなる」Presentが要らないんだもんね!

という戯言はともかくとして
処理は別スレッドで行って、なんか適当に「エクスポート中です」とかアニメーションさせた
画面出しておいた方がツール使う人の不安ちょっと解消されるかもね
使う人がプログラマだったらそんなんむしろ邪魔だろうけどデザイナプランナが使うんならって話ね

**名前は開発中のものです。** · 2006/10/22(日) 19:57:45

>>802
801のツールが何も画面に表示してないとは書いてないし、
その表示にPresentいらないし。GDIで十分。

**名前は開発中のものです。** · 2006/10/22(日) 22:07:46

GDIは、3Dやってくれん

**名前は開発中のものです。** · 2006/10/23(月) 00:01:56

3Dは別に必要ないんじゃないかと思うが

**名前は開発中のものです。** · 2006/10/23(月) 13:14:35

GDIだと
いろんなブレンドが面倒だろ

**名前は開発中のものです。** · 2006/10/23(月) 13:55:20

そこでMMXが満を持して登場

**名前は開発中のものです。** · 2006/10/23(月) 14:03:27

5年ぐらい前のコードをまた書けと

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

802の言う程度の描画ならGDIで十分、という話だと思う。
で、Presentはいらない場合もあるね、ってことだろう。
もはやなんの話だったかおぼえてないけど。

**名前は開発中のものです。** · 2006/10/23(月) 14:24:28

Presentが一番処理が重いんだ！とおっしゃった方が発端かと。

**名前は開発中のものです。** · 2006/10/23(月) 16:24:59

普通に時間計ったらPresentが一番重くなるんじゃないの？描画待ちで。

それを、Present使わない稀な例を挙げて騒いでるのはなんで？？

**名前は開発中のものです。** · 2006/10/23(月) 17:15:55

>>811
最初にPresentが重いといった人がどういう意図でいったのか分からんが、
描画待ちをしてるからではなく、状況に依存せずに重いと言ったんじゃなかろうか。

そもそも描画が完了してる状況ならさして重くないんだし。

**名前は開発中のものです。** · 2006/10/23(月) 17:28:47

Presentの前に通常処理をすればいいじゃない

**名前は開発中のものです。** · 2006/10/23(月) 17:54:32

佐賀

**名前は開発中のものです。** · 2006/10/23(月) 19:25:37

>>811
ほっとけ。
相手にしてもしょうがない。

**名前は開発中のものです。** · 2006/10/23(月) 19:37:27

誰か
GeForceとRADEONの違いについて語って

**名前は開発中のものです。** · 2006/10/23(月) 21:30:48

>>811
お前さんはとんでもない勘違いをしている。
Presentをしないプログラムも有り得るという話は、Presentが
重いという話の流れではなく>>777に対するレス。

**名前は開発中のものです。** · 2006/10/23(月) 22:21:08

>>777 はある程度内部処理を想像できてるから、
UP系と非UP系＋Presentとを比較した発言をしてるよね？

それに対して「Presentしない例もある」って言ってる人は
話の根本を理解してない上に、内部処理を理解してない人まで混じってる。

「Presentしないこともあるけどね」程度で終わればいいが
そっちの話にばかり移ってるのがおかしいんだよ。

**名前は開発中のものです。** · 2006/10/23(月) 23:31:10

んじゃそろそろクリスマスPresemtでも考えようぜ。
俺はゲームボーイアドバンス

**名前は開発中のものです。** · 2006/10/23(月) 23:48:22

やっべ驚くほどつまんない人が現れた

**名前は開発中のものです。** · 2006/10/24(火) 00:39:22

>>819 勇んでボケたのに咬んだね・・・＞ｽﾍﾟﾙﾐｽ

**名前は開発中のものです。** · 2006/10/24(火) 00:44:01

>>818
話の本筋が一段落したところで
脇道にそれてわいわいやってただけなので
文脈読んでください。
おかしいのはお前の会話能力です。

**名前は開発中のものです。** · 2006/10/24(火) 01:01:12

>>822 天才発見ｗ

**名前は開発中のものです。** · 2006/10/24(火) 01:19:20

わいわいやってたんだ・・・

**名前は開発中のものです。** · 2006/10/24(火) 02:59:13

Presentが一番重たい人に比べたら
誰だって天才だよｗ

**名前は開発中のものです。** · 2006/10/24(火) 14:20:05

P
r
e
s
e
n
t

**名前は開発中のものです。** · 2006/10/24(火) 19:59:24

pre-sentをそのまま訳したら「先送り」になってしまうな…

**名前は開発中のものです。** · 2006/10/25(水) 02:10:07

>>825 ﾊﾞｶがおるｗ

**名前は開発中のものです。** · 2006/10/25(水) 02:57:23

presentが一番重たい人キター！

**名前は開発中のものです。** · 2006/10/25(水) 04:08:53

今モーションの補間をやろうとしています。
キーフレームには各ボーンに対応するクオータニオンが設定されていて、そのキーフレーム
間のクオータニオン同士をなめらかに補間しようと考えています。
とりあえずD3DXQuaternionSquadSetupとD3DXQuaternionSquadを使って補間してみたの
ですが、この問題
http://bbx.hp.infoseek.co.jp/cgi-bin/bbx.cgi?log=40&vew=58
と同じ問題が出て困っています。このスレッドではGemsのサンプルを使うと良い、といった
事が書かれていますが、Gemsの方はGemsの方で、クオータニオンを360度一回転させると
おかしくなる等問題があります。
クオータニオンをD3DXVECTOR4にキャストしてCatmullRomで補間してみたりもしたのですが、
やっぱり一回転できない等問題が出てしまいます。

クオータニオン同士を滑らかに補間したい時は普通どうやるんでしょうか。
あんまりキーフレーム同士の角度が離れすぎないようにしてD3DXQuaternionSquadで補間する
しか無いんでしょうか？
それなりに滑らかに見えればOKで、あんまり厳密さとかは求めてないんですが・・・。

**名前は開発中のものです。** · 2006/10/25(水) 12:15:51

>>830
反転なしのslerpでsquadを実装、でだめなの？
その360度一回転ってのがよくわからないんだけど、まさか一区間で
一回転じゃないわよね。とりあえず例が無いとわからないわ。

**名前は開発中のものです。** · 2006/10/25(水) 12:47:20

「妹と月イチでＨなことしてる♪」と女子高生タレントがblogで発言→炎上中　★2
http://news20.2ch.net/test/read.cgi/news/1161654591/

**名前は開発中のものです。** · 2006/10/25(水) 13:37:44

>>831
ギャー！全然関係無いうっかりミスが原因でした。
仰る通り、反転無しのslerpで正しく動きます。
上の質問は忘れてください、お騒がせしました。

**名前は開発中のものです。** · 2006/10/27(金) 17:51:49

PCで
３D技術使いまくり系で
めがっさキレイなゲームって何があります？

**名前は開発中のものです。** · 2006/10/27(金) 18:54:51

おれのゲーム

**名前は開発中のものです。** · 2006/10/27(金) 19:35:30

うｐ

**名前は開発中のものです。** · 2006/10/28(土) 00:40:05

DirectXSDKを最新版にしたい場合、旧バージョンアンインストール→新盤DL＆インストールって手順でOK？

**名前は開発中のものです。** · 2006/10/28(土) 02:52:28

>>834
今なら間違いなくCrysis
ttp://www.xasis-game.com/title/crysis/movie.shtml

既に発売してるものならProject Gotham Racing 3

**名前は開発中のものです。** · 2006/10/28(土) 13:18:04

>>837
新版DL→旧バージョンアンインストール→インストールの方がたぶんｲｶす

**名前は開発中のものです。** · 2006/10/29(日) 21:53:43

遅レスで申し訳ないんだけど、結局、頂点をCPU側で動的に書き換える場合、
DrawPrimitive、DrawPrimitiveUP、DrawIndexedPrimitive、DrawIndexedPrimitiveUP
のどれを、どう使うのが一般的なの？

kickとかよくわからない素人なのですが、識者の方、どうかまとめてくれないでしょうか

**名前は開発中のものです。** · 2006/10/29(日) 22:38:31

>>840
てめぇで考えろよ。
正解なんてねぇよ。

**名前は開発中のものです。** · 2006/10/29(日) 23:20:08

>>843
あ？けんかう

**名前は開発中のものです。** · 2006/10/29(日) 23:27:52

>>842
けんかう。

**名前は開発中のものです。** · 2006/10/29(日) 23:45:05

(´･ω･`)<人に関数決めてもらわなきゃ描画も出来ネェ糞餓鬼がなめてんじゃねぇぞ！ｶｶｯﾃｺｲﾖ！ｵﾗ！

**名前は開発中のものです。** · 2006/10/29(日) 23:54:45

>>840
時と場合による。
どのような時に何がもっとも有効かはリファレンスを熟読しましょう。
その後の検証も忘れずにな。

**名前は開発中のものです。** · 2006/10/30(月) 00:35:12

俺は、本当は誰もそんなパターンなんて出来てないし誰も理解も出来てない、と思うんだ

>どのような時に何がもっとも有効か
なんてリファレンスを見るまでもなく、そのパターンが少しは出てくるはずだが、1つも出てこないから

**名前は開発中のものです。** · 2006/10/30(月) 01:21:58

そうか？
少なくとも俺の今のプログラムの中ではUP系関数を使う箇所はない。
DrawPrimitive系どうこうよりも、頂点バッファの作り方と使い方のほうが重要だし。

**名前は開発中のものです。** · 2006/10/30(月) 02:28:31

みんな頂点ストリーム使ってないのか？
UPだと０番しか使えないぞ。

０で座標、１でＵＶ、２で法線、３で・・・

って使うと汎用的に使えて便利だぞ。
UPだとこういうもの作るのに向いてない。