DirectX総合スレ (Part5)

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

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

**名前は開発中のものです。** · 2006/10/11(水) 01:01:45

いや無理なんじゃね？
逆行列は関係ない気がする。
そもそも行列で差分って何につかうんだ？

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

たぶん間違えた。
Ａ・Ｃ=Ｂ=Ａにしたいってことか。
難しいな・・・

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

>>685でOKじゃないの？

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

>>679
>>685で正解。

あとは、かける順序に注意。
それから、Aの逆行列が求まらない場合はCは一意とならない。

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

>>685-689
ありがﾄﾝ!
＞Aの逆行列が求まらない場合はCは一意とならない。
はい、それはもう・・・
いや～たすかりました

**名前は開発中のものです。** · 2006/10/11(水) 03:42:19

>684が
「よつんばいになれば免許を返して頂けるですね」の改変に見えた俺はとっとと寝ろ

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

アッー！

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

ID3DXAnimationControllerでアニメーションをやっているのですが、
アニメーションの全長(時間)はどうやったら取得できるんでしょうか？
それから、アニメーションを構成するキーフレームがそれぞれ何秒のところにあるのか
を取得したいのですが、そういう手段はあるんでしょうか？

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

>>693
ヒント：xファイルに書かれてる

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

そんな関数無い

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

じゃフレームが出力できるxファイルを作る必要があるじゃん
メタセコで出来る？

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

データ作った人間には何フレームあるかわかるだｒ

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

ドラゴンボールのビームとか
ガンダムのビームとかの棒
どうやって描画してるの？
円柱モデルじゃないでそ
ビルボードは、点を中心のやつじゃないとダメだし
ぬう

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

別に円柱でもそれっぽく見えればいいんだよ

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

6～8角厨

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

>>698
六角柱だけをライトなしの真っ白でレンダしてぼかすんだよ

**名前は開発中のものです。** · 2006/10/15(日) 00:49:28

>>698
＞ビルボードは、点を中心のやつじゃないとダメだし
んなわけない。

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

>>698
Gems3に載ってるやつは？
長方形のポリゴンの端に三角形がついてるやつ

**名前は開発中のものです。** · 2006/10/15(日) 11:47:05

>>698
「ビームの始点から終点までを結んだベクトル（以下、ビーム・ベクトル）」と
「カメラの位置からビームの端の点１つを結んだベクトル」の外積から
この２つベクトルに直角なベクトルを求める。
そのベクトルとビーム・ベクトルの外積からこの２つベクトルに直角なベクトルを求める。
このベクトルを法線ベクトルとする板ポリを描画するばＯＫ

ただ、カメラの視線ベクトルとビーム・ベクトルが平行に近いと板ポリであることが
はっきりと分かってしまうので、それの対処方法は以下の２つがある。

１つは板ポリの両端に普通のビルボードをくっつける方法（>>703が言っている方法）と、
もう１つはカメラの視線ベクトルとビーム・ベクトルが平行に近いときには普通の
ビルボードに切り替える方法がある。

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

光り系の加算テクスチャとかパーティクルも重要

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

アクションゲームの連続攻撃とかみたいな、ボタンの連続入力判定って
DirectInputでやる場合やっぱりバッファリングでやった方がいいんですかね？

**名前は開発中のものです。** · 2006/10/15(日) 19:20:54

連続入力のときに1/60よりも速い単位でボタン入力を受け付けるならバッファリングだろうなぁ。

**名前は開発中のものです。** · 2006/10/15(日) 19:41:13

ゲームコントローラは割り込みデバイスではないから、バッファリングでも
Pollを呼んだときしかデータ取得してないよ。

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

バッファリングでやってもあまり利点無いってことですかね
とりあえず直接取得でやってみます

**名前は開発中のものです。** · 2006/10/16(月) 03:58:38

1/60で連打できる奴以内だろ

**名前は開発中のものです。** · 2006/10/16(月) 11:47:04

連打機

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

>>710
連打は無理だろうが、1/60フレーム風神拳とか入力できる変態はいるよなー

>>706
アクションとか格げーだとバッファリングしたほうが楽なような気がするが。
あとで、リプレイとかつけたくなるかもしれんし。

**名前は開発中のものです。** · 2006/10/16(月) 11:55:28

そういや、VF5のアキラの膝が
K+G→１フレーム後にG離す
だったな
個人的には最風よりむずい

**名前は開発中のものです。** · 2006/10/16(月) 12:33:55

VF5は知らないがいまだにそのコマンドなの？
VF2でバグでそのコマンドで膝が出てたけど。

>>712
バッファリングだろうと直接データだろうと、入力の履歴は
アプリケーションに組み込むもの。
リプレイ等にDirectInputの設定は関係ないと思うが。

**名前は開発中のものです。** · 2006/10/16(月) 12:47:06

VF1からの伝統なのにVF5のとか書いてるところを見ると
十代だろうな

**名前は開発中のものです。** · 2006/10/16(月) 14:17:08

26ですが
今、VF5やってるからVF5って書いてしまっただけ

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

>>714
入力の履歴を保持する場合って、ボタン毎に数回分の入力時間を保持してればだいたいOKかな？

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

>>717
最低でも、コマンド受付可能時間×FPS数だけは記憶させないとだめだろ。

すなわち、ファイナルターンパンチ(溜め６０秒)×60FPSで記憶域3600個w

**名前は開発中のものです。** · 2006/10/17(火) 00:03:50

VF1からの伝統なのにVF5のとか書いてるところを見ると
ちんぽが十代だろうな

**名前は開発中のものです。** · 2006/10/17(火) 00:11:33

>>719
元気そうでうらやましい… orz

**名前は開発中のものです。** · 2006/10/17(火) 00:40:46

>最低でも、コマンド受付可能時間×FPS数だけは記憶させないとだめだろ。
正直な話、ボタンのため分をカウントしていれば、開始から発動までのバッファは要らない

「60秒押していたボタンを離した」と判定する、1フレーム分あればいい
波動拳コマンドの最長受付フレーム数が60フレームの場合ならバッファは60ほしい

これはバッファに入力を保存して、後からコマンドを検査する場合ね

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

>>718は語尾にwがついてるから冗談として極端な実装の例を挙げたんだろうけど、
>>721の実装は利点がよく分からんな。

>>721
> 「60秒押していたボタンを離した」と判定する、1フレーム分あればいい
その考えを押し進めると、
「押下したこと、離したこと、これらの時間間隔を記録すれば十分」ということになる。
だから、タメ時間を保持するためには、バッファの長さは60も要らなくて、2で済む。

最初に押下したときに、記録開始時刻からの時間を記録して、
次に離したときには、押下したときからの時間を記録して、
二度目に押下したときには、前に離したときからの時間を記録して、
……というように記録すればいい。

**名前は開発中のものです。** · 2006/10/17(火) 02:35:27

入力が変化するまでの時間を記録する方式は、ワーストケースで
毎フレーム入力が変化していた場合に、結局は入力受付時間分の
バッファが必要になるという事実。

**名前は開発中のものです。** · 2006/10/17(火) 03:45:09

で？

**名前は開発中のものです。** · 2006/10/17(火) 05:27:56

それでどうやってコマンド方式を判断するんだ？

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

カプコンは、ボタンを離したときもコマンド入力調べてる
SNKは、省略コマンドがある 21416→246

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

>>726
それは省略コマンドじゃなくて、最初から246しか判定してないだけだよ。
むしろ発表されているコマンドが冗長なだけ。

ちなみにスト2のスクリューも斜め入力は必要なくて、4方向だけでいい。

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

つーかボタン入力制御も知らないような奴がなんでこんなところにいるんだ？
基本的な常識も知らないでゲームを作りたいとか論外なんだが。

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

そうだね、プロテインだね

**名前は開発中のものです。** · 2006/10/17(火) 15:35:29

そう、常識だ。いや、常識だと多くの人々が思っている。
だが、実はCO2が地球温暖化の原因だという証拠は無いんだよ

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

D3DLIGHT_DIRECTIONAL な光源で
メッシュを描画しているのですが
scale=1.0f な時白→黒な球体が描画されるのですが
scale=10.0fな時灰色になるんです

何の影響なんでしょうか？

**名前は開発中のものです。** · 2006/10/17(火) 16:36:26

地球温暖化の影響

もしくは法線非正規化の影響

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

㌧ｸｽ

拡大の温暖化を防ぐには
SetRenderState( D3DRS_NORMALIZENORMALS, TRUE );
すればいいのね

**名前は開発中のものです。** · 2006/10/17(火) 20:02:50

RenderStateSet)TRUE, D3DRS_NORMALIZENORMALS(
が正解

**名前は開発中のものです。** · 2006/10/19(木) 11:57:34

おっぱいスレで質問したけど、答えが返ってこないので、こっちにマルチします。

おっぱいをデフォメーションさせてたゆんたゆん揺らせるには
メッシュオブジェクトの乳の部分だけを属性バッファで指定して、さらにその頂点バッファにアクセスして
頂点を動かせばいいの？

↑でいいとしても、乳の部分だけの属性バッファを作る方法が分かんない。

ヒント、この辺読め、カス！だけでもいいので教えてください。

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

X-File?
だったら判定するためのデータ埋め込めばいいじゃない

**名前は開発中のものです。** · 2006/10/19(木) 14:02:37

人体にチップを埋め込まれる、の間違いだな

**名前は開発中のものです。** · 2006/10/19(木) 23:40:34

モルダー落ち着いてモルダー

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

モルダー、あなた疲れてるのよ

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

おしっこモルダー

**名前は開発中のものです。** · 2006/10/20(金) 00:03:50

モルダー、あなたマジで疲れてるのよ

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

美しい河よ、モルダーよー

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

IndexBufferとVertexBufferの意味って何？

座標とか全部メモリにいれて
DrawIndexPrimitiveとかやればいいじゃん。

制限とか違うの？

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

>座標とか全部メモリにいれて
>DrawIndexPrimitiveとかやればいいじゃん。

それでいいんだよ。
ちょうてんばっふぁとか
いちいちつくるのめんどうだもんね！

**名前は開発中のものです。** · 2006/10/20(金) 16:04:45

何にでも疑問を持つのは良いことだ
次は自分の人生に意味を求めて自殺だレッツゴー

**名前は開発中のものです。** · 2006/10/20(金) 22:38:41

>743
いくらなんでもそれはひどい・・・
もっと上手く釣れ。

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

どうせ三途の川でくだらない釣りをしてるだけだろ。ホキでも食ってろ。

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

質問です．
HDRフォーマット（D3DFMT_A16B16G16R16）のテクスチャをレンダリングターゲットにした場合，
D3DFMT_X8R8G8B8のターゲットに使用していた固定パイプラインの機能を
そのまま使用しても正しく描画できるのでしょうか？

描画前に一時的なターゲットとしてHDRテクスチャを咬ませただけで
アルファブレンディングが上手くできなくなってしまったのですが……．orz

**名前は開発中のものです。** · 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だけですむ様にも最適化されるだろ。