那些有2D游戏编程经验的人是否有助于解释为什么游戏以这种方式编码？以恒定速率运行的物理循环不是更好的解决方案吗？ （实际上，我认为物理循环用于游戏的某些部分，因为无论帧速率如何，一些实体都会继续正常移动。另一方面，你的角色运行速度恰好[fps / 60]。）< / p>
让我对这个实现感到困扰的是游戏引擎和图形渲染之间的抽象丢失，这取决于系统特定的东西，如显示器，显卡和CPU。无论出于何种原因，如果您的计算机无法处理vsync，或者无法以60fps的速度运行游戏，那么它将会非常突破。为什么渲染步骤会以任何方式影响物理计算？ （现在大多数游戏要么放慢游戏速度，要么跳过帧。）另一方面，我知道NES和SNES上的老式平台游戏依赖于固定帧速率来控制和物理。为什么会这样，并且可以在没有帧率依赖性的情况下创建一个变形器？如果将图形渲染与引擎的其余部分分开，是否一定会损失精度？
谢谢你，如果这个问题令人困惑，我很抱歉。
答案 0 :(得分：7)
没有理由说物理学应该依赖于帧率，这显然是一个糟糕的设计。
我曾经试图理解为什么人们会这样做。我对公司另一个团队编写的游戏进行了代码审查，我从一开始就没有看到它，但他们在代码中使用了大量硬编码值17。当我在显示FPS的调试模式下运行游戏时，我看到它，FPS正好是17！我再次查看代码，现在很清楚：程序员认为游戏总是具有17 FPS的恒定帧速率。如果FPS大于17，他们会睡觉以使FPS正好是17.当然，如果FPS小于17，他们什么也没做，游戏就是疯了（就像在2 FPS下玩并驾驶一辆车一样）游戏中，游戏系统提醒我：“太快了！太快了！”。）。
所以我写了一封电子邮件，询问为什么他们硬编码这个值并使用它们的物理引擎，他们回答说这样他们让引擎更简单。我再次回复，好吧，但如果我们在一台无法达到17 FPS的设备上运行游戏，那么你的游戏引擎运行起来非常有趣，但并不像预期的那样。他们说这将解决问题，直到下一次代码审查。
在3或4周后我得到了一个新版本的源代码，所以我真的很想知道他们用FPS常数做了什么，所以我要做的第一件事就是在17之后搜索代码并且只有几个匹配，但其中一个不是我想看的东西：
final static int FPS = 17;
因此，他们从所有代码中删除了所有硬编码的17值，并使用了FPS常量。他们的动机：现在如果我需要将游戏放在只能达到10 FPS的设备上，我需要做的就是将FPS设置为10并且游戏将顺利运行。
总而言之，很抱歉写了这么长的消息，但我想强调一下，任何人都会做这样的事情的唯一原因就是糟糕的设计。
答案 1 :(得分：2)
这里有一个很好的解释为什么你的时间步长应该保持不变：http://gafferongames.com/game-physics/fix-your-timestep/
此外，根据物理引擎，当时间步长发生变化时，系统可能会变得不稳定。这是因为帧之间缓存的某些数据与时间步长有关。例如，迭代求解器的起始猜测（解决约束的方式）可能与答案相差甚远。我知道Havok（许多商业游戏使用的物理引擎）都是如此，但我不确定SMB使用哪种引擎。
几个月前Game Developer Magazine也发表了一篇文章，说明了在不同的帧速率下，不同的最大高度如何实现具有相同初始速度但不同时间步长的跳跃。有一个来自游戏的支持轶事（Tony Hawk？），当在NTSC版本的游戏上运行而不是PAL版本时可以进行一定的跳转（因为帧速率不同）。对不起，我现在找不到问题，但如果你愿意，我可以试着稍后再挖掘它。
答案 2 :(得分：0)
他们可能需要足够快地完成游戏，并决定用当前的实现来覆盖足够的用户群。
现在，如果你在开发过程中考虑它，那么
我认为这是不必要的，我以前见过它（一些早期的3D-hw游戏使用相同的东西，如果你看着天空，游戏会变得更快，如果你看着地面，游戏会变慢）。 / p>
它很糟糕。关于它的开发人员的错误，并希望他们修补它，如果可以的话。