【C++】 DirectX初心者質問ｽﾚ Part23 【C】

今のPCなら数百万ポリ位は描画できる
それが出来ないのはFPSを固定していないから
処理落ち云々言ってるのは正に初心者

>>950
別に糞環境じゃねぇけど処理落ちするぞ

>>数百万ポリ位は描画
これを本気でいってるならそのほうが初心者っぽいが

1フレームで数百万はあり得ないが、1000回程度なら60fpsは簡単に出るぞ

処理落ちとして考えられる理由。

テクスチャを32*32ごとに一つずつ作って、毎度切り替えている。
動的バッファを作っていながらAGPメモリを使わずに毎度書き換えている。
意味も分からずID3DXSpriteを利用している。

>>956
そんなミスしないよ

自分はミスしない、悪くないという奴に限って、
致命的に馬鹿なことをしているのが通例。

考えられる原因

裏画面に全体を描き込んで一度に転送していない
(1チップ毎に画面転送している)

全てのテクスチャを作り直している

FPSを固定していない
垂直同期に設定している

無駄なSLEEPを入れている

ハードウェアアクセラレーションを使っていない

>>959
そんなの今更考えられる原因としてあげてるのおかしいだろｗ

処理落ちソースをさらしたら、猛烈に突っ込みを受けることになるんだろうな。

まぁ、ソースだせや
馬鹿コードを直してやるよ

>FPSを固定していない
>垂直同期に設定している

質問者とは別人だが、その辺をどうしようか考えているところ。
その辺のことを解説したいいページとかないかな。
MSDNに書いてある？

やりたいのは液晶（通例59ないし60FPS）、CRT(60以上)どちらでも
最大60FPSを（処理落ちしない限り）安定して提供できるようなフレーム処理がしたい。

意味も分からずID3DXSpriteを利用している。

いつの話だよ。
今のは最低限のDrawPrimitiveにまとめる構造になってるぞ。

>>964
テクスチャ順にソートするだけだろ

「DrawPrimitiveは遅いって聞きました」のひとことから始まるこの混沌を
僕はいつも楽しみにしています

矩形をたくさん描画するような処理やるときにまとめずに
分割して呼び出すと遅いってだけでそれ以外はこいつ呼ぶしかねーんだから
遅いも糞も使わなきゃなにもでんがなｗ

多分、垂直同期で決まりじゃないか？

ちなみに何FPS出てるのか知りたい

>>956
頂点バッファに溜めてるっぽい

マップタイルはサーフェイス作るっしょ
シーンの初期化時「Now Loading...」とでも表示してる間に並べて描いて
後は領域切り出して転送するだけ。

>>968
なるほど……垂直同期で待機する方法を調べてみるか。

>ちなみに何FPS出てるのか知りたい
今のところネットブックで動かしてもフルスクリーンにすれば
60FPSが出るように処理量を抑えることができている。

でも環境によって、CPUに余力があるはずなのに
常に100%使用になっちゃう場合があるんだよね。

垂直同期で待機するとフレームが飛んだ場合の検出を別にやる必要が出てきそうだ。
その場合はtimeGetTimeでいいのかな？

>>970
メモリー食うじゃん？

>>970
それだと縦横4096超えるようなマップが作れなくない？
オレならマップチップを並べた状態のメッシュを用意して、１つのオブジェクトとして描画させるが。
今のところ32x32サイズだが、テクスチャが共有できてれば速度的な問題は無い。

若干問題は残っていてフェードアウトかけたいときにマテリアル光のαを減らすと、
２重になってるマップチップだけ１重のところより明るく見えちゃうことだな。

これを回避しようと思ったら970のいうように一旦サーフェイスに書いて、
改めてα合成をやり直す必要があると思う。

cpu100%…

core2なら50%、クアッドコアなら25%になるんだろ？

もろ、FPS固定、可変SLEEPが出来てない証拠

2D (笑)

>>974
いや、どうもダメな環境の場合、
Draw*Primitive*() 〜 Present() あたりで制御が返ってきてないように見える。
まだちゃんと時間計測やってないけど。

メイン環境だと処理能力に余裕があるからSleepする時間が取れるんだけどね。

ネットブックのGME950は挙動にくせがあるなー。
テクスチャの初期化のされ方もほかの会社のと違うみたいだし。

垂直同期使ったらいかんよ？
モニタの垂直回帰を自動で待つんだから
垂直同期は外してマルチスレッドで主スレッドはメッセージループのみ
子スレッドでメインループを作る

>>973
DirectDrawでチップ組みの2DRPGを組むときのやり方と同じでしょ。
画面が1024x768でチップが32x32なら、サーフェイスは(1024+32)x(768+32)だけ確保して
矩形を４回描画すりゃできる。(2^nサイズの問題はおいておく)

これがベストって雛形ください

>>978
なるほど。そうやるのが定石なのか。

マップチップがアニメーションする場合は効率があまりあがらないような気がするが、
メッシュ処理をする場合にも最低限UVを張りなおしが必要なんだよな。
（テクスチャ上のチップを規則立てて並べることでピクセルシェーダ上で張替えを行う力業もあるわけだが）

>>977
そうなのか。垂直同期待ちというのは面倒そうだな。

>垂直同期は外してマルチスレッドで主スレッドはメッセージループのみ
>子スレッドでメインループを作る
趣旨は分かるんだが、メッセージループでクリティカルなイベントを拾ったときの対処が面倒になるね。
例えばフルスクリーン、ウィンドウ表示の切り替えだとか。
１スレッドでやってるときはスクリーン切り替え中は勝手に処理が止まってるわけだが、
非同期で動いている場合は外から止める必要がある。

まあ既に７割以上のＰＣがデュアルコア以上になってるという市場の調査結果もあるから、
マルチスレッドによる計算資源の活用は積極的にやるべきだよな。

メッセージループって新たにスレッド作って回した方がいい？

>>973
全然わからんのだが教えてくれるか

>サーフェイスは(1024+32)x(768+32)だけ確保して
なんで+32？端の32x32 x nをマップチップとして使うの？
それだと数が限られないか？

>矩形を４回描画すりゃできる。
なんで4回？
この数字はどっから出てきた？

↑>>978の間違い

>>983
エスパーの俺が受信したところによると
全画面より１チップ分だけ縦横にスクロール分を確保。
４回の件は、例えば左上にスクロールするとすると、左上部分を転送（１回目）
右部分の縦に細長い矩形を転送（２回目）
した部分の横に細長い矩形を転送（３回目）
右下の１チップを転送（４回目）

ってことではなかろうか。
こんな方法が標準かどうかは別の問題だけどさ。

DDrawの初期はVRAMが4Mとか8Mなので、サーフェイスの確保も表示画面数個分とか。
そんな時代にBltFastを駆使してドット単位スクロールをするなら・・・という手法かな。

その後すぐに、システムメモリに画面を作ってCPUで全画面転送した方が早いので
素直にでかいメモリ確保するようになった。

>>985-986
なるほど、スクロール分なんですね。
納得しました。ありがとう。

D3DFVF_XYZRHWで作ったポリゴンって1回固定パイプライン通ってるからシェーダー通せない？

頂点シェーダはスキップされる
ピクセルシェーダは使える

やってみたけど頂点シェーだ無視された・・・

D3DFVF_XYZRHWで作ったポリゴンってループ内で動かすことはできないんですか？

ESPを使っても分からない！

ESP？

D3DFVF_XYZにして
とらんすふぉーまー

XYZRHWじゃ無理っぽいな
一度サーフェイスに書き込んでXYZで描きなおすしかないか

最初からXYZで描けよｗ

D3DFVF_XYZRHWは頂点計算済みと見なすと書いてあるんだから、
スキップされるのは当然じゃないか。
なぜ普通にレンダリングしない。

>>978
今更だが、1024+32だとメモリがスゲー無駄になりそうだから工夫がいるな

>>998
基本的なアイデアとしてはこれで問題ないだろう。
また、最近のVGAボードなら２の累乗サイズでないテクスチャも扱えるし。
（処理速度に差がある場合があるようだが）

1024x1024で確保して768より下の部分をワーク部分とする方法もあるし、
2048x2048確保する方法だってあるだろう。

>最近のVGAボードなら２の累乗サイズでないテクスチャも扱えるし

2の累乗以外対応のハイスペックVGAならそこまで効率を考える必要はないとして
むしろ対応してないロースペックVGAのことを考えるべきじゃないかと

>2048x2048確保する方法だってあるだろう
だからそれが無駄だと

>1024x1024で確保して768より下の部分をワーク部分とする
そういう工夫がいるよなって話

2048でもあいた所をうまく使えればいいかもしれないけど
解像度高めのテクスチャって環境チェックとかめんどいんだよな…

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。