【发布时间】：2012-07-20 23:07:26
【问题描述】：
在开发游戏一段时间后，我接触到了可变帧速率（您可以计算自上次滴答以来经过了多少时间并相应地更新演员的移动）和固定帧速率（您可以在其中计算已经过去了多少时间，然后选择勾选固定的时间或睡眠直到下一个窗口到来）。
哪种方法最适合特定情况？请考虑：
- 迎合不同的系统规格；
- 易于开发/维护；
- 易于移植；
- 最终表现。
【问题讨论】：
标签： frame-rate
【发布时间】：2012-07-20 23:07:26
【问题描述】：
我倾向于使用可变帧率模型，但在内部，一些系统是在固定的时间步长上打勾的。使用时间累加器很容易做到这一点。物理系统是一个最好在固定时间步长上运行的系统，如有必要，每帧可勾选多次以避免稳定性损失并保持模拟流畅。
一段代码来演示累加器的使用：
const float STEP = 60.f / 1000.f;
float accumulator = 0.f;
void Update(float delta)
{
accumulator += delta;
while(accumulator > STEP)
{
Simulate(STEP);
accumulator -= STEP;
}
}
这无论如何都不是完美的，但它提供了基本思想 - 有很多方法可以改进这个模型。显然，当输入帧速率非常慢时，需要解决一些问题。然而，最大的优势在于，无论增量有多快或多慢，模拟都在“玩家时间”中以平稳的速度移动 - 这是用户会察觉到任何问题的地方。
通常我不涉及图形和音频方面的东西，但我认为它们不会像物理、输入和网络代码那样受到影响。
【讨论】：
-
嗯，这是一个与帧率不同的滴答率的良好开端（通常帧率会更高）。然后，您必须解决如何从单个世界状态中绘制多个（不同）帧（由不太频繁的滴答率更新）的困境。一个常见的解决方案是让你的渲染滞后一整个帧，然后在最后计算的世界状态和之前的世界状态之间的一个插值位置渲染所有对象。
似乎大多数 3D 开发人员更喜欢可变 FPS：Quake、Doom 和 Unreal 引擎都根据系统性能进行放大和缩小。
- 至少你必须补偿太快的帧速率（不像 80 年代的游戏在 90 年代运行，太快了）
- 无论如何，您的主循环都应该通过时间步长进行参数化，只要它不是太长，像 RK4 这样的体面的积分器应该可以顺利处理物理 某些类型的动画（关键帧精灵）可能很难参数化。网络代码也需要很智能，例如避免拥有更快机器的玩家射出太多子弹，但无论如何都需要进行这种节流以补偿延迟（动画参数化也有助于隐藏网络延迟）
- 需要针对每个平台修改计时代码，但这是一个小的本地化更改（尽管有些系统很难精确计时，Windows、Mac、Linux 似乎都可以）
- 可变帧速率可实现最佳性能。固定帧速率可实现一致的性能，但永远不会在所有系统上达到最大值（这似乎是任何严肃游戏的阻碍）
如果您正在编写一个性能很重要的网络 3D 游戏，我不得不说，咬紧牙关并实现可变帧速率。
如果它是一款 2D 益智游戏，您可能可以使用固定帧速率，可能会为超慢速计算机和未来几年的模型稍微参数化。
【讨论】：
作为用户，我希望更频繁地看到的一个选项是，当帧速率在一定范围之外发生变化时，动态更改细节级别（在广义上，而不仅仅是技术意义上）。如果您以 5FPS 进行渲染，请关闭凹凸贴图。如果您以 90FPS 进行渲染，请稍微增加一些花里胡哨，并为用户提供一些更漂亮的图像来浪费他们的 CPU 和 GPU。
如果操作正确，用户应该在游戏中获得最佳体验，而无需进入设置屏幕并自行调整，作为关卡设计师，您应该不必担心保持多边形数量相同跨越不同的场景。
当然，我是作为游戏用户这么说的，而不是一个认真的人——我从来没有尝试过写一个不平凡的游戏。
【讨论】：
我遇到的可变长度帧时间的主要问题是浮点精度，可变帧时间会让你惊讶于它们对你的影响。
例如，如果您将帧时间 * 速度添加到某个位置，并且帧时间变得非常小，并且位置较大，则您的对象可能会减慢或停止移动，因为您的所有增量都因精度而丢失.您可以使用单独的错误累加器来弥补这一点，但这很痛苦。
拥有固定的（或至少是帧长度的下限）帧时间允许您控制需要考虑多少 FP 错误。
【讨论】：
我的经验仅限于一些简单的游戏（使用 SDL 和 C++ 开发），但我发现实现静态帧速率非常容易。您在玩 2d 或 3d 游戏吗？我会假设更复杂的 3d 环境会从可变帧速率中受益更多，并且难度会更大。
【讨论】：