二维平台：为什么物理依赖于帧率？
“超级肉男孩”是最近出现在PC上的一款难以应对的平台游戏，需要出色的控制和像素完美的跳跃。 游戏中的物理代码取决于帧率，该帧率被锁定在60fps; 这意味着如果你的电脑无法全速运行游戏，那么物理效果会变得疯狂，导致你的角色运行速度较慢并且落地。 此外，如果vsync关闭，游戏运行速度非常快。
那些有2D游戏编程经验的人可以帮助解释为什么游戏以这种方式编码？ 不会以恒定速率运行物理循环是更好的解决方案吗？ （实际上，我认为一个物理循环用于游戏的某些部分，因为无论帧速率如何，有些实体会继续正常移动，另一方面，您的角色的运行速度正好是[fps / 60]。）
这个实现困扰我的是游戏引擎和图形渲染之间的抽象损失，这取决于系统特定的东西，如显示器，图形卡和CPU。 如果无论出于何种原因，您的计算机无法处理vsync，或者无法以60fps的速度运行游戏，它将会非常壮观。 为什么渲染步骤会以任何方式影响物理计算？ （现在大部分游戏都会减慢游戏速度或跳过帧。）另一方面，据我所知，NES和SNES上的老派平台玩家在他们的控制和物理上依赖于固定的帧速率。 为什么会这样，并且有可能以这种方式创建一个patformer，而不会产生framerate依赖性？ 如果将图形渲染与引擎的其余部分分开，是否会有精度损失？
谢谢，如果问题很混乱，我很抱歉。
没有理由为什么物理学应该取决于帧率，这显然是一个糟糕的设计。
我曾试图理解人们为什么这样做。 我对公司的另一个团队编写的游戏进行了代码审查，我从一开始就没有看到它，但他们在代码中使用了大量硬编码值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;
所以他们从所有代码中删除了所有硬编码的值，并使用了FPS常量。 他们的动机：现在，如果我需要将游戏放在只能做10 FPS的设备上，我所需要做的就是将FPS常数设置为10，游戏将顺利进行。
最后，抱歉写了这么长的信息，但我想强调，任何人都会做这样的事情的唯一原因是糟糕的设计。
这里有一个很好的解释，为什么你的时间步应该保持不变：http://gafferongames.com/game-physics/fix-your-timestep/
另外，根据物理引擎的不同，当时间步长改变时，系统可能会变得不稳定。 这是因为在帧之间缓存的一些数据是依赖于时间步长的。 例如，迭代解算器的初始猜测（这是解决约束的方式）可能与答案相距甚远。 我知道Havok（很多商业游戏使用的物理引擎）是这样，但我不确定SMB使用哪个引擎。
几个月前还有一篇游戏开发者杂志的文章，说明了如何以不同的帧速率实现不同的最大高度，以相同的初始速度但不同的时间步长跳转。 有一个来自游戏（托尼霍克？）的支持趣闻，当在NTSC版本的游戏中运行而不是PAL版本时（由于帧率不同），可以进行某种跳跃。 抱歉，我目前无法找到此问题，但如果需要，我可以稍后尝试将其挖掘。
他们可能需要足够快地完成游戏，并决定在当前的实施中他们将覆盖足够的用户群。
现在，如果在开发过程中考虑它，要改造独立性并不是那么难，但我想他们可能会遇到一些陡峭的漏洞。
我认为这是没有必要的，我已经看到过它（一些早期的3D游戏使用了同样的东西，如果你看着天空，游戏速度更快，如果你看着地面，速度会更慢）。
它只是糟透了。 如果可以的话，请让开发人员了解它并希望它们对其进行修补。
链接地址: http://www.djcxy.com/p/60411.html上一篇: 2D platformers: why make the physics dependent on the framerate?