DirectX総合スレ (Part5)

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

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

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

**名前は開発中のものです。** · 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に対するレス。