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
The chip running the game is running in binary, so it has a *clock cycle* that defines how often the 1s and 0s happen. Like how does the computer know the difference between four 0s in a row and five 0s? Because in the background there’s a clock that just goes 01010101 which is how the chip “counts” what everything else is doing.
Let’s say you want your game to check if the character is touching a spike that will kill you. Your chip can’t “look”, really, it can only compare values and those values only change with the clock cycle. So the *fastest* that the chip can check is with the next clock cycle and look to see if there’s a 1 where there should be a 0 which means you touched the spike.
But your graphics card has its own chip that has its own clock cycle. What you see on the screen is updating with that graphics cycle, regardless of what the cpu is doing. The cpu might check if you’re touching the spike 1000 times a second, but your graphics card is only processing what should be displayed at, oh, 700 times a second, and it’s only actually updating what’s on the screen 60 times per second. What happens if the **cpu** updates where your character is calculated to be faster than your **gpu** calculates how to *show* where your character is?
You might end up in a case where the cpu says you touched a spike and are dead, but that’s not what it looks like on the screen. That’s not a good gameplay experience.
Back in the day of cartridge games, there was no separate cycle. The only thing that matters is what’s on the screen and your console was optimized to figure that out and show you. All the gameplay logic was usually built on the screen refresh rate. Now, though, that would be way too slow to calculate everything you need to run the game. So we have separate cpus that are good at handling different kinds of logic but go fast as fuck, and gpus which are only good at showing what’s on screen.
Some games are optimized for performance. There is enough wiggle room between what the cpu and gpu say that you probably won’t notice. Like, if you’re playing an online shooter, the hitbox is probably already bigger than your character model *and* there’s internet lag, and a decent amount of computing power goes into just kind of fudging it in a way that feels fair. The cpu needs to go fast af to keep up with everything happening.
Some games need to be tied to the graphics cycle. A game like geometry dash has frame-perfect timing so you need to know with 100% certainty that what the screen is showing is what the cpu thinks is going on. *One pixel* of difference might be enough to kill you. And that’s fine, because the game is simple enough that you don’t need much cpu to make it run so you can lean more on the gpu, or tell the cpu to follow the gpu and not just go as fast as it can.
Latest Answers