take for example geometry dash and celeste.
in geometry dash, having a 360hz monitor will have slightly different gameplay than a 60hz, and some user created levels have made frame perfects that are only possible at 240hz+.
celeste has a 60fps cap, if you use assist mode’s builtin speedhack at 0.5x speed, since the game has 60fps cap, it’s effectively 120fps calculation. this also affects it, why?
In: 8
Short: Because the developers decided to make it that way.
Long:
A game (or any program for that matter) is one long loop of instructions that gets repeated over and over again. Get the user input, process the user input, move the enemies, move falling objects down a bit, etc.
But there’s a second loop: The one that paints each frame to be shown on the monitor. That one also runs all the time. Paint the background picture, paint the enemies, paint the player, paint the explosions, paint the health bar, etc.
But this now means that you have two endless loops you have to convince the computer to execute at the same time. And there are multiple ways to do that:
(a) Lazy. Just put both in the same loop. If your game loop and graphics loop can both run 60 times per second (what’s considered the default monitor display frequency anyway), you can just combine them. And as long as everything stays at 60 fps, all is fine. Otherwise, things can get whacky. At higher fps, things move faster, and at lower fps they move slower. You can compensate for that in the game loop by moving objects depending on the measured time since the last iteration of the game loop…but that still introduces rounding errors (I guess this is what you’re seeing in your game? 0.33+0.33+0.33 != 0.5+0.5) and delayed responses to fps changes.
(b) Interweave. You can run your game loop, and in the pauses between runs the graphics loop as often as there is time. Minecraft did that before multithreading, for example. The game loop ran 20 times a second, and after each run, the graphics loop ran as often as possible. This generally works well, but graphics can become a bit stuttery as every 1/20 second there’s a longer pause to run the game loop.
(c) Multithreading. Split your program into two, and run each part on a different core of the CPU. While this gives the best results (the loops don’t interfere with each other), you just created a nightmare for the programmers as they need to make 110% sure that code from the graphics loop doesn’t access game data while code from the game loop changes it and vice versa. Otherwise, you get crashes, objects that are in two places of the screen at the same time, or flicker because they’re sometimes missing, etc.
Latest Answers