大きなFPSと一貫したFPS


8

ゲームのフレームレートを最適化するとき、大きなFPSに焦点を当てるべきか、一貫したフレームレートに焦点を当てるべきか。

これはよく争われる問題ですので、どちらが良いか尋ねていません

それぞれの長所と短所は何ですか?
どの状況でどちらが優先されますか?

また、注意:入力のポーリング/処理、物理、およびゲームの更新レートは、フレームレートとは無関係です。FPSが影響するのは、画面がレンダリングされる頻度だけです。

回答:


10

もちろん、これは主観的なものですが、速度よりも一貫性がゲームプレイにとってはるかに重要だと思います。

基本的に、ゲームが一貫していて、プレイするのが楽しく、不快でない場合、プレイヤーは遅いフレームレートを我慢します。しかし、ゲームが完全に揺るがしても、それが破裂して人々に頭痛の種を与えたり、物事をコントロールできなくなったりすると、イライラしてプレイを停止します。

そう...

設計と開発全体で一貫したFPSに焦点を当てます。

ゲームがほぼ終了し、バグ修正などを気にせずにパフォーマンスを向上させる時間がある場合は、より高速な(ただし一貫性のある)FPSに焦点を当てます。

パフォーマンスを向上させる1つの方法は、ポーリングではなく、コールバック/デリゲート/割り込み(言語/プラットフォームによって異なります)を使用することです。


9
もう1つの簡単な注意:プログラムオブジェクトの速度は、「...フレームあたり」ではなく、「...秒あたり」です。ほぼ均一なFPSが得られたとしても、多少の変動があり、オブジェクトを「1秒あたり10フィート」移動すると、「フレームあたり0.1フィート」(100FPSを想定)よりも効果的です。フレーム時間が少しずれている場合。
Olie

13

あなたがすべきこと:

  • ゲームロジックを固定フレームレートにロックする
  • 可能な限り高速でグラフィックをレンダリングする

そうすれば、フレームレートが下がっても入力ラグは発生せず(私はあなたを見ているだけで、原因2)、フレームレートが高くなりすぎた場合(90年代のゲームを考えてみてください)、ゲームはプレイ不能になりません。

ここに私がそれをする方法があります:

s_PhysicsCurrent = GetTickCount();
float delta = (float)(s_PhysicsCurrent - s_PhysicsStart);
s_PhysicsStart = s_PhysicsCurrent;

s_PhysicsTime += delta;

while (s_PhysicsTime > ONEFRAME)
{
    // Update
    Game::Tick(ONEFRAME);

    // Clear input
    Keyboard::Clear();
    Mouse::Clear();

    s_PhysicsTime -= ONEFRAME;
}

s_Window->Clear();

Game::Render();

s_Window->Swap();

基本的に、ロジックを実行するフレームの「スタック」を収集し、それらの間を完全に補間できます。


2

少なくとも2つの実行スレッドがあり、レンダリングは独自のスレッドで行われているようです。その場合は、実際には2つのフレームレートを考慮する必要があります。両方をできるだけ速くしたいでしょう。ただし、作成するゲームの種類によっても異なります。

フレームレートの小さな低下が対戦相手にアドバンテージを与える可能性がある、一人称シューティングゲームを構築していますか?その場合、平均fpsが十分に高いことを確認する必要がありますが、最悪の場合のフレーム時間も心配する必要があります。ボードゲームを構築していますか?その場合、時々起こるフレーム時間の急増は、ユーザーエクスペリエンスを停止させることにはなりません。

私自身のゲームでは、私のプロセスは通常次のようなものです:

  • コードでプロファイラーを実行する
  • 平均フレームレートを見てください。平均が低すぎる場合は、低速のものを最適化して平均fpsを上げます。
  • 平均fpsが十分に高くなったら、最悪のフレーム時間(計算時間またはレンダリング時間に大きなスパイクが見られるフレーム)を探します。これらの最悪のシナリオを最適化して、最悪のフレーム時間を改善してください。

ほとんどの場合30 fpsで、10秒ごとに200ミリ秒に急上昇すると、問題が発生します。ただし、平均15 fpsの場合は、最初に平均fpsを上げてください。

したがって、短い答えはおそらく、最初にユーザーエクスペリエンスに最大の改善をもたらすものを最適化することです。


2

FPSを一定の数にロックすると、次のことが可能になります。

  • 滑らかな外観を維持する
  • アニメーションを線形時間で実行し続ける、物理オブジェクトをフレーム間で一定の速度で落下させる、など。
  • ただし、FPSのロックの最も便利な部分は、いくつかのダウンタイムがあるフレームで、ガベージコレクション、マップの次の領域でのストリーミングの作業など、他の作業を行うことができ、レンダリング時にいくらかの余裕があることです。大きくて光沢のあるもの、または箱の山を倒すとき。

+1:2つ目の箇条書きには同意しません。落下ブロックは、それが6回または60描かれているかどうか画面を横断する1秒を要する
deft_codeを

2
正解です。ドローの間隔が異なるため、ボックス内のように、ある位置から別の位置にジャンプするようには見えません。滑らかなモーションは、可変時間ステップによって引き起こされる散発的なモーションよりも優先されます。
Sean James

1

どちらも。理想的には、一貫して毎秒60フレーム以上です。現実的には、一貫して毎秒30フレーム以上。1秒あたり30フレーム未満で、プレーヤーのパフォーマンスに影響を与え始めます(私はFPS / twitchベースのゲームを考えていますが、ストラテジーゲームはおそらくそれ以下でうまくいくでしょう)。

あなたが本当にどちらか一方を言う必要があるなら、私は一貫して行きます。フレームレートを保証できる場合は、保証されたフレームレートを高くすることに集中できます。


1

大きいほど常に良いですが、:

一貫性のないフレームレートは、乗り物酔いにつながる可能性があります。

(彼のフレームレートが20から60の間で10秒間ジャンプしたとき、内部テスターに​​投げられました。)


3
テスターがぶら下がっていなかったと確信しています
Sam Harwell、2010

0

あなたは一貫したより大きなFPSの両方を望んでいると思います。(リフレッシュレートにより)グラフィックが滑らかであるほど良いです。30FPSを下回ると、ユーザーはジッターに気づき始め、アクションへの応答時間の不足に苛立ちます。



-4

答えは1つだけです。つまり、開発中は常に高い状態を保ち、ダウンが最も低いスパイクまで下がると、ゲームは安定した流れに陥ります。私はコードに座っています。コードドラゴンの秘密の方法であるため、コードはそのまま残ります。/ Eyhe


どうして?「最低スパイク」とは何ですか?
Anko

3
-1これは答えではありません。それはある種のヴォーゴン詩です。
MichaelHouse
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.