4 ms·

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

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.
- squeaky-clean 3y ago
  Very true, I didn't want to go too deep in one comment, but I tried to mention that the video of the modded Wipeout is fluctuating between 4000fps and 6000fps, but that doesn't cover the fact that 5999 frames may have been calculated in 0.1s and 1 frame took 0.9s I actually tried increasing the input handling resolution of a game of mine by running the input polling and physics system 4x for each actual rendered frame. I thought it would be a great idea, you can get more precise input and physics without also calculating batching, draw calls, or sending anything to the GPU. Only problem was that because the actual game logic and physics in my game was so simple, the visual frame would take about 5ms to calculate/render, and then the 4 non-visual frames would take about 0.2ms each to calculate. So even with a 1000hz mouse it was running the non-visual series of frames faster than the mouse would update, and then stalling for 5ms while the visual frame rendered.
  - syntheweave 3y ago
    When trying to run one system at a higher rate than the other(whether it's render, physics, input) the principles of DSP come into play: you're running a bunch of things that can be coordinated together for maximum smoothness if you define the sample rates to be consistent and interpolate the sampled data appropriately. If you can run something very fast but you don't define a set pace, you don't have a theoretically sound starting point, and that's where a lot of game timing systems(from basically every era of gaming) fall over and accidentally drop information or add timing artifacts. So, like you, I made a system with a target physics refresh that was above render, but I did it with the goal of visually smooth operation - and therefore, I derived a frame pace from time-from-bootup, and guided the physics refresh not around the direct multiple of vsync, but "how many frames do I need to issue to keep pace with real time as defined by the system clock". Doing this naively creates disturbing rubberbanding effects, since the pace naturally oscillates, but adding a low-pass filter to reduce jitter and a "dropped frames" adjustment produced motion with a very satisfying quality. I'm forgetting precisely what I did with the input, on the other hand, but I think I determined that "as fast as possible" was still an improvement because the way I was issuing frames was reducing the amount of aliasing of deadlines on the margin. It's an area where you can definitely get pretty sophisticated. Many emulators for older systems now are emulating ahead, displaying that result, and then rolling back emulation state to create a configurable negative input latency.

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.
squeaky-clean 3y ago
Very true, I didn't want to go too deep in one comment, but I tried to mention that the video of the modded Wipeout is fluctuating between 4000fps and 6000fps, but that doesn't cover the fact that 5999 frames may have been calculated in 0.1s and 1 frame took 0.9s I actually tried increasing the input handling resolution of a game of mine by running the input polling and physics system 4x for each actual rendered frame. I thought it would be a great idea, you can get more precise input and physics without also calculating batching, draw calls, or sending anything to the GPU. Only problem was that because the actual game logic and physics in my game was so simple, the visual frame would take about 5ms to calculate/render, and then the 4 non-visual frames would take about 0.2ms each to calculate. So even with a 1000hz mouse it was running the non-visual series of frames faster than the mouse would update, and then stalling for 5ms while the visual frame rendered.
- syntheweave 3y ago
  When trying to run one system at a higher rate than the other(whether it's render, physics, input) the principles of DSP come into play: you're running a bunch of things that can be coordinated together for maximum smoothness if you define the sample rates to be consistent and interpolate the sampled data appropriately. If you can run something very fast but you don't define a set pace, you don't have a theoretically sound starting point, and that's where a lot of game timing systems(from basically every era of gaming) fall over and accidentally drop information or add timing artifacts. So, like you, I made a system with a target physics refresh that was above render, but I did it with the goal of visually smooth operation - and therefore, I derived a frame pace from time-from-bootup, and guided the physics refresh not around the direct multiple of vsync, but "how many frames do I need to issue to keep pace with real time as defined by the system clock". Doing this naively creates disturbing rubberbanding effects, since the pace naturally oscillates, but adding a low-pass filter to reduce jitter and a "dropped frames" adjustment produced motion with a very satisfying quality. I'm forgetting precisely what I did with the input, on the other hand, but I think I determined that "as fast as possible" was still an improvement because the way I was issuing frames was reducing the amount of aliasing of deadlines on the margin. It's an area where you can definitely get pretty sophisticated. Many emulators for older systems now are emulating ahead, displaying that result, and then rolling back emulation state to create a configurable negative input latency.