2D 平台游戏：为什么物理取决于帧速率？
“超级食肉男孩”是一款难度较高的平台游戏，最近推出了 PC 版，需要出色的控制和像素完美的跳跃。游戏中的物理代码取决于帧速率，帧速率锁定为 60fps；这意味着，如果您的计算机无法全速运行游戏，物理效果将变得疯狂，导致（除其他外）您的角色跑得更慢并掉到地上。此外，如果垂直同步关闭，游戏运行速度会非常快。
那些有 2D 游戏编程经验的人可以帮助解释为什么游戏是这样编码的吗？以恒定速率运行的物理循环不是更好的解决方案吗？ ，某些实体都会继续正常移动。另一方面，你的角色运行速度与 [fps/60] 完全相同。）
（实际上，我认为游戏的某些部分使用了物理循环，因为无论帧速率如何 这种实现让我困扰的是游戏引擎和图形渲染之间抽象的丢失，这取决于特定于系统的东西，如显示器、显卡和 CPU。如果出于某种原因，您的计算机无法处理垂直同步，或者无法以 60 fps 的速度运行游戏，那么游戏就会严重崩溃。为什么渲染步骤会以任何方式影响物理计算？ （现在的大多数游戏要么会减慢游戏速度，要么会跳帧。） 另一方面，我知道 NES 和 SNES 上的老式平台游戏的大部分控制和物理功能都依赖于固定帧速率。为什么会这样？是否有可能在不依赖帧速率的情况下创建一个模式？如果将图形渲染与引擎的其余部分分开，是否一定会损失精度？
谢谢您，如果问题令人困惑，我们深表歉意。
"Super Meat Boy" is a difficult platformer that recently came out for PC, requiring exceptional control and pixel-perfect jumping. The physics code in the game is dependent on the framerate, which is locked to 60fps; this means that if your computer can't run the game at full speed, the physics will go insane, causing (among other things) your character to run slower and fall through the ground. Furthermore, if vsync is off, the game runs extremely fast.
Could those experienced with 2D game programming help explain why the game was coded this way? Wouldn't a physics loop running at a constant rate be a better solution? (Actually, I think a physics loop is used for parts of the game, since some of the entities continue to move normally regardless of the framerate. Your character, on the other hand, runs exactly [fps/60] as fast.)
What bothers me about this implementation is the loss of abstraction between the game engine and the graphics rendering, which depends on system-specific things like the monitor, graphics card, and CPU. If, for whatever reason, your computer can't handle vsync, or can't run the game at exactly 60fps, it'll break spectacularly. Why should the rendering step in any way influence the physics calculations? (Most games nowadays would either slow down the game or skip frames.) On the other hand, I understand that old-school platformers on the NES and SNES depended on a fixed framerate for much of their control and physics. Why is this, and would it be possible to create a patformer in that vein without having the framerate dependency? Is there necessarily a loss of precision if you separate the graphics rendering from the rest of the engine?
Thank you, and sorry if the question was confusing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
物理原理没有理由依赖于帧速率，这显然是一个糟糕的设计。
我曾经试图理解人们为什么这样做。我对公司另一个团队编写的游戏进行了代码审查，我从一开始就没有看到它，但他们在代码中使用了很多硬编码值 17。当我在调试模式下运行游戏并显示 FPS 时，我看到，FPS 恰好是 17！我再次查看代码，现在很清楚了：程序员假设游戏始终具有 17 FPS 的恒定帧速率。如果 FPS 大于 17，他们会进行睡眠以使 FPS 恰好为 17。当然，如果 FPS 小于 17，他们什么也不做，游戏就会变得疯狂（就像以 2 FPS 玩并在 FPS 中驾驶汽车时）游戏时，游戏系统提醒我：“太快了！太快了！”）。
所以我写了一封电子邮件询问他们为什么硬编码这个值并使用它作为他们的物理引擎，他们回答说这样可以使引擎更简单。我再次回答，好的，但是如果我们在不支持 17 FPS 的设备上运行游戏，你的游戏引擎运行起来会很有趣，但不会达到预期。他们表示，这将在下次代码审查之前解决该问题。
3 或 4 周后，我得到了源代码的新版本，所以我真的很好奇他们对 FPS 常量做了什么，所以我做的第一件事就是搜索 17 之后的代码，只有几个匹配项，但是一个其中我不想看到：
final static int FPS = 17;
因此，他们从所有代码中删除了所有硬编码的 17 值，并改用 FPS 常量。他们的动机是：现在，如果我需要将游戏放在只能运行 10 FPS 的设备上，我所需要做的就是将 FPS 常量设置为 10，游戏就会流畅运行。
总之，很抱歉写了这么长的信息，但我想强调的是，任何人会做这样的事情的唯一原因是糟糕的设计。
There are no reasons why physics should depend on the framerate and this is clearly a bad design.
I've once tried to understand why people do this. I did a code review for a game written by another team in the company, and I didn't see it from the beginning but they used a lot of hardcoded value of 17 in their code. When I ran the game on debug mode with the FPS shown, I saw it, FPS was exactly 17! I look over the code again and now it's clear: the programmers assumed that the game will always have a 17 FPS constant frame rate. If the FPS was greater than 17, they did a sleep to make the FPS be exactly 17. Of course, they did nothing if the FPS was smaller than 17 the game just went crazy (like when played at 2 FPS and driving a car in the game, the game system alerted me: "Too Fast! Too Fast!").
So I write an email asking why they hardcoded this value and use it their physics engine and they replied that this way they keep the engine simpler. And i replied again, Ok, but if we run the game on a device that is incapable of 17 FPS, your game engine runs very funny but not as expected. And they said that will fix the issue until the next code review.
After 3 or 4 weeks I get a new version of the source code so I was really curious to find out what they did with the FPS constant so first thing i do is search through code after 17 and there are only a couple matches, but one of them was not something i wanted to see:
final static int FPS = 17;
So they removed all the hardcoded 17 value from all the code and used the FPS constant instead. And their motivation: now if I need to put the game on a device that can only do 10 FPS, all i need to do is to set that FPS constant to 10 and the game will work smooth.
In conclusion, sorry for writing such a long message, but I wanted to emphasize that the only reason why anyone will do such a thing is the bad design.
这里有一个关于为什么你的时间步长应该保持不变的很好的解释：http://gafferongames.com /game-physicals/fix-your-timestep/
此外，根据物理引擎的不同，当时间步长发生变化时，系统可能会变得不稳定。这是因为帧之间缓存的某些数据与时间步相关。例如，迭代求解器的起始猜测（即约束的求解方式）可能与答案相去甚远。我知道 Havok（许多商业游戏使用的物理引擎）也是如此，但我不确定 SMB 使用哪个引擎。
几个月前，游戏开发者杂志上也有一篇文章，说明了如何以相同的初始速度但不同的时间步长进行跳跃，并以不同的帧速率实现不同的最大高度。有一个来自游戏（Tony Hawk？）的轶事，在游戏的 NTSC 版本上运行时可以进行一定的跳跃，但在 PAL 版本上则不能（因为帧速率不同）。抱歉，我现在找不到问题，但如果您愿意，我可以稍后尝试挖掘它。
Here's a good explanation on why your timestep should be kept constant: http://gafferongames.com/game-physics/fix-your-timestep/
Additionally, depending on the physics engine, the system may get unstable when the timestep changes. This is because some of the data that is cached between frames is timestep-dependant. For example, the starting guess for an iterative solver (which is how constraints are solved) may be far off from the answer. I know this is true for Havok (the physics engine used by many commericial games), but I'm not sure which engine SMB uses.
There was also an article in Game Developer Magazine a few months ago, illustrating how a jump with the same initial velocity but different timesteps was achieved different max heights with different frame rates. There was a supporting anecdote from a game (Tony Hawk?) where a certain jump could be made when running on the NTSC version of the game but not the PAL version (since the framerates are different). Sorry I can't find the issue at the moment, but I can try to dig it up later if you want.
他们可能需要足够快地完成游戏，并决定用当前的实现来覆盖足够的用户群。
现在，如果您在开发过程中考虑一下的话，改造独立性并不是那么困难，但我认为它们可能会陷入一些陡峭的困境。
我认为这是不必要的，而且我以前见过它（一些早期的 3d-hw 游戏使用了同样的东西，如果你看天空，游戏会变快，如果你看地面，游戏会变慢）。
实在是太糟糕了。向开发人员报告这个问题，并希望他们能够修补它（如果可以的话）。
They probably needed to get the game done quickly enough and decided that they would cover sufficient user base with the current implementation.
Now, it's not really that hard to retrofit independence, if you think about it during development, but I suppose they could go down some steep holes.
I think it's unnecessary, and I've seen it before (some early 3d-hw game used the same thing, where the game went faster if you looked at the sky, and slower if you looked at the ground).
It just sucks. Bug the developers about it and hope that they patch it, if they can.