RPGツクールVXAceの網

RPGツクールVXAceの製作過程で気が付いたことをメモする。

動作環境と解像度（３）解像度の選択

処理負荷(waitで擬似再現)とフレームレートの関係

Windows7 Core-i5 670 3.5GHz

f:id:kazamit:20120608213536p:plain

Graphics.updateのあとにsleep を入れることにより、擬似的に処理負荷が高まったことを想定して各解像度でのＦＰＳを調査。ゲーム状態は、サンプルマップ１の雪原でキャラを歩行させた状態。

どの解像度でも、9ms以内ならばスキップは発生しなかった。14ms以上の処理がかかると、ゲームにストレスがたまるレベルでスキップする。16ms以上は、ほぼ全時間が計算処理に回されている状態でがくつきが大きい。

結論的には、640*480でも十分実用的なＦＰＳが出ると思われる。ＣＰＵが最新に近いとは言え、現状マップ歩行では描画以外の処理で１msもかかっておらず、演算能力が半分になってもおそらくフレームスキップは起きない。

ここでやっと本題だが、解像度を640*480とデフォルトの544*416どちらにするか考える。

◆640*480

  • ○フルスクリーンが一杯まで入る
  • ○領域が広いため表示情報多い（マップ、メニュー画面）
  • ×起動時はウィンドウサイズが一瞬544*416（回避不能）
  • ×メニューなどのレイアウト変更必要

◆544*416

  • ○デフォルトのシステムをほぼ流用できる
  • ○動作はやや軽快
  • ×フルスクリーン時上下黒帯
  • ×作業領域狭い

作業領域（視野）が広いのはプレイのしやすさにもつながるので640で進めてみる。

 

動作環境と解像度（２）画面更新タイミング

検証をすすめるうちに、Graphics.updateの詳細が明らかになってきた。

Graphics.updateの機能は、ヘルプによると

ゲーム画面を更新し、時間を 1 フレーム進めます。このメソッドは必ず定期的に呼び出す必要があります。

だが、より詳細に書くと

メモリ上のバックバッファ描画データ（多分ビットマップ）をゲームウィンドウに描画し、フレームレート調整のための更新タイミング時刻に到達するまでウェイトを行う。Graphics.frame_count は１増やされる。

という感じになる。たとえば、Graphics.frame_rateが60（デフォルト）の場合、１フレームの更新にかかる時間は約16.66msになる。このとき、たとえばGraphics.update以外の処理に10msかかってからGraphics.updateが呼ばれたとすると、Graphics.updateは約6.6msのウェイトを行う（内部的には１ms刻みでコントロールしているようだ。16.666を刻みたい場合、16,17,17,16,17,17とすれば平均16.666になる)。Graphics.update自体に16.66ms以上かかると本末転倒だが、おそらく画面をウィンドウに描画するという処理はＣＰＵの能力にもよるがそこまで長い時間はかからないという想定だろう。

こうして1フレーム内に軽い処理が入った場合でも重い処理が入った場合でも、極力固定のタイミングで画面とframe_countを更新することで、正確なゲーム時間と適切なＣＰＵ使用率を保っているようである。

そういう理由から、たとえばGraphics.frame_rate = 120 にすると、ゲームのエフェクトや入力検出全てが60FPSのときに対して倍速になるため、敵の行動が早すぎて表示が読み切れなかったり、下のコマンドに行こうとして下を押しっぱなしにすると想定以上に大きく下に移動してしまったりする。60FPSからの変更が推奨されないというのはこのようなズレを意図してのことと思われる。ちなみに「画面のちらつきをおさえる」をチェックしている場合は、画面更新は60FPS(ディスプレイのリフレッシュレート）に合うが、内部計算はGraphics.frame_rate の頻度で実施される。

ところで、Graphics.update以外の処理（計算とかバックバッファへの描画とか）が16.666ms以上かかってしまった場合、画面は更新されず次のフレームの処理が先に実施される。俗にフレームスキップと呼ばれる現象で、画面のスムーズさを犠牲にして内部計算を遅らせないようにする機能である。

例えば、Graphics.updateのあとにsleep 0.020(20ms)を入れると画面が一切更新されなくなるのか、といえばそうではない。５～１０ＦＰＳくらいは出ているので、ゲームを認識できるレベルでの更新は行うようである。

次回は、解像度とフレームスキップが起こる処理負荷の関係について調べる。

動作環境と解像度（１）

ツクールＸＰの網に倣い、このブログに製作で気が付いたことをメモしていくことにする。

 

ＶＸはRGSS3(RUBY)の処理効率が上がったため動作が軽くなったと考えられるが、どの程度軽くなったか検証している。とりあえずこれが動けばほぼ全てのユーザーが動くであろうpentium3 -933MHz メモリ512MBでトライした結果、マップの通常歩行で大体20～30FPS出ていた。ツクールXPが10FPS台だったと思うので、かなり良好。一般的なＰＣなら間違いなく60FPS出せるだろう。

 

ゲームのフレームレート(Graphics.frame_rate)を120FPSに変更して解像度を変化させたときの動作検証を試みる。ヘルプにあるとおりGraphics.frame_rateを変更することは推奨されない。ゲームの全グラフィック処理がフレーム基準で設定されているため、フレームレートを倍にすると多くのエフェクトが２倍速で実行されてしまう。しかも、画面のちらつきを抑えるオプションを有効にした場合、結局垂直同期を取るため60ＦＰＳ（多分画面のリフレッシュレート）と同期してしまい、滑らかさという点ではあまり意味が無くなる。

 

そういうわけで、今回は検証のためにだけ、試験的にフレームレートを120に変更して実施する。 

単純計算ではデフォルトの544*416pixは画素数226,304。

640*480は307,200。

この差は35.7％あり、仮に544*416でジャスト60FPSの能力だったと仮定すると、640*480では44FPS程度に落ちる。ただし実際には内部計算などの別の処理にＣＰＵを使っているのでこういうことにはならないと思うが、無視できる量ではなさそう。

 

続きは明日に。