UPS und FPS - Was soll ich einschränken und warum?

Ich schreibe gerade ein Spiel mit C ++ und SDL2 und es gibt eine Sache, über die ich mich wundere - ist es sinnvoll, meine Frames pro Sekunde (FPS) und / oder meine Updates pro Sekunde (UPS) zu begrenzen?

Ich habe die Idee, dass Sie, wenn Sie die USV begrenzen, im Wesentlichen die Geschwindigkeit des Spiels steuern. Wenn sich der Spieler 1 Update pro Update bewegt und Sie es immer 30 Mal pro Sekunde aktualisieren, bewegt er sich mit einer Geschwindigkeit von 30 Pixel / s und Sie Wahrscheinlich wird auch die CPU entlastet, da die Anzahl der Berechnungen pro Sekunde abnimmt. Wenn Sie die FPS begrenzen, verringert sich die Anzahl der Drawcalls pro Sekunde, sodass Sie Ihre GPU entlasten. Ich hoffe, ich habe das alles richtig verstanden, wenn nicht, können Sie mich gerne korrigieren.

Meine Frage ist - was soll ich in meinem Spiel einschränken? FPS? UPS? Beide? Weder? Gibt es einen anderen, besseren Ansatz dafür? Wie wird das in den meisten Spielen gemacht und warum?

Antworten werden sehr geschätzt!

Ja, das macht Sinn.

Wie Sie sagten, wird das System weniger belastet, was für die Thermik und andere Anwendungen gut ist.

Allerdings ... Ihre Spielelogik sollte NICHT von den Updates pro Sekunde abhängen. Daher empfehle ich Ihnen, einen Blick auf die Deltatime zu werfen, um Ihr Spiel unabhängig von den Updates pro Sekunde zu machen.

Ich empfehle Ihnen, sich diese Frage anzuschauen. Es erklärt ziemlich gut, wie man es berechnet und verwendet. So erhalten und verwenden Sie die Deltazeit

Hoffe es hat geholfen!

Die beste Antwort ist: Es kommt darauf an .

Sie müssen keine einschränken

Updates : Wenn Ihre Updates nicht an eine Obergrenze gebunden sind, sollte die Spielelogik von einem Delta- Zeitbetrag abhängen , um zu vermeiden, dass das Spiel je nach Computer, auf dem es ausgeführt wird, schneller oder langsamer ausgeführt wird. Dies ist ein sehr verbreiteter Ansatz, der von vielen Spielen verwendet wird, aber nicht der einzige.

Rendern : Wenn das Rendern nicht an eine Obergrenze gebunden ist, wird der Framebuffer möglicherweise in einem unvollständigen oder fehlerhaften Zustand dargestellt, was zu Zerreißartefakten führt . Aus diesem Grund verwenden viele Spiele die vertikale Synchronisation (V-Sync).

Sie können beide einschränken

Updates : Einige Spiele verwenden feste Zeitschritte für einige oder alle Gameplay-Systeme. Dieser Ansatz funktioniert genau so, wie Sie es beschrieben haben. Die Anzahl der Updates pro Sekunde ist auf eine Obergrenze begrenzt, um sicherzustellen, dass sich die Dinge auf einem erstklassigen Computer nicht zu schnell bewegen. Dadurch entfällt die Notwendigkeit eines Delta-Timings. Einige Anwendungen sind mit festen Zeitschritten besser, andere mit Delta-Timing. Die Wahl des Ansatzes hängt ganz davon ab, was genau Sie erreichen möchten. Das Online - Buch GameProgrammingPatterns hat ein eigenes Kapitel gewidmet Spiel Schleifen , dass Berührungen auf beiden Architekturen.

Rendern : Frames Per Second sollten auf eine Obergrenze eingestellt werden, um das oben erwähnte Rissproblem zu vermeiden. Ihre Anwendung sollte dies jedoch nicht manuell mit einer CPU-Sperre versuchen. Aktivieren Sie stattdessen die V-Synchronisierung und lassen Sie die zugrunde liegende Hardware mit der Aktualisierungsrate des Monitors synchronisieren. Auf diese Weise ist Ihr Spiel vorwärtskompatibel mit zukünftigen Monitoren, die möglicherweise auf einer viel höheren Frequenz als den derzeit üblichen 60 Hz arbeiten. Es ist auch erwähnenswert, dass viele Spieler, insbesondere diejenigen, die sich mit Benchmarking beschäftigen, es immer noch vorziehen, ohne V-Sync zu laufen, um die höchstmögliche Bildrate zu ermöglichen. Es ist daher sinnvoll, die Funktion zur Laufzeit zu aktivieren oder zu deaktivieren.

Was Sie nicht einschränken sollten

Wenn Ihr Spiel einen auf Abfragen basierenden Ansatz für Benutzereingaben verwendet, z. B.: Ruft eine getInput()Art auf, um die Controller-Zustände während des Aktualisierungsschritts zu aktualisieren, ist dies besser, wenn nicht eingeschränkt. Oder wenn begrenzt, dann auf eine sehr hohe Obergrenze setzen. Je öfter Sie Benutzereingaben abfragen und darauf reagieren, desto reaktionsschneller und flüssiger wird sich das Spiel "anfühlen". Die sogenannten 60-Hz-Spiele, von denen wir heutzutage hören, aktualisieren nicht die KI und alle Weltzustände mit dieser Geschwindigkeit, einige rendern nicht einmal so schnell, aber sie fragen die Controller-Eingabe mindestens 60 Mal pro Sekunde ab und aktualisieren den Spieler-Avatar entsprechend. Zugegeben, dies ist nur für schnelllebige Actionspiele wirklich relevant.

Es gibt zwei Beiträge, die Sie sich ansehen möchten:

Korrigieren Sie Ihren Zeitschritt

Interpoliertes Physik-Rendering

Ich finde die Diskussionen auf den Posts wirklich von unschätzbarem Wert, aber meiner Meinung nach ist es am sinnvollsten, wenn das Spiel eine wichtige Menge an Physiksimulation enthält. Zusammenfassend ist die Idee, dass die Simulation einen festen Zeitschritt haben sollte (andernfalls könnte die Physik an einem Punkt explodieren, an dem das Delta zu groß ist), während dem Rendern die Freiheit gegeben werden sollte, mit der maximal möglichen Geschwindigkeit zu laufen. Um beide zu synchronisieren (die Simulation und das Rendern), wird der Renderstatus durch einen Faktor interpoliert, der davon abhängt, wie weit die Simulation von der folgenden Aktualisierung entfernt ist (denken Sie daran, dass die Simulation behoben ist).

Ich hoffe es hilft.