>>106458055
The last time I made a game, I did a main loop where on every frame update, I count how much time elapsed since the last frame, then move everything according to that much time. It's probably a horrible idea and would fuck you big time but it was a simple javascript thing with no actual AI logic, just a few things going in a fixed direction. I never got to test it on anything that didn't run on 60fps so I've no clue what it would have done, but I did have everything running at a fixed "speed" so on 120Hz it probably would've just moved everything half as much.
So basically the game logic was tied to the framerate.
Wouldn't even know how to decouple the main loop from the rendering stage. Probably not even possible on javascript.
>>106458131
>There are plenty of very old PC games with problems like this too. They were made for super ancient PCs and anything faster just breaks them.
I remember we had an incredible old "wheel of fortune" style game that we played a ton in the mid 90s, but on anything Pentium 1 and above it was unplayable fast. We had to find a tool that intentionally slows down execution for just one single app.
There was also the Turbo button on old PCs that did this in hardware, because the 286/386/486 ran too fast for apps designed for the first IBM PC using a 8086.