My game loop uses a timer to run at 60 FPS:

When it comes to rendering, the following condition is checked beforehand:

It's my understanding that checking that the event queue is empty before drawing is important so that rendering doesn't "fall behind". But this poses a problem when the update portion of the loop takes longer than 1/60th of a second to complete-- the event queue is never empty, because (I think) the update took long enough that another timer event was triggered. Thus, nothing is ever rendered.

Could someone offer me some advice for dealing with this problem? If I render after every update without checking if the event queue is empty, would I be at risk for any major problems? Would it just decrease the "actual" framerate when under load, and then recover afterwards? Is there something important that I'm not considering?

One potential issue I see is that the timer would generate more events than could be processed, since the update is slower than 60 FPS. Is this a valid concern?

Removing the emptiness check seems to work fine (I end up with around 50 FPS) but I'm worried there might be something I'm not seeing that will come back to haunt me...

Update: It seems to be as I feared; the timer events block other events from being processed!

That's what I thought... If the logic portion takes longer to complete than it takes the timer to tick, how can that be helped? Short of decreasing the level of processing, is the best solution here just to clear the event queue of any extra ticks after each logic update?

This problem came about as a side-effect of stress-testing my collision system. Rendering stops because the logic cannot be processed at 60 FPS (with thousands of bodies; the system itself is fine at a reasonable scale), so the event queue fills up with timer events as a result and is never empty to allow rendering to occur.

Obviously, it's better to have the game start lagging than to have it stop rendering altogether. So, dropping the extra timer events should do it without any hidden consequences?

Update: Hmmm, maybe not. I added this at the end of the logic update:

But now if any other type of event is triggered (e.g., ALLEGRO_EVENT_MOUSE_AXES) rendering stops until that event stops occurring. I'm not sure why that is; I'm still investigating.

That's true, but if I dump the whole thing, I lose everything that's behind the timer events and it stops responding to most input.

I'm using a fixed time-step. Here's a simplification of what the loop looks like:

I want to avoid interpolation and other fancy things for now-- My only goal at the moment is just to have the game continue rendering, even if it's stuttering.

I get what you're saying-- Count the logic ticks, and if they're above a certain threshold, drop all remaining timer events so it can render, and also prevent the timer events from continually accumulating (which would probably cause an overflow eventually). Right?

At this rate, it seems like I'm going to have to use a wrapper myself to have more control over the events. I was hoping there would be some way to do it using Allegro directly, but it doesn't look like there's an easy way to drop the remaining timer events.

If even the logic part alone takes 100% CPU, there is no way you can additionally DRAW something.
You need to either :
- consider better hardware
- locate a mistake in your code which makes something very expensive for no good reason (ex: file I/O during logic)
- locate expensive work and make less of it. Typically : path-finding.
- reconsider the size of your "time-steps"

IMO, it's not a good thing to modify the system to perform better in these cases which-never-happen, if it performs worse in cases-that-happen.

For example, the typical frame-dropping system performs very good in case of tiny hiccup (ie. Antivirus hogs resources for 1/10th of a second), because it catches up the missed ticks : over 10 seconds, you keep exactly 600 logic steps.
Dropping "timer" events means these will be slowdowns (less than 600 logic steps over 10 seconds).

Using two separate event queues would mean that the order of events would change, and events would be de-synchronized with the game as it played.

Earlier, when I said you should empty the queue, I was talking about a game loop something like this :

This has the advantage of dropping all extra timer events that may have piled up without losing any input. And because you're processing every single event in the queue you can't get behind. It should slow down somewhat gracefully, without destroying your fixed step determinism. I'm curious to see how this loop would perform in your collision stress test.

EDIT
If it takes a long time to process your logic, and input events are received in the meantime, this method could fail, because there would be timer events in-between the input events.

At some point, you're just going to have to slow down your timer. Ideally you want your logic to take up somewhere around your timer rate minus a few milliseconds to allow for drawing.

EDIT2
What I meant to say was, you want your timer to tick at a rate of your logic duration plus a few milliseconds for drawing. That way, it won't ever get behind.

If you are willing to, you could add a freestanding version of your new game loop to the allegro wiki's Timer tutorial, as a second example. That way you could help new users starting to use the API (and veterans as well) have a better way to implement a game loop with Allegro.

Or you can post the code here and either me or someone else can add it then on the tutorial page. Last time it was updated was way back on 2013. Countless Allegro applications have been built using that code as a starting point.

If you drop up to 10 frames, your game could end up running at around 5-6FPS.

Personally, I think you would be better off with either an adaptive timer rate, or simply dropping all timer events after the first. That way, your game would run as fast as possible, while still keeping your fixed step determinism.

How about not using a timer at all, and just redrawing whenever a redraw is needed?
The effect is that the game will slow down if processing the events takes longer that it should, but at least you'll get 1 frame per iteration and it won't clog:

Right, right, I forgot... but you fix that adding an al_rest() somewhere. You can check the difference between old_time - new_time and 1.0/FPS to get an idea how much to rest, or something like that.
I still much prefer this method than using a timer that potentially clogs the queue.

If you look at the timer thread process for allegro's timers, it uses al_rest internally to wait for timers to tick. So the timers are just as accurate as the granularity of al_rest.

And for example, on Windows, al_rest uses Sleep internally :

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686298%28v=vs.85%29.aspx

So there's really not much point (on Windows at least) to use anything other than al_rest, as that is what is going to be used anyway. At least that's my understanding of what the code is doing.

EDIT
Actually, the timer tick count should always be accurate, but it may be behind by up to the granularity of al_rest. It uses al_get_time for elapsed time and tracking counters.

EDIT2
Allegro may be able to achieve higher resolution timing on Windows using Waitable Timer Objects. If al_rest used a synchronization timer, it could be much more accurate.

There's no trouble if you simply process all the events in the queue at once.

See my earlier post for a solution.
https://www.allegro.cc/forums/thread/616480/1025001#target

Another advantage of timers is being able to have multiple timers active. Trying to simulate that with al_rest would be a nightmare to do yourself, always trying to figure out which "timer" would tick next. Say you had different animation rates or different logic and drawing rates. These would be easier with a timer than with al_rest.