6 ms·

It means it's calculating 6000 frames per second, but all of them don't need to make it to the screen. On a 60hz screen, every 100th frame calculated would actu

It means it's calculating 6000 frames per second, but all of them don't need to make it to the screen. On a 60hz screen, every 100th frame calculated would actually be displayed. (If we assume a perfect 6000fps, the video shows fluctuations between 4000fps-7000fps. If you just mean how can it be so high in general? Old, well optimized, games run really well on faster modern hardware. I remember getting over 1,000 fps in Guild Wars 1 on a GTX 1060 when looking at an area with no monsters/NPCs. edit( this paragraph doesn't apply here) ~~The PS1 also doesn't have floating point math, mostly everything is done in fixed point with integer math which is obscenely fast compared to floating point (it could also simulate an FPU if the precision is absolutely necessary but that's not suitable for realtime)~~ Just read further down the article that they converted it to float. I guess the game is just super optimized. I would have thought fixed point savings factored in here.

_a_a_a_ 3y ago
> all of them don't need to make it to the screen ah gotcha, thanks. The bandwidth would have to be terabytes/sec. Come to think of it, pretty dumb of me to think they did.
- squeaky-clean 3y ago
  Nah, most people would probably not think of unseen frames being generated unless you're into studying your graphics performance. It also technically does make a difference in some games. Even if the frames don't make it to the screen, if your mouse polls at 1000hz then you can get more precise input tracking by rendering up to 1000fps. It's something only really noticeable to professional gamers. But pro CSGO players are positive they can feel an improvement when running at fps more than double their monitor rate.
  - kmeisthax 3y ago
    Also keep in mind that games don't run at a constant FPS. The "FPS" stat that we talk about is an average of the time each frame took to process and render, 1/x. But we can also talk about deviation from that average, which is where you get "1% low" and "0.1% low" stats. If your 1%s or 0.1%s dip below your monitor refresh rate, that becomes microstutter, which is way more noticeable than a reduction in the average frame time. Wanting to have FPS at 2x your monitor's refresh rate will[0] provide a significant safety margin against frames that take too long to render. I will also point out that this 2x rule came into the community before we had adaptive sync, so the alternative would be turning off vsync in the vain hope that microstutter would get lost in the tearing. For the record, "microstutter" wasn't really a common thing people talked about until fairly recently, so I'm kind of applying today's more scientific analysis of game performance to things that back then were largely superstitions that happened to work. [0] Assuming a fast CPU and GPU drivers worth using
    - spookie 3y ago
      Very much true, just wanted to add something. In the before times, games would be running on pure forward renderers. Which, in turn, would mitigate many of the the frame timing inconsistencies of the more complex pipelines of today! Some still do that, of course. With the exception that we aren't relying in fixed function hw anymore!
      - kmeisthax 3y ago
        Wait, really? That's odd. I thought the whole point of a deferred rendering pipeline was to reduce inconsistency by doing all your lighting calculations in one pass on one quad. In forward rendering you have to worry about overdraw - i.e. if you have a model that's half-obscured by another, but you render it first, you still wind up drawing the whole model, including the expensive pixel shader material you attached to it[0]. With deferred rendering all your model is doing is drawing textures to various channels in the G-buffer, which is cheap. I thought the major downside of deferred was memory bandwidth - i.e. you have to write and read the entire G-buffer with at least 11[1] channels in order to produce an RGB image. That's a cost you pay every frame so it wouldn't hurt frame time consistency. Meanwhile in forward-land it was the case that your FPS was extremely viewport dependent. Like, I remember looking down at a floor would double FPS, looking at a large scene with a bunch of objects or people in it would tank FPS, etc. [0] Unless you get lucky with drawing order or sorted everything from front-to-back so that you can rely on early depth testing to kill those pixel draws. Which would also ruin your frame time consistency. [1] XYZ normal, depth, RGB diffuse, RGB specular, and some kind of 'shininess' parameter that controls the specular exponent. Most practical deferred implementations will also have either a "material ID" channel or some special-purpose channels for controlling various visual effects in the game. This is also why Breath of the Wild has a weird column where if you stand inside of it Link stops getting toon shading.
        spookie 3y ago
        That's true, and a very good counter argument. But, bear in mind, with fixed function hardware I was assuming no lights were involved.
ufjfjjfjfj 3y ago
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

_a_a_a_ 3y ago

> all of them don't need to make it to the screen ah gotcha, thanks. The bandwidth would have to be terabytes/sec. Come to think of it, pretty dumb of me to think they did.

squeaky-clean 3y ago
Nah, most people would probably not think of unseen frames being generated unless you're into studying your graphics performance. It also technically does make a difference in some games. Even if the frames don't make it to the screen, if your mouse polls at 1000hz then you can get more precise input tracking by rendering up to 1000fps. It's something only really noticeable to professional gamers. But pro CSGO players are positive they can feel an improvement when running at fps more than double their monitor rate.
- kmeisthax 3y ago
  Also keep in mind that games don't run at a constant FPS. The "FPS" stat that we talk about is an average of the time each frame took to process and render, 1/x. But we can also talk about deviation from that average, which is where you get "1% low" and "0.1% low" stats. If your 1%s or 0.1%s dip below your monitor refresh rate, that becomes microstutter, which is way more noticeable than a reduction in the average frame time. Wanting to have FPS at 2x your monitor's refresh rate will[0] provide a significant safety margin against frames that take too long to render. I will also point out that this 2x rule came into the community before we had adaptive sync, so the alternative would be turning off vsync in the vain hope that microstutter would get lost in the tearing. For the record, "microstutter" wasn't really a common thing people talked about until fairly recently, so I'm kind of applying today's more scientific analysis of game performance to things that back then were largely superstitions that happened to work. [0] Assuming a fast CPU and GPU drivers worth using
  - spookie 3y ago
    Very much true, just wanted to add something. In the before times, games would be running on pure forward renderers. Which, in turn, would mitigate many of the the frame timing inconsistencies of the more complex pipelines of today! Some still do that, of course. With the exception that we aren't relying in fixed function hw anymore!
    - kmeisthax 3y ago
      Wait, really? That's odd. I thought the whole point of a deferred rendering pipeline was to reduce inconsistency by doing all your lighting calculations in one pass on one quad. In forward rendering you have to worry about overdraw - i.e. if you have a model that's half-obscured by another, but you render it first, you still wind up drawing the whole model, including the expensive pixel shader material you attached to it[0]. With deferred rendering all your model is doing is drawing textures to various channels in the G-buffer, which is cheap. I thought the major downside of deferred was memory bandwidth - i.e. you have to write and read the entire G-buffer with at least 11[1] channels in order to produce an RGB image. That's a cost you pay every frame so it wouldn't hurt frame time consistency. Meanwhile in forward-land it was the case that your FPS was extremely viewport dependent. Like, I remember looking down at a floor would double FPS, looking at a large scene with a bunch of objects or people in it would tank FPS, etc. [0] Unless you get lucky with drawing order or sorted everything from front-to-back so that you can rely on early depth testing to kill those pixel draws. Which would also ruin your frame time consistency. [1] XYZ normal, depth, RGB diffuse, RGB specular, and some kind of 'shininess' parameter that controls the specular exponent. Most practical deferred implementations will also have either a "material ID" channel or some special-purpose channels for controlling various visual effects in the game. This is also why Breath of the Wild has a weird column where if you stand inside of it Link stops getting toon shading.
      - spookie 3y ago
        That's true, and a very good counter argument. But, bear in mind, with fixed function hardware I was assuming no lights were involved.

ufjfjjfjfj 3y ago

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