Re: trying Chickadee

["Thompson, David" <dthompson2@worcester.edu>]

On Wed, Sep 5, 2018 at 4:42 PM, Arne Babenhauserheide <arne_bab@web.de> wrote:
>
> Thompson, David <dthompson2@worcester.edu> writes:
>
>> Correct, the game loop doesn't stop because you're not moving
>> anything. Chickadee's game loop renders frames as often as possible.
>> If 100% of one CPU core is being used, the likely culprit is that
>> Chickadee was unable to sync it's drawing with the monitor's refresh
>> rate, which could cause it to pause a bit after rendering each frame.
>> Perhaps I could automatically factor in a small usleep call when vsync
>> is unavailable in order to avoid this situation.
>
> That sounds important. In every game loop I wrote myself till now (only
> two or three) I had to add some small delay because otherwise people on
> laptops really notice this (though the real reason why I did it — as
> opposed to the reasoning after the fact — is that it just feels wrong to
> burn cycles without need).
>
> Adding a single 1 ms sleep in the game loop should never hurt, because
> even if someone has a 200Hz refresh rate (so you only have 5 ms to
> render), this sleep still only take up 20% of the time between
> frames. And it gives you some maneuvering mass if you find in the end
> that 10% performance are missing :-)

I've read plenty of material that argues both ways.  I don't think
adding an unconditional sleep is the best move because it's entirely
possibly that the simulation is behind and needs to catch up, in which
case the correct action is to skip rendering frames and focus on
updating game state instead. When vsync is on, there is no point in
sleeping because you are already sleeping to await the monitor
refresh.  That leaves one case where a sleep should occur: When vsync
is off and there is leftover time before the next update needs to
happen.