rev512で対応。 いわゆるフルスクリーンモード(解像度をVGAにすることによるもの)にするのではなく、 ウインドウ最大化かつBorderStyle=Noneで対応するようにしてみた。
sf298yen チケット切っていただきありがとうございます。
yyagi.com/DTXManiaGR_095_WASAPI_20130202.zip ⇒
'暫定対応かと思いますが、一応記述します。
'横道
カクツキは、単純に640x480以外のサイズの時全てで発生しているようです。
DirectX的には、BackBufferからFrontBufferへの転送時のスケーリング負荷が大きいと言うことなのでしょう。 これを改善するにはBackBufferのサイズをウインドウサイズに合わせろということなのでしょうけれども、 描画関連を全部見直さないといけなくてヤバいです。
というわけで、申し訳ないのですが、一旦旧方式の解像度切り替えフルスクリーン方式に戻しました。 (ウインドウのスケーリング方式を使う場合は、ウインドウ右上の最大化ボタンを押していただければほぼ近いものになります)
将来的には(HD化の時にでも)BackBufferの作り方を見直すことになると思いますが、解像度切り替え方式での描画遅延改善方法がないか、もう少し考えてみます。最初は tp://www2.tky.3web.ne.jp/~yosshin/prog_memo/latency/091029.html の「Lock Unlock Flip のタイミング」の内容そのものかなと思ったのですが、今の設計は結果的にこれの対策通りになっています。(ゲーム進行と画面描画が一体化している。)
HD化の予定については、viviさんに聞いて下さい(ぉ
横道については、必要に応じてチケット発行をお願いします。(理由を添えることをお忘れ無く。でないとコレジャナイものができる可能性があります)
sf298yen カクツキは、単純に640x480以外のサイズの時全てで発生しているようです。 …略… 将来的には(HD化の時にでも)BackBufferの作り方を見直すことになると思います
というわけで！
vivi様～！HD化待ってま～～す！
カクツキは、どうもウインドウがタスクバーに少しでも重なると発生するようです。(なので、ただのウインドウ最大化だと、処理落ちしない。)
sf298yenさんのところでも同じ状況でしょうか？
なお、試しに
tp://social.msdn.microsoft.com/Forums/ja/vbgeneralja/thread/c00c30af-b266-425e-a193-8eb1a88ad647
このあたりをみて、タスクバー(とスタートボタン)を消しつつフルスクリーンという荒技を試してみましたが、処理落ちの改善はできませんでした。やり方か何か違うみたいですね。
sf298yen カクツキは、どうもウインドウがタスクバーに少しでも重なると発生するようです。(なので、ただのウインドウ最大化だと、処理落ちしない。) sf298yenさんのところでも同じ状況でしょうか？
(Windows 7 / VSyncWait=ONで)
そうですね、おそらく同じ状況だと思います。
解像度が小さいとタスクバーにかかっていても普通に60fps出るため大丈夫なのですが、
ある程度大きくしている場合、Windowが見切れる場合カクツキます（だいたい45-58と60fps出ていません）。
タスクマネージャでexplorer.exeプロセスを切ってタスクバーを非表示にしたこともありますが同じでした。
補足：XPでは見切れていても60fpsのままでカクツキは今のところ出ていません。
Win7の場合、個人設定で、「ウインドウの色」にて「透明感を有効にする」のチェックを外すと、タスクバーに重なっても極端な性能劣化がないようです。
097ベースでフルスクリーン(ウインドウ最大化)するようにしたサンプルを作りましたので、透明感を外してお試し下さい。
tp://yyagi.com/DTXManiaGR_097_30666.zip
なお、VGAフルスクリーンに比べると性能は落ちています。従来通りの性能を維持するには、以前書いたようにBackBufferの作り方の変更等、描画ロジックを全面的に改める必要があります。
sf298yen Aeroでは常に３フレーム遅延するということですので、私はAeroテーマは使用していません。
「透明感を有効にする」はAeroテーマに付随するプロパティだと思うのですが、Aeroテーマを選択した上でのテスト、ということでいいのでしょうか？
Aeroを無効化なさっているのであれば、テスト不要です。ありがとうございました。
ここまでのまとめ
問題点: Win7で、NVIDIAのドライバを使用していると、フルスクリーン時大体3フレーム遅延している模様。
対策1: 解像度変更タイプのまま解決を図るなら、Direct3D9Exを使い、SetMaximumFrameLatencyを使うことで、1フレーム遅延にまでは追い込める。しかし0フレーム遅延にまでは持ち込めない。
→ 最初から1フレーム先の画面を計算して描画するようにするのが一番無難な対策のような気がしてきました。 更に、何フレーム先の画面を描画するようにするのかをCONFIGURATIONで設定できるようにすればよいかな。
対策2: 解像度は変更せず、画面をスケーリングして表示するやり方であれば、この問題は発生しない。しかし、タスクバーに描画領域が重なると、カクツキが発生する。
→ 最低限、BackBufferのサイズをウインドウサイズと一致させ、Flip時にスケーリングが発生しないようにする必要有り。また、Aeroをオフにして半透明描画を止めることで問題解決する場合もある。
最初から1フレーム先の画面を計算して描画するよりは、画面に表示している判定ラインの表示位置を上下に調整できたほうがいいですかね。
画面を目押しするタイプの方にとっては。
・・・アジャスト関係が３つに増えて分かりにくくなりますが、すべて原因と対策が違う以上、仕方ないですね。
判定ラインの表示位置を調整する機能について、#31602 に株分けしました。
対策2: 解像度は変更せず、画面をスケーリングして表示するやり方であれば、この問題は発生しない。しかし、タスクバーに描画領域が重なると、カクツキが発生する。
この対応をRel100より取り込んでいるのですが、先日104で動作確認したところ、カクツキの現象がなくなっていました。
.NET Frameworkのバージョンを変更したからでしょうか・・・？
とにかくうまく動いているようですので、本チケットは後日クローズします。各種遅延対策は別チケットにて。(含 判定ライン表示上下機能 #31602)
Fork
Win7で、NVIDIAのドライバを使用していると、フルスクリーン時大体3フレーム遅延している模様。
ウィンドウ状態の時は問題ない。
#28914の109～111番目のコメントより、チケットを株分けした。