UPS和FPS-我应限制什么，为什么？

我目前正在使用C ++和SDL2编写游戏，我想知道一件事-限制每秒的帧数（FPS）和/或每秒的更新数（UPS）是否有意义？

我的想法是，如果您限制UPS，则基本上可以控制游戏的速度-如果玩家每次更新移动1px，并且您始终每秒更新30次，则他将以30px / s的速度移动，而您由于每秒的计算量减少，这也可能减轻CPU的负担。如果限制FPS，则每秒的调用次数会减少，因此可以减轻GPU负担。我希望我能正确理解所有这些内容，如果不能，请随时纠正我。

我的问题是-我应该在游戏中限制什么？FPS？UPS？都？都不行 有另一种更好的方法吗？在大多数游戏中这是如何完成的，为什么？

答案非常感谢！

是的，确实有道理。

正如您所说，它将减轻系统的负载，这对散热和其他应用程序很有用。

但是...您的游戏逻辑不应依赖于每秒的更新。因此，我建议您来看看deltatime，它可以使您的游戏不受每秒更新的影响。

我建议您看一下这个问题。它很好地解释了如何计算和使用它。如何获取和使用时间增量

希望能有所帮助！

最好的答案是：这取决于。

您不必限制任何一个

更新：如果您的更新没有上限，则游戏逻辑应取决于增量时间量，以避免根据运行计算机的速度更快或更慢地运行游戏。这是许多游戏使用的非常普遍的方法，但它并不是唯一的方法。

渲染：如果渲染没有上限，则帧缓冲区可能以不完整或错误的状态呈现，从而导致撕裂的伪影。这就是为什么许多游戏都采用垂直同步（v-sync）的原因

您可能会限制两者

更新：某些游戏在其部分或全部游戏系统中使用固定的时间步长。正如您所描述的，此方法有效。每秒更新的数量限制在上限，以确保在一流的计算机上运行不会太快。这消除了对增量定时的需要。在固定的时间步长下，某些应用程序更好，而在增量定时下，某些应用程序则更好。选择哪种方法将完全取决于您要实现的目标。在线书籍GameProgrammingPatterns有一章专门介绍了涉及这两种架构的游戏循环。

渲染：应该将每秒帧数设置为上限，以避免上述撕裂问题，但是，您的应用程序不应尝试通过某些CPU锁定来手动执行此操作。而是启用v-sync，并使底层硬件与监视器的刷新率同步。这样，您的游戏将与未来的显示器向前兼容，后者可能会以比目前常见的60Hz更高的频率运行。还值得注意的是，许多游戏玩家，尤其是那些进行基准测试的玩家，仍然更喜欢在不使用v-sync的情况下运行，以实现尽可能高的帧频。因此允许在运行时启用或禁用该功能是明智的。

你不应该限制的

如果您的游戏使用基于轮询的方法来输入用户信息，例如：getInput()在更新步骤中调用a 来更新控制器状态，则更好（如果不受限制）。或者如果受限制，则设置为很高的上限。您查询用户输入并对其进行操作的频率越高，游戏“响应”的响应速度和流畅度就越高。我们今天听到的所谓的60Hz游戏并没有以这种速度更新AI和所有世界状态，有些甚至还没有达到那么快的速度，但是它们每秒至少查询控制器输入60次并相应地更新玩家头像。当然，这仅与快节奏的动作游戏有关。

您可能要看两篇文章：

修正您的时间表

插值物理渲染

我发现有关帖子的讨论确实非常宝贵，但是我认为，当游戏中进行大量物理模拟时，这才是最有意义的。总而言之，该想法是模拟应具有固定的时间步长（否则，物理量可能会在增量太大的某个点处爆炸），而应该给渲染自由以最大可能的速率运行。为了同步（模拟和渲染），将渲染状态插入一个因子，该因子取决于模拟与后续更新之间的距离（请记住模拟是固定的）。

希望能帮助到你。