Hi All

I'm hoping someone can clarify the pros and cons of two different game loop styles.

The first one, and the one I've only used, is to have a fancy while loop that makes logic run at a predetermined FPS and then have the rendering take up what ever time is left over:

(Taken from http://www.koonsolo.com/news/dewitters-gameloop/)

The other way which I have not tried, but have heard of people doing is an event driven "game loop". The way I understand it is you set up a bunch of timers. One for rendering, one for updating the logic, and one/some for getting input.

Can someone explain the pros and cons of each? Also which style is best suited for what style of game?

Thanks
Adam.

The best way is to separate logic from drawing; do your logic every loop, but only draw if it's time to draw. This forum is FULL of examples, I'm sure one of the other guys will post a link for you.

But ultimately, ALWAYS separate logic from drawing.

I think they are separate in the example code- update_game() would do the logic, and display_game(interpolation) would do the drawing.

Someone should correct me if I'm wrong, but I believe one major pro of an event-driven system would be that it would be easier to adapt to using multiple threads. Another pro is that timing of certain events would be more accurate than if you were to use a typical game loop.

For example, in a typical game loop, if update_game takes a particularly long time to spawn objects, load data, or communicate over a network, the call to display_game could potentially be later than you want it to be.

Most of the time though, I think the two methods are pretty much equally valid. I don't think either is suited to any particular type of game more than any other type of game.

This seems insane, I don't know if anybody really does it like that. The event driven loops generally seen for A5 involve a single timer and are fundamentally the same to the game loop you posted. Once you add interpolation, they become practically identical:

One thing I've noticed, not sure if it is just me, but beginners seem to have problems with what constitutes game logic. I remember that my first game I coded (back in 2006 if I remember right) I had put some game logic in my drawing routines and I've seen it done a lot being on here, Cplusplus.com, gamedev.net, and cprogramming.com. In my case I just threw it where ever just to get it working and never thought about the placement of it.

Since the OP asked explicitly: there's only one hiatus in that article: it assumes the logic to generally finish in time. When you have complicated logic f.i. 3D collisions, that condition might not hold true on slow hardware. (Kind of depends on what kind of hardware range you want to target.) So that's only important in real-time action games with complicated physics^[1] on hardware where you can expect the logic to take more than a frame's time for multiple frames.
These considerations are very small, but I always like to get detailed. In the example's case the input is bound to the logic. If the input is polled, you can miss some inputs, if the logic should fall behind. Also game time will get stretched relative to real time, which might make it hard to time input. So considerations for action oriented games only; and even then the problems are not fully avoidable.
The event oriented approach has the benefit that you don't miss any input^[2]. Keyboard and mouse input can be received as events independently^[3] of a timer.It has the disadvantage that you have to filter the input yourself in the worst case scenario.

Hi

Thanks for the replies. For some reason I thought the two methods where significantly different in purpose.

I'm trying to wrap my head around game loop designs in event-based Allegro 5. I adapted the A5 Tutorial "Bouncer" example with the game loop with interpolation algorithm SiegeLord posted (code attached). In the adapted example, a purple box that moves diagonally, bouncing when it hits the edge of the display, I get pretty smooth motion regardless of vertical refresh rate or vsync being enabled or not. Though when the bitmap changes direction abruptly (at the edges of the screen), the motion hiccups, obviously because the interpolation presumes the bitmap's direction will proceed when in fact on the next logic loop the direction changes. Is that just a limitation of using interpolation? It seems to be that "extrapolation" would be more accurate term, or perhaps I'm just thinking about it incorrectly or implemented it incorrectly?

This. You coded the algorithm to perform extrapolation instead of interpolation, hence your issues. The general algorithm tends to assume that you are interpolating between the current position and the position one game tick in the past. Your code interpolates between the current position and one game tick into the future (sort of, as it assumes linear motion will persist into the future), thus making it perform extrapolation.

Additionally interpolation game loops tend to store the old position etc. explicitly, instead of assuming any sort of relationship between position and velocity. This way your object will be less likely to display in a position it was never actually in. It also obviates the treatment of teleportation.

Ah! I figured it out. Changed this...

flux_capacitor(int gigawatts)

...to this...

flux_capacitor(double gigawatts)

But really... I stored the previous x and y positions of the object before they are updated in the game logic code block, and draw the object at...

previous position + (current position - previous position) * interpolation value.

Still not sure if I'm correct, though that yields the same smooth motion without drawing objects where they perhaps shouldn't be drawn. I suppose adding some user controlled objects will make it clear if I now have it correct or if I'm rendering in the past.

Didn't the linked article actually do extrapolation and named it wrong? It's not a bizarre thing to do, given that the thing you display is one frame behind otherwise. It does have inconsistencies then, though.

I guess I'd have to try it on a non-trivial example, but I don't think the artifacts make it worth using extrapolation. The whole point of using interpolation was to remove the artifacts, and if you're removing the jitter ones and replacing them with something that might look even worse... it seems odd to me. Interpolating on one game tick back doesn't seem to be so bad to me... at 60Hz it's 16ms lag... at 120Hz it's 8ms lag. The computers are very fast these days so upping the logic update rate would be my solution to dealing with this lag, rather than doing the questionable extrapolation.

That said, the higher your logic rate the less need you have for any sort of interpolation at all... so, meh .

SiegeLord, thanks for posting that game loop code and for the further elaboration on the interpolation. I re-worked the game loop of my first A5 creation using that interpolation method and with an only rare hiccup (maybe some other even on my system?) I get smooth as silk motion at any refresh rate with a fixed logic rate. I don't really notice input latency with a 60Hz logic rate and faster than 60Hz is indeed no sweat on modern hardware and for what I'll be coding. I would have been otherwise implementing delta time with variable logic rates, which I now see from another posting is a bad idea. Now to trace it and actually understand what it's doing.