Damn, just found out one big mistake with the code I posted:
float timeBetweenFrames = 1000.0f / (float)updatesPerSecond_;
This will lead to a timeBetweenFrames 1000 times too large. :lol: Should be:
float timeBetweenFrames = 1.0f / (float)updatesPerSecond_;
This explains the non-responsiveness of my first code example. So apparently it has nothing to do with polling for events only once per loop.
So, uh, problem fixed I guess.
While we're at it, I have a question about the following article on
http://dewitters.koonsolo.com/gameloop.htmlHere is the part I don't get:
Our first solution, FPS dependent on Constant Game Speed, has a problem when running on slow hardware. Both the game speed and the framerate will drop in that case. A possible solution for this could be to keep updating the game at that rate, but reduce the rendering framerate. This can be done using following game loop:
const int TICKS_PER_SECOND = 50;
const int SKIP_TICKS = 1000 / TICKS_PER_SECOND;
const int MAX_FRAMESKIP = 10;
DWORD next_game_tick = GetTickCount();
int loops;
bool game_is_running = true;
while( game_is_running ) {
loops = 0;
while( GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP) {
update_game();
next_game_tick += SKIP_TICKS;
loops++;
}
display_game();
}
The game will be updated at a steady 50 times per second, and rendering is done as fast as possible. Remark that when rendering is done more than 50 times per second, some subsequent frames will be the same, so actual visual frames will be dispayed at a maximum of 50 frames per second. When running on slow hardware, the framerate can drop until the game update loop will reach MAX_FRAMESKIP. In practice this means that when our render FPS drops below 5 (= FRAMES_PER_SECOND / MAX_FRAMESKIP), the actual game will slow down.
He says "The game will be updated at a steady 50 times per second, and rendering is done as fast as possible." However, looking at that code, it seems display_game() is called a maximum of once per loop, while update_game() may be called several times being in that inner while loop. In other words it looks like it is the contrary of what he's saying: the game will be updated as often as possible, while the rendering will take place a fixed number of times per second.
Am I right (I hope not)?