Towards the end of our loop:

1. we test the time taken since LastCounter
2. sleep the remaining time up until our TargetSecondsPerFrame
3. call Win32DisplayBufferInWindow()
4. then finally reset LastCounter

Doesn't this ignore the time taken to process Win32DisplayBufferInWindow? (currently just a call to StretchDibs or something similar).
So each frame takes at least TargetSecondsPerFrame + Win32DisplayBufferInWindow time.

Shouldn't we just reset LastCounter at the end of our Sleep to keep measurements consistent?

Or should we do this by moving the display buffer call before the sleep call? This would mean we would displaying the graphics buffer closer to when we fill the sound buffer. Wouldn't this mean the graphics/audio sync would be better? (tbh I don't really understand the audio buffer setup yet and I think we deal with that in more detail on the next video).

PS - A huge thanks to Casey for this awesome project, and to everyone else who helped with the site and other resources. I'm really enjoying myself and am tearing through the archives trying to catch up with the live stream!

mallardz

Doesn't this ignore the time taken to process Win32DisplayBufferInWindow? (currently just a call to StretchDibs or something similar).
So each frame takes at least TargetSecondsPerFrame + Win32DisplayBufferInWindow time.

Shouldn't we just reset LastCounter at the end of our Sleep to keep measurements consistent?

Ok, so the very next video deals with this and the answer is yes we should!