I recently tried to play Wolfenstein New Order, I realized that unlocking the framerate makes the game break. why? (sorry for bad english)
because it’s easier.
You have one “frame” where you just do everything: read the player input, do whatever actions, calculate collisions and physics and whatever, and draw everything when all those calculations are done.
Then you move on to the next frame and do everything again. Everything lines up all the time and always happen in the same order. Simple, quick, and consistent.
To decouple calculations and framerate, you don’t know when the game will try to draw something. It might be in the middle of when you’re calculating collisions, or moving the units, or calculating physics. Or you might end up doing multiple calculations while the GPU is slow and can’t draw anything.
So you have to add an extra layer in between, probably saved to some memory somewhere. Now every time the GPU draws something, it has to access that memory. Every time you calculate something, you also access that memory. Let’s hope they DON’T try to read and write on the same spot at the same time, that could cause bugs. And so much memory access, you’ve basically doubled your memory bandwidth requirements.
It’s complicated, more resource intensive, and introduces potential bugs.
Not a game dev but I’ve done some programming and I love games so I’ll take a stab. There’s a few reasons I can think of:
- That’s how the engine they’re using works. Game engines take a long time to develop, and so if you’re using one off the shelf or from a previous project, it may be from a time when tying behavior to the frame rate was a low overhead tool for timing that would cause few if any issues. Given that Wolfenstein is a Bethesda title and they’ve made many games with similar engine level limitations, this seems most likely to me for this particular case.
- They never intended to release it that way, and just set it up that way early in development to start getting to the real gameplay work. Then the deadline came around and it wasn’t a high priority in terms of getting the game out the door.
- Probably doesn’t apply to Wolfenstein, but for indie games that have one or only a few developers, none of those people may have done much programming before, instead being more focused on other aspects of game design. So if you’re learning as you go, there’s a good chance some hacky things will make it in to the final product.
I suppose that’s what I get for just doing a quick google 🙃
That is really interesting though, my understanding is that Doom 2016 is known for running pretty well and achieving high framerates, or at least that was the sense I got from tech youtube when I watching that more. I wonder what the devs were doing in that case.
At least it’s not Destiny 2 where incoming damage is tied to frame rate such that the higher yours is the more damage you take.
Damned if I know. It’s possibly the stupidest decision I’ve ever seen in a big name game. But yeah sometimes you’ll be walking around and just all of a sudden get obliterated out of nowhere and it was because you got mapped by an NPC rocket with damage tied to frame rate. There’s YouTube videos of people proving it works this way iirc; I know people used to post testing videos on R.
I don’t know this specific case, but my guess is that damage is a set amount per frame that a collision overlap is happening. This is perfectly valid if it is biased by the delta between frames. It means things get a little wonky at low framerates, but largely work well. But if you are assuming a frame is an exact length, you save a multiplication action, but gain the problem of unlocked frame rates breaking things (and frame dipping possibly causing problems).
Because it’s easier to programm a single thread that executes a sequence of commands like [ update-gamelogic, update-graphics, etc. ] instead of at least 2 threads (for gamelogic and graphics) that you have to synchronize somehow. Synchronization can be pretty difficult!
Tying game logic to the framerate doesn’t really have anything to do with single- vs multi-threading. You can properly calculate the time since the last update in a single-threaded engine.
It’s not about that.
If the game loop doesn’t run at the same speed as the render loop you’ll get ‘tearing’ - some game objects are at the latest state, some are not. That can cause some funky bugs.
From my understanding, tearing can occur even if the game logic and render command submission happen on a single thread, since it’s a consequence of the OS compositor sending buffers to the monitor in the middle of rendering.
This video might give you a good idea of what’s going on behind the scenes and why things are not trivial to get right: https://youtu.be/yGhfUcPjXuE
