DirectX総合スレ (Part6)

**DirectX6** · 2006/11/17(金) 00:38:52

言語は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/

**名前は開発中のものです。** · 2007/04/23(月) 10:39:58

DirectX関連の本は大抵、説明をわかりやすくするために
わざとハードコーディングのサンプルを載せてるものが多いと思うんだが。
とかなんとか書いていたら>>788が1～2行目で言ってるじゃないかorz

**名前は開発中のものです。** · 2007/04/23(月) 12:52:06

>>792みたいな奴がイチイチ状況を理解せずに文句を言うから、
アメリカのマニュアルみたいに最初に注意書きをいっぱい書いておけば良いんだよ。
生き物は乾燥させられません、説明用にコーディングしているため最適なコードではありませんと。

**名前は開発中のものです。** · 2007/04/23(月) 13:49:46

分かりやすくなっているのなら良いけど、>>788の本に限って言えば
特に分かりやすくなっていなかった。（だから「無駄に」って書いた）

その本とDirectX SDKのサンプルやMSDNの記事を両方を読んでみて
SDKのサンプルやMSDNの記事の方が分かりやすかったし、役にも立った。

**名前は開発中のものです。** · 2007/04/23(月) 14:26:03

そりゃSDKサンプルとかMSDNの方が分かりやすいとは思うけども、やっぱ本は必要だよ
画面小さいといちいち窓切り替えて見比べたりしづらくて、うがー、ってなる
あと暇なとき寝ながらでも読んでいられるし

**名前は開発中のものです。** · 2007/04/23(月) 15:00:28

WUXGA+UXGAの環境だと
窓を切り替えたり画面小さくしたり
することに逆に憧れる

**名前は開発中のものです。** · 2007/04/23(月) 20:34:58

環境は人それぞれ

ゲーム作って実感しましたorz

**名前は開発中のものです。** · 2007/04/27(金) 15:48:01

エグゼクートバッハー復活希望。

**名前は開発中のものです。** · 2007/04/28(土) 00:58:45

外人のコミュニティで言って来い

**名前は開発中のものです。** · 2007/05/02(水) 14:11:20

スキンメッシュのフレーム情報の管理に関して質問でつ。
ボーンとか仕込むとメッシュが階層構造持つことになるけど、
それぞれのフレームが持つ情報へアクセスする方法はどうやるのが一般的？

自分はいま全フレームへのポインタを一次元配列で確保しといて、
そのポインタを通じてフレーム内情報の読み書きをしてるんだけど。。。
階層構造とか再帰とかあんまり経験無いからどうすればいいのか……。

**名前は開発中のものです。** · 2007/05/02(水) 15:23:45

一番簡単な実装方法は再帰でツリーをたどる関数を作る
オーバーヘッドが気になるならば
ロード時にフルパス名を作ってそれをキーにしてマップに登録

**名前は開発中のものです。** · 2007/05/02(水) 19:23:04

好みの問題じゃないか？

基本は１つの頂点バッファで管理。
派生クラスでは体のパーツ（ボーン？)毎に、
頂点バッファ上での範囲を管理していて、
体の中心から変換マトリックスを更新しつつ、
範囲ごとに表示。

ローポリでいくつもりなので、
俺の場合はこんなもん。

**名前は開発中のものです。** · 2007/05/04(金) 17:40:46

DirectX 9.0cでアプリケーションを作ってるのですが
普通に動かすと40FPSぐらいですが
Windows Media Player11を起動させておくと
60FPSに跳ね上がります。なんで？？

**名前は開発中のものです。** · 2007/05/04(金) 17:47:27

普通に動かして40fpsってどんなスペックやねん

**名前は開発中のものです。** · 2007/05/04(金) 17:49:11

>>804
タイマーの分解能の設定は？

**804** · 2007/05/04(金) 18:15:02

>>806
timeGetTime()で設定とかはとくにしてないですが
40FPSだと見た目でガタガタになるのがわかるので
おおよその値はあってると思います。

**名前は開発中のものです。** · 2007/05/04(金) 18:17:03

>>807
いや・・・・・・・・そうではなくて
設定してないなら設定しろと言っていると思われます

**804** · 2007/05/04(金) 18:22:57

>>806、808
はうあ！　MediaPlayerを立ち上げなくても速くなりました！
MediaPlayerが共通のタイマーの設定をしてたということでしょうか。
ふしぎふしぎ。ありがとうございました。

**名前は開発中のものです。** · 2007/05/04(金) 18:54:44

ふしぎーのもーりーはー

**名前は開発中のものです。** · 2007/05/04(金) 21:33:47

メディアプレーヤーを起動してると速くなる系の質問はかなり頻出

某掲示板で検索してもわんさか出てきた
ttp://bbx.hp.infoseek.co.jp/cgi-bin/bbx.cgi?log=49&vew=100

様はtime＊＊系の設定はシステムグローバルだってことね

**名前は開発中のものです。** · 2007/05/04(金) 22:20:15

>>804
もう解決したが、
timeBeginPeriod(1)
timeEndPeriod(1);
だな

**名前は開発中のものです。** · 2007/05/04(金) 22:20:59

これ、Win98から、Win2000に移ったころハマったよ。懐かしい（昔話）

**名前は開発中のものです。** · 2007/05/05(土) 22:52:08

自分の環境では、サイズを自由にしてテクスチャを生成できるのですが
そういう環境でも、テクスチャサイズを２のべき乗にした方が
スピードアップできるのでしょうか？

**名前は開発中のものです。** · 2007/05/05(土) 22:53:55

何故実験環境があるのに、自分で測定しようとしない？

**名前は開発中のものです。** · 2007/05/05(土) 23:13:52

今は、指定数値のままの自由サイズでテクスチャを作成できるように
してるだけで、それを２のべき乗に拡大して（余剰分は透明色にする）
生成するルーチンの実装はまだやってないのです。
２のべき乗にした方が速くなると分かれば、そのように実装しますが
そうでないなら無駄な労力を使いたくないという事です。

**名前は開発中のものです。** · 2007/05/05(土) 23:16:34

じゃぁ、お前の環境とやらを住人全員に配布しないとだめだな。

**名前は開発中のものです。** · 2007/05/05(土) 23:24:16

>>817
>>816は別に配布するんじゃなくて自分専用の何かを作るってるんでないの

2の整数乗でないサイズのテクスチャに対応したハードなんて
持ってる人どんだけいるんかね

**名前は開発中のものです。** · 2007/05/05(土) 23:39:41

２のべき乗の方が速い。

**名前は開発中のものです。** · 2007/05/05(土) 23:45:51

おお。サンクスです。
自分のＰＣのグラはオンボードなので、現代じゃ一般的だと思ったのですが
そうじゃないのですかorz

**名前は開発中のものです。** · 2007/05/06(日) 00:01:04

速い遅いというのが何を指しているかによるが
Directt3Dサーフェイスには幅の他にピッチという概念があるので
テクスチャ作成に関わる部分では、サイズがいくつだろうが変わらないと思う。
フィルタリング(ミップマップ)は2^nサイズだと、最適化ルーチンが使えるので
そっちの方が速そうだ。
テクスチャサンプリングはGPUのリッチさによりけりだな。

**名前は開発中のものです。** · 2007/05/06(日) 00:02:33

自分で試すまでどっちが早いかなんて分からない。

**名前は開発中のものです。** · 2007/05/06(日) 00:03:58

＞速い遅いというのが何を指しているかによるが

テクスチャの表示です

**名前は開発中のものです。** · 2007/05/06(日) 00:36:27

>>804-813
自分も同じことにはまってました。
なぜか特定のマシンだけ極端にFPSが上がらなくて、VirtualPCを立ち上げると
FPSが高くなってました。

timeBeginPeriod、timeEndPeriodはアプリケーションの開始と終了に書いてましたが、
それを変更したら直りました。
どうもありがとう。

**名前は開発中のものです。** · 2007/05/06(日) 12:47:32

>>816
テクスチャの内容なんて影響ないと思うから重要なのはテクスチャのサイズだけじゃないの？
サイズが２のべき乗かそうでないかの違いしかないんじゃない？
だから現状指定数値で実行できるなら

わざと２のべき乗のサイズにしたテクスチャの場合
と
２のべき乗のサイズでないテクスチャの場合
と
で速度を測ってみればいいじゃない
とりあえず表示はちゃんとしてなくても速度だけ測れればいいんでしょ？
ならこれで測れば問題ないんじゃない？

ただ、上の人も言ってるけど何が影響するのか要素が多すぎて
やってみてナンボってところあると思うよ
ミップマップとか、バイリニアフィルターとか、ＵＶのアドレッシングモード、
１フレームでテクスチャ切り替えを頻繁に行ったとき、
１フレームでテクスチャ切り替えを頻繁に行わなかったとき
とかなんかちょっとした条件の変化で速度変わるかもわからんしね
テスト画面作ってるときは影響なかったけどゲーム作ってみたらモリモリ重くなったとかありがち。

ちなみに俺の環境ではたいして違いは無かった

**名前は開発中のものです。** · 2007/05/06(日) 20:25:23

>>818
GF6600以降のグラボは全部自由サイズのテクスチャに対応してる。
ただし範囲外サンプリングはCLAMPに限定され、
ピクセルシェーダー命令が一部使えないけどな。

**名前は開発中のものです。** · 2007/05/06(日) 20:58:18

>>826
GF6600は含まれてますか？

**名前は開発中のものです。** · 2007/05/06(日) 21:01:14

GFは、か・・・

**名前は開発中のものです。** · 2007/05/06(日) 21:10:39

これがゆとりか。

**名前は開発中のものです。** · 2007/05/06(日) 21:48:05

>>826
制限があるのはNONPOW2CONDITIONAL
これはGF6600どころか、もっと前から使える。
というのも、この機能の制限をよく考えれば分かるが、POW2テクスチャの
一部を使えば実装できるようになっているので、ドライバが対応すれば
どんなチップでも対応できる。

GeForceは6シリーズから、真のNon-Pow2テクスチャに対応したから
細かい制限は無いよ。（仕様上テクスチャ圧縮は使えないが）

**名前は開発中のものです。** · 2007/05/06(日) 22:19:49

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/

**名前は開発中のものです。** · 2007/05/07(月) 10:07:13

自分で3Dエンジン組めば分かるけどpow2のテクスチャはビット演算だけでrepeatとか可能で非常に便利。

俺はゲームで使うテクスチャは3D絵はpow2、2D絵は自由サイズにCAMP限定でエンジン組んでる。
non-pow2対応してない場合はpow2のテクスチャに拡大転送してUVは内部で自動再計算。

**名前は開発中のものです。** · 2007/05/08(火) 13:27:17

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で取得する方法、もしくは他の関数がありますか？
よろしくお願いします。

**名前は開発中のものです。** · 2007/05/08(火) 17:35:02

ヘルプが間違っているんだから、ヘッダを確認するのがプログラマの常識。

**833** · 2007/05/08(火) 19:07:00

ヘルプが間違っているのですか…。ということは英語版のMSDNも。
ヘッダの確認もしたのですが、なにぶんあまり知識がないものでよくわからなかったのです。
なのでこちらで質問させていただきました。

BaseVertexIndexの取得についてですが、自己解決しました。
この引数を検索したら、DrawIndexedPrimitiveで使ってますね。

ありがとうございました。

**名前は開発中のものです。** · 2007/05/08(火) 23:17:50

２のべき乗にしたがるのはswizzlingを一発で通したいからなんじゃないの

**名前は開発中のものです。** · 2007/05/09(水) 10:09:33

RTSみたいなゲームを作ってる者なのですが
描画速度が思うように速くならずに、非常に困っております。

画面サイズは800×600で、フィールドは32×32の板ポリゴンをタイル状に敷き詰めてます。
その上で動くユニットと小物オブジェクトも全て板ポリゴン（一部ビルボード）です。
それを１フレームごとに
Clear
フィールド描画　＝　SetTexture()→DrawPrimitiveUp()を各タイルごとに約500回
ユニット＆オブジェ描画　＝　Vertex配列に座標数値を代入して
　　　　　　　　　　　　　　SetTexture()→DrawPrimitiveUp()を平均500回（500ｵﾌﾞｼﾞｪ分）
Present
と描画してるのですが、当方の環境はP4 1.8GHzでオンボードのグラボですが
せいぜい２８FPSまでしか出せません（ポーズ中の描画Onlyのみで）。

たかだか１０００個の板ポリゴンを描画するだけでFPS30もいかないものなんでしょうか？
これで本来の内部処理を加えると、20FPSが限界になってしまいます。
１フレームごとに
頂点配列に数値代入（フィールドタイル以外）→SetTexture()→DrawPrimitiveUp()
を板ポリの数だけ繰り返すやり方では駄目なのでしょうか？

**名前は開発中のものです。** · 2007/05/09(水) 10:54:03

Direct3Dはテクスチャの切り替えとDraw系関数のコールがびっくりするくらい遅いので、
板ポリゴンはなるべくひとつの頂点配列に溜め込み、
テクスチャはなるべく一枚のテクスチャに詰め込み座標ずらしで対処して、
Draw系関数のコールとテクスチャの切り替えを少なくすればそれなりに改善されると思うよ。
まぁ1000回程度ではそこまでガタ落ちしないから、他にも問題抱えてそうだけど・・・。

パフォーマンスまわりの話は文面だけだと話しが拗れがちだから、
こーゆーとこで質問するよりプロファイラの読み方覚えた方が良いかと。

**名前は開発中のものです。** · 2007/05/09(水) 14:05:17

２ｃｈでDirect3Dのパフォーマンス絡みの話題となると、
ステートの変更を減らせとかDraw系関数の呼出回数を減らせとか、
結局そんな一般的なことしかなかなか書けないんだよね

プロファイラの読み方というかプロファイリングについての基本的なことなら、
とりあえずここを最後まで読んでみることをすすめてみる。

http://msdn2.microsoft.com/en-us/library/bb172234.aspx

長いけど、中でやってることは単純

**名前は開発中のものです。** · 2007/05/09(水) 14:14:56

グラボの名前とテクスチャの解像度も書こうぜ
トライアングルセットアップがボトルネックとは限らん

**名前は開発中のものです。** · 2007/05/10(木) 23:34:29

IDirect3DDevice9::CreateOffscreenPlainSurfaceで作った
サーフェイスにレンダリングすることってできますか？

**名前は開発中のものです。** · 2007/05/10(木) 23:53:06

no you can do it

**841** · 2007/05/11(金) 00:17:56

>>842
僕の質問に対する回答でしょうか？

**名前は開発中のものです。** · 2007/05/11(金) 00:47:00

no i did

**名前は開発中のものです。** · 2007/05/11(金) 01:05:36

英語の "Yes/No" は、日本語の「はい／いいえ」と
厳密に対応してはおりません。

842と844は
"All your base are belong to us"
レベルの英語もどきですね。

**名前は開発中のものです。** · 2007/05/11(金) 01:51:06

no this engrish is yours

**名前は開発中のものです。** · 2007/05/11(金) 01:56:20

>>845
842も844もネタだろ？
そのまま「はい」「いいえ」に置き換えたとしても
質問文の内容から考えて意味が通ってないしｗ

**名前は開発中のものです。** · 2007/05/11(金) 02:40:30

>>841
できません。

**名前は開発中のものです。** · 2007/05/11(金) 09:50:20

>>841
できないし、そんなことをするような状況が存在しないだろう。

**名前は開発中のものです。** · 2007/05/11(金) 17:53:19

>>849
GPU使った汎用演算で使いたいのかも。
まあ、その場合でも普通のテクスチャ使うか。。。

**841** · 2007/05/11(金) 23:05:46

>>848,849,850
ありがとうございました

**名前は開発中のものです。** · 2007/05/11(金) 23:22:19

>>838
>>839
どうもありがとうございました。

**名前は開発中のものです。** · 2007/05/11(金) 23:45:13

>>838-839
>>837の問題に対してまとめたところで意味あるのか？と聞きたい
例えばこの処置で速度が２～３倍になったとしてもそれでも60FPS多分届かないぐらいなんだぜ
チップを敷き詰めるならロード時にチップ敷き詰めたデカイテクスチャを作ることだってできると思うんだが
こういうゲームではどうなんだろうか？
まあ、ゲームのマップ全体を作れとは言わんがある程度のまとまりで逐次ロードしつつ作れれば
描画時のポリ数に悩まされることはないんじゃないだろうか？

少なくとも俺はDrawPrimitiveにポリゴンをまとめて突っ込むなんてのはなんの解決策にもなってないと思うんだけど？
だってDrawPrimitiveって普通に何回も呼ぶぜｗ
呼ばなきゃゲーム作れねぇじゃんｗ
エフェクトによって２度描き３度描きよくやるぜｗ
やっぱさ、このまとめる形の最適化ってなんかおかしいと思えってｗ

**名前は開発中のものです。** · 2007/05/11(金) 23:54:11

そうえいば、DirectX10でDrawPrimitiveのボトルネックが無くなるとか
噂を聞いたがどうなったんだ・・・・？

**名前は開発中のものです。** · 2007/05/12(土) 00:29:50

>>853
いやー、結構効果あると思う。以前おれも同じ状況になったし。
その時はスプライト？(ポリゴンx2の四角形、画面上で32x32ピクセルくらい)
一枚一枚でDraw～()呼んでたら数百枚で60fps割った。

でもテクスチャが同じスプライトをまとめて、Draw～()の回数減らしたら
30000枚くらい描画しても60fpsをキープできるようになった。

**名前は開発中のものです。** · 2007/05/12(土) 00:57:05

なんか思い出してきた。

たしかその時は同じ頂点バッファを使いまわしてたんだ。（＝頂点４つを数百回反復使用。。。）
1フレーム間に同じバッファで何回もLock → Drawを繰り返したのが悪かった気がする。
だからDraw～()の回数もあると思うけどバッファのLockにも注意すべきかと。

**名前は開発中のものです。** · 2007/05/12(土) 01:02:49

>>853
おたくのゲームの作り方に関係なく「DrawPrimitive」には
相当のCPU負荷が存在するのは現実世界での事実だ。

だからあの手この手でDrawPrimitiveを減らすための努力や
システムを組むのに時間をかけるんだろう。

そのためだけにわざわざMSが専用APIが実装したり、
GPU Gemsにそれを扱った章が掲載されたりしている。

DirectX10では改善されているが、DirectX9まではそこがボトルネック
なのだからそこをいかに減らすのかもプログラマの腕の１つ。

**名前は開発中のものです。** · 2007/05/12(土) 01:08:37

fbxやtga等のファイルを作成する開発環境でフリーで良いのありませんか？

**名前は開発中のものです。** · 2007/05/12(土) 01:14:19

>>857
いや、重いのはわったけどさ
劇的に早くはなんねーってことよ。

なんつーの？DrawPrimitiveにまとめて突っ込むとかやりだすようになったら
手法を根本的に変える必要があるときだと思うのよ（まあ、例として>>853つーことで）

例えば、ソートをバブルソートが遅いからってクイックソートに変えて解決する問題って少ないと思うんだよね。
そりゃオーダーが全然違うし、クイックソートの方がはるかにはえーよ。それはわかる。
でも、実用的じゃないでしょ？
そういう話よ。

ゲームに限らずよ、ただ目先の数値につられてホイホイ最適化しちゃうのってまずいと思うぜ。
もう、これやるっきゃねーよ。って状況が意外と少ないと思うのよね。

**名前は開発中のものです。** · 2007/05/12(土) 01:47:38

>>858
http://goldenstudios.or.id/products/GTGE/

**名前は開発中のものです。** · 2007/05/12(土) 02:40:52

でだ、そうはいってもまとめなきゃ動かんようなものもある
弾幕ＳＴＧの弾とかやるっきゃないね
ただ、こういうのは俺の中ではええねんｗ

だってこんなのもともと普通じゃできねぇような量を描画しようとしてるじゃん
しかも、普通だったら全部カメラに入るなんてまずないのに２Ｄであるために全部描画しなくちゃいけないとか特殊事情
だからこれはどうでもええねん。
できないような量を無理やり動かすんだから大いに最適化してくれって感じじゃん。
魂までもすり減らせって感じだ。

ただ、マップなんかは普通じゃん。

俺がいうところの何を普通っていって何が異常かってのがわからん？
これはオブジェクト単位で普通とかどうとか言ってると思うｗ

パーティクルやらちょっとまとまった単位でのもんってのは他のやり方があると思うんだよね。
もう、パーティクルなんてやめてアニメーションテクスチャにとっかえちゃうとか、
マップチップも３Ｄ空間にもってきたら下地じゃん。これもやりようがあると思うんだよね。
ただ、弾幕ＳＴＧの弾は弾１つでオブジェクトなんでやりようがないと思うんだよね。
この場合は妙ちくりんなワザ使って最適化する必要があると思うんだよね。
って感じ。

だからやらなきゃいけんところはやらなきゃいけんと思うんだけど
そういうところって少ないと思うんだよね。
ああ、で、やっちゃいけないところをやっちゃうと
今度は身動きとれなくなっちゃうって感じなので（やってることが最適化なので当然だが）あんまりこの
DrawPrimitiveにまとめて突っ込む手法ってのはやる前に別のやり方がないかちょっと考えたほうがいいと思うんだよね。

**名前は開発中のものです。** · 2007/05/12(土) 05:31:59

凄いぞ。書けば書くほど論旨がぼやけていく。

**名前は開発中のものです。** · 2007/05/12(土) 06:02:47

噛めば噛むほど旨みが出てくるのなんてするめくらいだろ

大抵のものは噛めば噛むほど不味くなる。
それと同じ

**名前は開発中のものです。** · 2007/05/12(土) 06:58:58

またこの話題か
CPUがネックになってるかGPUがネックになってるかでどっちがいいのかなんて変わるだろ

**名前は開発中のものです。** · 2007/05/12(土) 07:04:06

バッチの話題になると妙に血気盛んに意味無い論語り出すアホがいるよな

そんなもんケースバイケースだ、で終わるのに

**名前は開発中のものです。** · 2007/05/12(土) 08:51:13

>>865
>ケースバイケース
それだってある程度法則があると思うんだけど
まあ、こんなDrawPrimitiveに全部突っ込むなんてのは稀だよ

**名前は開発中のものです。** · 2007/05/12(土) 09:37:22

まぁ、少なくともこのケースはDrawPrimitiveが原因だと思うが・・・。

**名前は開発中のものです。** · 2007/05/12(土) 09:48:15

ケースバイケースでもあるし程度の問題でもある。
何も画面描画を1回のDPで行えなんて無茶は誰も言ってないだろ。

描画数が多くてある程度まとめられるものをまとめようぜ、って話だろ。
背景のマップチップや弾幕STGの弾みたいなものはソートがそれほど重要でもなく
数だけはべらぼうに必要な場合が多いからそういうものはまとめる。

フォント描画のときだって1文字ずつDP呼び出すなんてまずしないだろ。
最近のD3DXFontですらキャッシュするように改良されてるんだから。

GPUがネックの場合はまとめようがまとめまいが処理落ち確定だから意味ないけどな。
GPUがネックなら基本的に数を減らすしかねぇ。

**名前は開発中のものです。** · 2007/05/12(土) 09:48:27

>>867
解決策のアプローチの話なんだが・・・

**名前は開発中のものです。** · 2007/05/12(土) 09:55:02

>>868
>数だけはべらぼうに必要な場合が多いからそういうものはまとめる
こうかくと１フレームのこういうモデルの描画すべてをまとめようとする奴がいる
あくまでオブジェクト単位でまとめるだけって書いておきたいｗ

**名前は開発中のものです。** · 2007/05/12(土) 10:04:33

>>868
日本語読解力の欠けた俺に
ケースバイケースと程度問題の違いを教えてくれ

なんて不毛な論争なんだろうか

**名前は開発中のものです。** · 2007/05/12(土) 10:40:39

通訳しよう。

「他人の話はどうでもいい、俺様の話を聞け」

**名前は開発中のものです。** · 2007/05/12(土) 10:54:26

>>871
横から突っ込むけど明らかに違うだろ、日本語的にも

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

アイデンティティの問題ってのもあるから難しいよね。

身の程に合わないほど自意識を肥大化させたオッサンって、
現実では、　実際の待遇＞＞＞自己評価　　という状況に必ず直面する。
そうなると、普段抑圧している分、こういう場で
必要以上に自尊心を満たそうとし始める。

メンツに固執し、自分がトップに立つ形で決着がつかないと暴れ始める。
自分が一番でないとアイデンティティが崩壊するから、妥協できない。
相手の意見を認める、見解の違い・表現の違いを容認する柔軟性がなくなる。
そしてネットでも加齢臭をまき散らし、嫌われる。

「匿名の状況下では君の自尊心は何の意味も持たない」
という単純な現実を受け入れてくれればよいのだが。

**名前は開発中のものです。** · 2007/05/12(土) 11:12:42

このタイミングでそのレスはさすがになにがいいたいのかわからない

**名前は開発中のものです。** · 2007/05/12(土) 11:37:34

実際の待遇＞＞＞自己評価　なら文句ないぜ

**名前は開発中のものです。** · 2007/05/12(土) 12:59:37

あーもー、この流れが嫌だからわざわざ予防線張ってアドバイス書いたのに・・・。
相変わらずID:LW0FYzwBは意味不明だな。

>>853
＞描画時のポリ数に悩まされることはないんじゃないだろうか？
>>837は少ないポリ数なのに遅くて困ってると書いてるのに
どうしてポリ数削減の最適化をお勧めしてるんだろうか。人の話を全然聞いてない。
仮に>>837が>>853の方法を適用したら、結果としてDPコールも減るから
問題の切り分けができないまま状態が改善してしまうかもしれないよ？

最適化の一般論を語るその口で出てくる具体的なアドバイスが
「目先の数値につられてホイホイ最適化」そのものってのが涙を誘う。
毎回思うんだが、あんた本当に2Dゲーム作ったことないだろ？

**名前は開発中のものです。** · 2007/05/12(土) 15:41:09

no i have never and will never do any of them

**名前は開発中のものです。** · 2007/05/12(土) 16:45:54

>>877
でも、DrawPrimitiveにまとめて突っ込むだけじゃここまでの速度はでないよね？
また、それで解決するかも怪しいよね？
>>853の方法なら確実でしょ。
その件に関しては文句あるの？

**名前は開発中のものです。** · 2007/05/12(土) 18:30:45

>>879
そのやりかたの場合システムが複雑になる。
別スレッドでリアルタイムに状況判断して新しいテクスチャ作らないといか。
間に合わない場合なども想定して組まなければならないわけだしな。

あと使うかどうかは別として高速スクロールが出来ない。

ポリゴン数には悩まされなくてすむがテクスチャメモリや
テクセルレートに関しての悩みがあることを忘れてもいかん。

だからケースバイケースだというわけで。

**名前は開発中のものです。** · 2007/05/12(土) 18:38:13

>>880
>あと使うかどうかは別として高速スクロールが出来ない
いや、できると思うけど俺は

**名前は開発中のものです。** · 2007/05/12(土) 22:52:39

どんな精度の絵を描こうとしてるんだ？？？

**名前は開発中のものです。** · 2007/05/12(土) 23:29:53

>>881
やったとこないけどできると思うとか
んな推測をもとに今までグダグダ言ってたのか？

STGスレで「DirectXはスクリーン限定でラスタースクロール可能」等と
胡散臭い主張して突っ込まれてフェードアウトしたロートルがいたが
お前はとてもよく似ている

**名前は開発中のものです。** · 2007/05/12(土) 23:32:38

s/スクリーン/フルスクリーン/

で、質問者>>837の数値を参考にして
例えば800*600フルカラーのゲーム画面で
フィールド一画面分（27x18のマップチップ）を描くとして
例えば以下の２つの手法を検討したとする

　①テクスチャにSetRenderTargetでスクロール分差分更新
　②30*20のメッシュのUVをスクロール分だけ差分更新

口先だけでないならこの両者のパフォーマンスを速やかに比較して
速やかに結論が出せるはずだ

**名前は開発中のものです。** · 2007/05/12(土) 23:35:32

前者について補足すると、これはおそらくお前がやろうとしてる
画面と同じかそれよりも大きいサイズのテクスチャにフィールドを
描いて、それをフレームバッファに転送とかいう方法

**名前は開発中のものです。** · 2007/05/12(土) 23:48:20

後者について補足すると、これはおまえが嫌っている
一画面分のマップチップをマテリアル単位でまとめて
DrawPrimitiveする方法だ。比較の便宜上差分更新としてるが
予めフィールド全域分を用意しても構わない。

**名前は開発中のものです。** · 2007/05/13(日) 01:29:23

>>883
君、そうやっていつも掲示板で見えない敵と戦ってるの？ｗ

いきなり高速スクロールを適用ことを前提にしてるけど
ＣＤなりＤＶＤなりＨＤＤの容量が許す限りどこまでもいくんだから
環境の制限でもしない限りなんでもできるだろｗ

スクロールなんて貧乏臭いことしなくても、
市販のゲームのアリガチ演出みたいに背景にムービー流してもいいぜｗ

別にロード時にテクスチャこさえなくてもすでにこさえたもん保存しておいてもいいわけだし
また、別にスクロールするときにテクスチャを生成しなくちゃいけないなんてのはお前だけの妄想だ
別にあらかじめすべての絵を完成させた状態でもいい

それとこの条件だとお前に振りだぜ、俺は別にチップにこだわらなくていいって考えだし
でかいテクスチャをチップ的な使い方もできるから要はお前のやり方も俺のやり方の中に含まれてしまっている

それと30*20のメッシュとか条件ついてるけど
俺の方法なら４頂点の２ポリでもいいしｗ
この場合のパフォーマンスは最速だ。
もっと変化がほしけりゃ好きにサイズを変えたらいいし、その場合ゲームによりけりになってしまうな。

**名前は開発中のものです。** · 2007/05/13(日) 01:35:05

要はチップってのがどういう性質のもんかってことだよね？ちがう？
昔はメモリが少なかったからできるだけ使いまわしていい絵を完成させようってのが
あったけど今は容量はアフォみたいに増えちゃったけど処理速度はそれにおっつくぐらい
上がってないって状況じゃないの？

**名前は開発中のものです。** · 2007/05/13(日) 04:13:16

こんな時間に質問です。

今、"Special Effects Game Programming with DirectX"って本を読んでいるんですが
添付されているCDのDirectXはVersion 8.1です。
ネットで検索すると最新はVersion 9.0cらしいですね。

皆さんならどちらをインストールしますか？
(それらの違いをよくご存知の方が答えてくださると光栄です。)

**名前は開発中のものです。** · 2007/05/13(日) 07:37:01

>>888
マップチップでやるっつーのは質問者の意向だろう
その前提を覆すなら初めからそういっときなよ
苦しくなったからって今更一枚絵でーとか逃げんな

お前の主張

一枚絵でやってもいんじゃね。ローカルメモリに全部読み込むと楽でいいよ

で片付く話。長文でぐだぐだ書かなくていいよ

**名前は開発中のものです。** · 2007/05/13(日) 09:34:18

>>888
お前まさかマップチップの利点がVRAMの節約だけだと思ってんのか？

すくなくとも画面いっぱいにチップ描画をする程度なら素直にバッファまとめてDPすりゃいい。
1024ｘ768程度の画面を32ｘ32のチップで埋め尽くしても余裕で60FPS出る程度の速度にゃなる。

元のチップを1枚のテクスチャにまとめるというデータ的な最適化は必要だがな。

背景に動画だとかユーザーの入力に反応してスクロールするときとか、
地形が変化するときどうするつもりだよ。
そもそも画質が劣化するしチップごとにアトリビュート持たせるために別のエディター用意すんのか？

**名前は開発中のものです。** · 2007/05/13(日) 09:38:17

>背景に動画だとかユーザーの入力に反応してスクロールするときとか、地形が変化するとき
質問者はそこまで想定してんの？