5 ms·

Isn't it a waste of computing power to produce 6000 fps and only use a fraction of them

throwaway14356 3y ago
you need about the same impossible accuracy to play this. im only half joking, if you want to improve you will need to somehow respond more accurately. Seeing someone play it well is mind blowing if you know how hard it gets.
ComputerGuru 3y ago
Yes, but in practice, no. These games are usually coded as a loop that runs with full CPU as fast as it can (unless capped, which the old one wasn’t), using as much cpu as is available. In that case, the fps is a side effect of how long the loop takes to run each pass (which is what happened here) - i.e. you don’t determine the fps, the fps is a result of how complicated or (in)efficient your code is. So going from running at 30 fps because it was so poorly coded and made such inefficient use of the cpu to running at 6000 fps because it now completes each loop pass that much faster, the cpu usage is actually the same. Now if your code is so optimized that it can run at 6000 fps, at that point you can say “gee, I don’t need this many updates a second, let me cap it to x frames per second.” But how do you do that? The GPU is grabbing finished frames out of the buffer at its own pace, whether you are generating them at 6k/sec or just 5/sec. To cap your cpu consumption you would usually say “we need a new frame every 0.015s to always have a new frame ready for the GPU so that the screen updates sixty times a second, so if we finish a frame in 0.001s instead, sleep (effectively yielding cpu consumption to other processes) for 0.01 seconds after we run through the loop” - but while that may work for some things, there are other stuff that need to happen “in real-time” such as reloading the audio buffer (to avoid pauses or corrupted/garbled audio), etc and you also can’t rely on the system to actually wake you before 0.015s even though you asked it to wake you after just 0.01s to be extra safe. Tl;dr, yes, once your code is running at 6k fps, then capping it to reduce consumption is an option, but running at 6k fps doesn’t actually increase cpu vs inefficiently running at 30fps.
- johncoatesdev 3y ago
  You can get a callback when a frame is going to get drawn and only render then. That way you don't render needless frames. Your logic loop that controls the game state can be set to an optimal tick rate so it's not just maxing out a core. The audio buffers I've worked with have also supported callbacks so they can remain optimally filled.
- leptons 3y ago
  It's possible that going far above "6000fps" might be necessary someday for holographic/3D displays that need to render the scene from hundreds or thousands of different viewpoints for one single frame. Say you need to render a scene from 1000 different angles for a 3D display, just to get to a 60hz refresh rate you would need to render the scene 60,000 times.
  - astrange 3y ago
    This is the game update loop, which excludes rendering. (for some reason people still use FPS which is confusing) I'm not aware of any displays like that, but if there were, you could optimize by eye tracking each viewer and only rendering the direction they're seeing it from. The "New 3DS" (note: different from the regular 3DS) did this.
- veave 3y ago
  That is so absolutely false. Any game you run if you don't cap fps it uses 100% of your gpu and potentially your cpu. As soon as you cap the framerate to 60 fps it starts behaving normally.
  - naikrovek 3y ago
    "rendered" and "sent to the screen" are very different. there are nuances about all of this which make both of you correct in different situations.
  - ComputerGuru 3y ago
    I said as much, though. Read again. I had a caveat about when you start limiting your frame rate.
squeaky-clean 3y ago
It's not intended to run at 6000fps. That's just how quickly it will run without any form of limiter. You can use your GPU settings to limit the framerate, or many games have a built in frame-limiter.
somat 3y ago
I think this was just a case of optimized code runs really fast, but sometimes the game will decouple the physics simulation from the graphics, I have seen this done in both directions, racing games where you want the physics to run faster than the graphics for a nice smooth car control, and building games where you want the physics to run slower than the graphics, mainly because you have so much physics you can not calculate it all every frame.

you need about the same impossible accuracy to play this. im only half joking, if you want to improve you will need to somehow respond more accurately. Seeing someone play it well is mind blowing if you know how hard it gets.

ComputerGuru 3y ago

Yes, but in practice, no. These games are usually coded as a loop that runs with full CPU as fast as it can (unless capped, which the old one wasn’t), using as much cpu as is available. In that case, the fps is a side effect of how long the loop takes to run each pass (which is what happened here) - i.e. you don’t determine the fps, the fps is a result of how complicated or (in)efficient your code is. So going from running at 30 fps because it was so poorly coded and made such inefficient use of the cpu to running at 6000 fps because it now completes each loop pass that much faster, the cpu usage is actually the same. Now if your code is so optimized that it can run at 6000 fps, at that point you can say “gee, I don’t need this many updates a second, let me cap it to x frames per second.” But how do you do that? The GPU is grabbing finished frames out of the buffer at its own pace, whether you are generating them at 6k/sec or just 5/sec. To cap your cpu consumption you would usually say “we need a new frame every 0.015s to always have a new frame ready for the GPU so that the screen updates sixty times a second, so if we finish a frame in 0.001s instead, sleep (effectively yielding cpu consumption to other processes) for 0.01 seconds after we run through the loop” - but while that may work for some things, there are other stuff that need to happen “in real-time” such as reloading the audio buffer (to avoid pauses or corrupted/garbled audio), etc and you also can’t rely on the system to actually wake you before 0.015s even though you asked it to wake you after just 0.01s to be extra safe. Tl;dr, yes, once your code is running at 6k fps, then capping it to reduce consumption is an option, but running at 6k fps doesn’t actually increase cpu vs inefficiently running at 30fps.

johncoatesdev 3y ago
You can get a callback when a frame is going to get drawn and only render then. That way you don't render needless frames. Your logic loop that controls the game state can be set to an optimal tick rate so it's not just maxing out a core. The audio buffers I've worked with have also supported callbacks so they can remain optimally filled.
leptons 3y ago
It's possible that going far above "6000fps" might be necessary someday for holographic/3D displays that need to render the scene from hundreds or thousands of different viewpoints for one single frame. Say you need to render a scene from 1000 different angles for a 3D display, just to get to a 60hz refresh rate you would need to render the scene 60,000 times.
- astrange 3y ago
  This is the game update loop, which excludes rendering. (for some reason people still use FPS which is confusing) I'm not aware of any displays like that, but if there were, you could optimize by eye tracking each viewer and only rendering the direction they're seeing it from. The "New 3DS" (note: different from the regular 3DS) did this.
veave 3y ago
That is so absolutely false. Any game you run if you don't cap fps it uses 100% of your gpu and potentially your cpu. As soon as you cap the framerate to 60 fps it starts behaving normally.
- naikrovek 3y ago
  "rendered" and "sent to the screen" are very different. there are nuances about all of this which make both of you correct in different situations.
- ComputerGuru 3y ago
  I said as much, though. Read again. I had a caveat about when you start limiting your frame rate.

squeaky-clean 3y ago

It's not intended to run at 6000fps. That's just how quickly it will run without any form of limiter. You can use your GPU settings to limit the framerate, or many games have a built in frame-limiter.

somat 3y ago

I think this was just a case of optimized code runs really fast, but sometimes the game will decouple the physics simulation from the graphics, I have seen this done in both directions, racing games where you want the physics to run faster than the graphics for a nice smooth car control, and building games where you want the physics to run slower than the graphics, mainly because you have so much physics you can not calculate it all every frame.