Sorry if this has been brought up and/or fixed, I'm late to the party and only on day 20 or so. Plus the forums has no search as far as I can tell which is a bit of a bummer.
So in day 18 Casey sets up the game loop as something looking very roughly like:
My question is, doesn't this add what is effectively a frame of input delay and can we deal with that at all?
Here's the example in my mind:
The problem is the user input was intended to affect frame 3, but it's not processed until frame 4. The time between frame 2 being displayed and input for frame 3 being collected into the game input struct is near instant. Effectively the user has no time to react to the displayed frame (well sort of, humans have >100ms delay anyways so they would be behind no matter what)
Without the majority of time being spent between rendering one frame and starting the update of the next frame most of the user's input will "miss" making it in to the update for the frame after the one being displayed.
A possible loop without this issue might look like:
Except the problem here is any time spent updating the game cannot be accounted for by the sleep duration like the loop used by HH (as of day 18) does.
Now this is a very minor delay all things considered; many monitors will introduce an equal or longer delay than this anyways. There's also very few games where such minor timings could possibly even matter (Fighting Games being the prime example). It's hardly a big issue and I'd imagine many games have such delay baked in, but since Handmade Hero is all about digging deep into the low level stuff I'd thought I'd bring it up and see if people know how to make the loop tighter, why I'm wrong and there's no delay, or whatever other comments people have.
So in day 18 Casey sets up the game loop as something looking very roughly like:
1 2 3 4 5 | while(running) {
Win32GameUpdateAndRender()
Sleep()
Win32DisplayBufferInWindow()
}
|
My question is, doesn't this add what is effectively a frame of input delay and can we deal with that at all?
Here's the example in my mind:
1 2 3 4 5 6 7 8 | Game calculates information to display frame 1 Game sleeps for ~1/30th of a second Game displays frame 2 *almost immediately* Game calculates information to display frame 2 User reacts to game frame 2 that is now displayed and begins input Game sleeps for ~1/30th of a second (user input continues) Game displays frame 3 Game calculates information to display frame 4 (includes the user input during previous sleep) |
The problem is the user input was intended to affect frame 3, but it's not processed until frame 4. The time between frame 2 being displayed and input for frame 3 being collected into the game input struct is near instant. Effectively the user has no time to react to the displayed frame (well sort of, humans have >100ms delay anyways so they would be behind no matter what)
Without the majority of time being spent between rendering one frame and starting the update of the next frame most of the user's input will "miss" making it in to the update for the frame after the one being displayed.
A possible loop without this issue might look like:
1 2 3 4 | Game Renders frame 1 Game sleeps for ~1/30th of a second Game calculates information to display frame 2 Game Renders frame 2 |
Except the problem here is any time spent updating the game cannot be accounted for by the sleep duration like the loop used by HH (as of day 18) does.
Now this is a very minor delay all things considered; many monitors will introduce an equal or longer delay than this anyways. There's also very few games where such minor timings could possibly even matter (Fighting Games being the prime example). It's hardly a big issue and I'd imagine many games have such delay baked in, but since Handmade Hero is all about digging deep into the low level stuff I'd thought I'd bring it up and see if people know how to make the loop tighter, why I'm wrong and there's no delay, or whatever other comments people have.
Edited by Logo
on
The problem with this analysis is that the game never actually sleeps for 1/30th of a second. It only sleeps the CPU to use up any remaining time that wasn't used processing the frame.
In the case where we are doing our own rendering, there will essentially be no sleeping at all, because we will be burning all the CPU just to render the game without the GPUs help. In the case where we are using the GPU to do the rendering, then yes, the CPU will sleep for some amount of time (far less than 1/30th of a second, though, most likely), but the GPU is still busy rendering the game, and so it is not as if we could have computed the frame later. We had to compute the frame as soon as possible to give the GPU as much time as we can to render.
In the case where we were running on a machine that had a massively overpowered CPU and GPU relative to the game, then there would be time wasted that could produce a tighter feedback loop for the player, but the answer here would be to increase the frame rate to take advantage of the extra power, not to move the delay to before the input processing.
Hope that makes sense...
- Casey
In the case where we are doing our own rendering, there will essentially be no sleeping at all, because we will be burning all the CPU just to render the game without the GPUs help. In the case where we are using the GPU to do the rendering, then yes, the CPU will sleep for some amount of time (far less than 1/30th of a second, though, most likely), but the GPU is still busy rendering the game, and so it is not as if we could have computed the frame later. We had to compute the frame as soon as possible to give the GPU as much time as we can to render.
In the case where we were running on a machine that had a massively overpowered CPU and GPU relative to the game, then there would be time wasted that could produce a tighter feedback loop for the player, but the answer here would be to increase the frame rate to take advantage of the extra power, not to move the delay to before the input processing.
Hope that makes sense...
- Casey