[hamdingers]

No, I'm explaining how most games work in practice.

You're right a game could be made that works that way. I'm not aware of one, but I don't have exhaustive knowledge and it wouldn't surprise me if examples exist, but that was not the question.

[adastra22]

I would not at all be surprised that there are examples out there, although I don't know of them. Tying the game state to the render loop is decision made very deep in the game engine, so you'd have to do extensive modifications to change any of the mainstream engines to do something else. Not worth the effort.

But a greenfield code shouldn't be perpetuating this mistake.

[whstl]

That's a super interesting discussion

On most modern engines there is already a fixed-step that runs at a fixed speed to make physics calculation deterministic, so this independence is possible.

However, while it is technically possible to run the state updates at a higher frequency, this isn't done in practice because the rendering part wouldn't be able to consume that extra precision anyway.

That's mainly because the game state kinda needs to remain locked while: 1) Rendering a frame to avoid visual artifacts (eg: the character and its weapon are rendered at different places because the weapon started rendering after a state change), or even crashes (due to reading partially modified data); 2) while fixed step physics updates are being applied and 3) if there's any kind of work in different threads (common in high FPS games).

You could technically copy the game-state functional-style when it needs to be used, but the benefits would be minimal: input/state changes are extremely fast compared to anything else. Doing this "too early" can even cause input lag. So the simple solution is just to do state change it at the beginning of the while loop, at the last possible moment before this data is processed.

Source: worked professionally with games in a past life and been in a lot of those discussions!

[vintermann]

I can give an example. I'd heard that Super Meat Boy was hard, and it was, but it turned out, if you ran it at the 60hz it was designed for instead of 75hz, it was considerably easier. At 120hz it was unplayable.

You kind of understand how the game loop is tied to the refresh rate in games like this, though. Practicing "pixel perfect" jumps must be challenging if the engine updates aren't necessarily in sync with what goes on on screen. And in the really old days (when platformers were invented!) there was no real alternative to having the engine in sync with the screen.

[adastra22]

In the model I am describing there would be whole game state updates on every tick cycle, completely decoupling the frame rate from the response latency and prediction steps.