I don’t know if I’m explaining this right…
A computer can run logic at some speed based on how powerful the components of it are, so if it can perform the logic of something, for example, movement in a game, how does it know how much should be done based on its power, instead of essentially running in “fast-forward” or conversely in slow motion?
In: 1307
There’s a thing called the game loop.
Every loop, it does all the logic for the game and drawing onto the screen.
Faster computers will call this loop quicker because they can, slower computers will call it slower.
If you look at how much time has passed since the last time the loop happened, you know how much to move things on the screen.
So if your character moves 60 steps per second and half a second has occurred since the last loop, you should move the character 30 steps (half of 60).
This will keep fast and slow computers running at the same speed.
IIrc for games there’s the update function, a part of the game’s code that executes as fast as possible, there’s also fixed update, which updates every X milliseconds, time given by a small clock, there’s deltaTime which is a fancy way to determine how much we have to delay the current frame for it to not be faster than normal without using a fixed update rate.
This used to be a problem back in the day with some systems that would run certain games but which later were ran on faster processors, resulting in faster gameplay.
If it weren’t for these functions, we’d run something like the Atari Breakout at 9000x speed.
As for videos, ask someone that codes in that domain.
Most apps (I think) use ffmpeg, a library that handles most of the stuff, the ones that don’t I have no idea about.
In the beginning, they didn’t. The classic example of increasing difficulty level of Space Invaders was partially inspired by less sprites on screen allowing the hardware to calculate the game faster translating to enemies moving faster. Even as recently as early-mid 2010’s this was a problem. For example, Skyrim would have weird physics interactions when the FPS was set to greater than 60.
But to answer your question, the CPU usually has a method available to programs to just return real time. This means that the physics can be calculated on real time instead of frames, which means the movement can be based on “distance per second” instead of “distance per calculation” that caused the classic problems.
In applications where it’s important that a computer not go “too fast”, such as updating a game, it can be tethered to the internal clock. The program running the game will only ask for an update every so often. 60 updates a second is popular because it’s usually fast enough that humans can’t tell the individual updates apart. Even if the computer is fast enough to generate more updates than that, it won’t
Some older games played on new hardware can indeed run strangely because this safeguard wasn’t fully in place. They may end up playing at very high framerates and have processes that update every frame, producing unexpected behavior relative to when they were programmed and framerates that high weren’t possible.
In the early days of computing, game logic and video playback speeds were directly tied to the computer’s processor speed. So games and videos would literally run faster on more powerful hardware.
But programmers realized this was a problem, so they changed how games and video playback work under the hood. Here’s the key:
Modern games and video players update the logic and render the graphics in separate steps. The logic update happens in discrete time steps, not continuously. For example, the game logic might update 60 times per second, fixed, regardless of how fast the computer is.
After the logic update, the graphics get rendered. A faster computer can render more frames per second, making the visuals smoother. But the underlying logic is the same.
So while a faster computer can achieve higher frame rates and smoother visuals, the game logic itself – things like physics, AI, and video playback speed – stays fixed. This isolates the logic from the rendering performance.
In summary, by separating the logic updates from the rendering, programmers ensure games, videos, and other software maintain a consistent speed across different hardware. The visual smoothness improves on faster hardware, but the functional speed stays the same. It’s like a digital metronome keeping the beat regardless of the instrumentation.
First let’s re-frame the question — what you’re really asking about is the “Clock Speed” of a computer. Simply put a “thing” in a computer happens with each clock “tick.” When you see “5 Gigahertz” computer, that mean it can do 5 Billion “things” in one second. (These are very small things, not ‘move a character from point A to B,’ more like ‘add two numbers’)
So your real questions is “How do computers with different clock speeds play games at the same rate.” The answer is because they use actual time to figure out how quickly to move things in games or animation or videos rather than relying on clock speed.
It’s actually a very good question because games used to use the clock speed of the computer for movement, but when the games became unplayable on faster computers they switched to using actual time.
Typically, a computer game doesn’t run the computer “at top speed”, there’s a clock involved.
There are a few ways to do this. One is that each frame, you look at how much time has passed since the last frame, and make the game “move forward” that much time. So if it’s been 0.03 seconds, and your bullet/ character is moving at some speed, you can calculate how far it should have gone, etc.
Now, really old games (DOS era) often didn’t do this, and they consequently *were* much faster on faster hardware. I remember it being a real problem and having to run games in an emulated environment to slow them down.
It can go in slow motion, that is why we see frame drops, because something takes longer than anticipated maybe a memory access, maybe a draw call, maybe a floating point calculation.
It doesn’t speed up because software caps it. The software forces only e.g 200 updates per second, CPU cannot do 300. Some CPUs cannot handle 200 updates per second so they will do just 40 or 60 update per second.
My 5900x e.g can do more than 500 updates per second on CS2 which then are pushed to a Graphics card i.e a 6700XT which can do these 500 updates per second. If I would have used a gold RX670 I have, it would not be able to do 500 updates per second and in turn I will see frame drops.
If I replace my 5900x with my 20 year old CPU, my will not get more than 40 fps as CPU cannot push frames fast enough and effectively runs everything in slow motion.
Fun fact: on its own, it doesn’t! We have to specifically tell it to slow down.
Computers contain a clock that they can use to measure real-world time. When you write a game or a video program or such, you can tell the computer to use that clock to do things at the correct speed – usually by making it take a break every once in a while.
Imagine you’ve been told you have to draw a picture every hour. If you’re slow at drawing things, it might take you that whole hour. If you’re fast at drawing things, though, you could make a drawing in 15 minutes, and then spend 45 minutes waiting around doing whatever you want until you have to start the next drawing – like getting homework done early! Computers are like that – they do what they need to do in the time they were told to do it (for games and movies, this is often 1/60th of a second), and if they get done ‘too fast’ then they just wait until the time’s up. If we’re really clever, we can have them spend that time working on other things, or we can ask them to draw even *nicer* pictures since we have all this extra time.
Once in a while you can find an old game or program that wasn’t told to do that properly, and playing it on new, modern hardware can cause some issues because the computer does things (some things, or even *all* things) much too fast.
There’s the “turbo button” that fixes it by slowing down the computer to a more manageable speed
Latest Answers