我有一个 OpenGL 课程练习，用几个对象的简单动画编写游戏
在与我的合作伙伴讨论我们的设计选项时，我们意识到对于动画的工作方式，我们有两个主要选择，要么
通常应该首选的方法是什么？有人对这两种方法都有具体经验吗？
【问题讨论】：
尽可能快地渲染和计算以获得最大帧速率（由垂直同步限制）
不要使用计时器，它们在 Windows 上
此外，如果您想保持稳定，请在时间步长上使用上限/下限，如果帧需要几秒钟才能渲染（另一个进程访问磁盘？）则进入慢动作或跳过如果您在 10 毫秒内获得其中两个，请更新。
更新 （因为这是一个相当流行的答案）
我通常更喜欢有一个固定的时间步长，因为它使一切更加稳定。大多数物理引擎对变化的时间都非常健壮，但其他东西，如粒子系统或各种更简单的动画甚至游戏逻辑，在让所有东西都以固定时间步长运行时更容易调整。
更新2 （因为我得到了 10 个赞；）
为了在长时间运行（>4 小时）内进一步保持稳定性，您可能需要确保不使用浮点数/双精度数来计算较大的时间差，因为这样做会丢失精度，并且游戏的动画/物理会遭受。请改用定点（或基于 64 位微秒）整数。
有关毛茸茸的细节，我建议阅读 Tom Forsyth 的 A matter of precision。
【讨论】：
阅读this page 了解游戏循环。
简而言之，设置一个计时器：
以固定频率（例如每 25 毫秒 = 1 秒/40 帧/秒）更新游戏状态。这包括游戏对象的属性、输入、物理、AI 等。我称之为 Model 和 Controller。对固定更新率的需求来自于太慢或太快的硬件上可能出现的问题（阅读文章）。一些物理引擎也喜欢以固定频率更新。
尽快更新游戏的框架（图形）。那就是视图。这样，您将提供流畅的游戏。您还可以启用垂直同步，以便显示器等待显卡（通常为 60 fps）。
因此，循环的每次迭代，您都要检查是否应该更新模型/控制器。如果晚了，请更新，直到它们是最新的。然后，更新一次框架并继续循环。
棘手的部分是，由于更新速率不同，在快速硬件中，视图会在模型和控制器之前更新几次。因此，您应该根据“如果游戏状态已更新，它们将在哪里”插入游戏对象的位置。真的没那么难。
您可能需要维护两种不同的数据结构：一种用于模型，另一种用于视图。例如，您可以为模型创建一个场景图，为您的视图创建一个 BSP 树。
【讨论】：
第二种方法是我的首选方法，因为计时器通常不像您想象的那么准确，并且具有事件处理系统的所有延迟和开销。考虑时间间隔将使您的动画具有更加一致的外观，并且在帧速率下降时保持稳健。
话虽如此，如果您的动画基于物理模拟（例如刚体或布娃娃动画），那么为您的物理设置一个固定的更新间隔可以大大简化实现。
【讨论】：
选项 2 是首选。它将在不同性能的硬件上很好地扩展。
《Game Programming Gems 1》这本书有一章正好涵盖了您需要的内容：
【讨论】：
使用第二种方法。为我的高级项目做了一个游戏，根据经验，不能保证你的逻辑会在计时器要触发时完成处理。
【讨论】：
我很想使用循环，因为它会尽可能快地渲染（即在您的物理计算完成后立即）。如果您在计算中遇到任何减速，这可能会更加稳健，这将导致计时器触发开始排队。但是，在出现这种减速的情况下，您可能必须对更新之间计算的时间步长设置一个上限，因为您的物理引擎可能会因时间跳跃过大而变得不稳定。
【讨论】：
我建议将系统设置为处理从外部传入的“增量”。
当我这样做时，在动画格式中，我将所有内容都基于实时值。我传入的增量是 1 / 30 秒，但它可以是任何东西。使用此系统，您可以获得第一个或第二个选项，具体取决于您是否传入固定增量，或者是否传入自上一帧以来经过的时间量。
至于哪个更好，这取决于你的游戏和你的要求。理想情况下，您的所有系统都将基于相同的增量，以便您的物理与动画相匹配。如果您的游戏完全丢帧，并且您的所有系统都使用可变 delta，我建议可变 delta 是两种解决方案中更好的最终用户体验解决方案。
【讨论】：