UPSとFPS-何を制限する必要がありますか。その理由は何ですか。

現在C ++とSDL2を使用してゲームを作成していますが、疑問に思っていることが1つあります。毎秒のフレーム数（FPS）や毎秒の更新数（UPS）を制限することは理にかなっていますか？

UPSを制限すると、基本的にゲームの速度を制御できると思います。プレーヤーが1更新あたり1ピクセル移動し、常に毎秒30回更新する場合、30ピクセル/秒の速度で移動します。 1秒あたりの計算量が減るため、おそらくCPUも解放されます。FPSを制限すると、1秒あたりのドローコールの量が減少するため、GPUが軽減されます。そのすべてを正しく理解できていれば幸いです。そうでない場合でも、自由に修正してください。

私の質問は-私のゲームで何を制限すべきですか？FPS？UPS？どちらも？どちらでもない？これに対する別のより良いアプローチはありますか？これはほとんどのゲームでどのように行われ、その理由は何ですか？

回答は大歓迎です！

はい、それは理にかなっています。

あなたが言ったように、それはシステムへのより少ない負荷を作るでしょう、それはサーマルと他のアプリケーションのために良いです。

ただし...ゲームロジックは、1秒あたりの更新に依存するべきではありません。したがって、毎秒の更新からゲームを独立させるdeltatimeを確認することをお勧めします。

この質問をご覧になることをお勧めします。それはそれを計算して使用する方法をかなりよく説明しています。デルタタイムを取得して使用する方法

お役に立てば幸いです。

最良の答えは、次のとおりです。

どちらも制限する必要はありません

更新：更新が上限にバインドされていない場合、ゲームロジックは、実行されるマシンに応じてゲームの実行が速くなったり遅くなったりしないように、デルタ時間に依存する必要があります。これは多くのゲームで使用される非常に一般的なアプローチですが、それだけではありません。

レンダリング：レンダリングが上限にバインドされていない場合、フレームバッファーが不完全または誤った状態で表示され、ティアリングアーティファクトが発生する可能性があります。これが、多くのゲームが垂直同期（v-sync）を採用している理由です

あなたは両方を制限するかもしれません

更新：一部のゲームは、そのゲームプレイシステムの一部またはすべてに固定タイムステップを使用します。このアプローチは、説明したとおりに機能します。1秒間の更新数は上限に制限されており、一流のマシンで高速に動作しないようになっています。これにより、デルタタイミングが不要になります。一部のアプリケーションは、タイムステップが固定されている場合や、デルタタイミングの場合に適しています。どのアプローチを選択するかは、完全に達成しようとしていることに完全に依存します。オンラインブックGameProgrammingPatternsには、両方のアーキテクチャに関連するゲームループに特化した章があります。

レンダリング：前述のティアリングの問題を回避するために、1秒あたりのフレーム数を上限に設定する必要があります。ただし、アプリケーションは、CPUロックを使用して手動でこれを試行しないでください。代わりに、v-syncを有効にして、下にあるハードウェアをモニターのリフレッシュレートと同期させます。そうすることで、ゲームは、現在一般的な60Hzよりもはるかに高い周波数で動作する可能性のある将来のモニターと前方互換性があります。多くのゲーマー、特にベンチマークを行うゲーマーは、可能な限り最高のフレームレートを実現するために、v-syncなしで実行することを好むことにも注意する必要があります。したがって、実行時に機能を有効または無効にできるようにするのが賢明です。

制限してはいけないこと

ゲームがユーザー入力にポーリングベースのアプローチを使用している場合、たとえばgetInput()、更新ステップ中に一種のコントローラーを呼び出してコントローラーの状態を更新する場合、制限がない場合はこれが適しています。または制限されている場合は、非常に高い上限に設定します。ユーザー入力をクエリして操作する頻度が高ければ高いほど、ゲームの反応がよくなり、スムーズになります。最近聞いたいわゆる60HzゲームはAIとすべての世界の状態をその速度で更新していません。高速にレンダリングされないものもありますが、コントローラーの入力を少なくとも毎秒60回クエリし、それに応じてプレーヤーのアバターを更新します。これは、ペースの速いアクションゲームにのみ関連していると考えられます。

あなたが見てみたいかもしれない2つの投稿があります：

タイムステップを修正

補間された物理レンダリング

投稿に関する議論は非常に貴重だと思いますが、私の意見では、ゲーム内に重要な量の物理シミュレーションがある場合に最も理にかなっています。要約すると、アイデアには、シミュレーションに固定の時間ステップが必要です（そうでない場合、物理がデルタが大きすぎる場所で爆発する可能性があります）一方で、レンダリングには可能な最大レートで実行する自由を与える必要があります。両方（シミュレーションとレンダリング）を同期するために、レンダリング状態は、シミュレーションが次の更新からどれだけ離れているかに依存する係数によって補間されます（シミュレーションは固定されていることに注意してください）。

それが役に立てば幸い。