スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

描画の効率化

さて描画入力音声と、3拍子揃ったので実際どんくらい速度でるのか試した。

1000個程度矩形を書いたところでfpsが急に落ちた。全然駄目やないか。
あれ、ちょっと前にやったときには5000個位までいけたのに。

で、どうやらボトルネックは
・やっぱりdrawprimitive呼びすぎ
・やっぱりテクスチャ切り替えすぎ
ってことらしい。よくわからんが。

そもそも3Dみたいにひとつのオブジェクトが何千何万頂点あるのと違い、
平面の場合は4頂点~を基本としているわけで土台が違うわけだ。
となると、drawprimitiveやsettextureみたいによびだしコストが高い奴はやばいわけだ。
今はなんも考えず一枚書くのにテクスチャセットからdrawprimitiveをしてるわけだが、
これはまとめられる限りまとめた方がもちろんいいと。
が、2Dだと大概の場合は基本頂点情報はおなじで位置だけ違うってのが多いから、
適応する変換行列を複数選択できない以上、変換行列で頂点操作するには個数分drawprimitiveがいる。
頂点ブレンドを本来使われるべく用意された方法無視して使えば、出来ないことはないがぶっちゃけ無駄だろう。
恐らくはインデクス付三角形リストを毎描画一度だけロックして書き込み、がいいか。
のためには、描画をしたいクライアントは最低限の情報を描画担当者に次々渡し、
最後まで来たらまとめてロックし描画をするという仕組みだろうか。
他に適するものとしてdrawprimitiveupというのもあるが、directX10以降オミットされたので非推奨なんだろうか。
きっと中身では渡された頂点配列GPUに送りつけてるわけだから、やってることは同じってこと?誰か教えて。
しかし動的配列となるとやっぱベクターか。STLまじぱねぇ。ついでにboostもぱねぇ。早くC++0xこい。
もうなんか普通の配列とか使うけどいらないよ。
ただこれやると、システムメモリに数千の頂点配列を確保することになるが…。
まいいか。今回はメモリをふんだんに無駄使いしよう!の方針で行こう。
さてこの場合、テクスチャ切り替えを減らすには、テクスチャ別に描画出来る機構が必要となる。
ついでに同じテクスチャグループは、一画像内にいくつかテクスチャを小分けして設置して、考慮する事になる。
と、こんどはクライアント側でテクスチャ座標を考慮する事になる。
するとどうだ、面倒くさいので、一元管理したくなる。
時間がなくなる。
ウボァー。


見事な連携だな。
だが無意味だ。


一通りふざけたところで話を戻すと、結局どちらにしても描画依頼側は描画情報を出さなければならないが何が必要か。
最低限頂点位置、まずはこれは必要だろう。しかし自由変形や五角形以上を描かない限り、
描画位置を示すのに四角形に必要なのは、中心と幅・高さでいい。
逆に任意個数頂点に対応したものにするには可変長配列が必要となるが、newが発生する…
のは微妙なので、根源の三角形と長方形の2種類あればどんな形もいけると信じよう。
三角形だと重複頂点があるがもう知らん。連続性フラグとか設けて、ダブりをなるべく無くそう。
基本は長方形とすると、後必要なのは頂点色とテクスチャ座標。
頂点色はガリガリ好きに書いて貰うとして、件のテクスチャ座標は、
何かテクスチャ名とかかいて貰うことで、ファイルとテクスチャ座標を気にしなくていい機構を考えよう。
あるいは動的に実行時そんなふうに並んだテクスチャが作れると嬉しいんだけどね。
既存のテクスチャをマージする方法とかあるんでしょうかね。

スポンサーサイト

Comment

コメントの投稿

Comment
管理者にだけ表示を許可する
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。