If it's an ALLEGRO_EVENT_TIMER and it comes from the same timer source, then you can remove it with al_drop_next_event().
That's what I'm trying to do now (mentioned in this post), but since doing it that way will only clear sequential ALLEGRO_EVENT_TIMER events, it introduces another issue: If I do something that also generates frequent events, such as moving the mouse and introducing new ALLEGRO_EVENT_MOUSE_AXES events, the queue starts looking like this:
... and so on, so rendering remains blocked until I stop moving the mouse. Since the event following a timer event is always ALLEGRO_EVENT_MOUSE_AXES, the timer events can't be cleared properly. Your loop in Allegro Flare is practically identical to what I'm using, so how do you manage to avoid that, if at all?
Update: Maybe I should cause it to ignore all following timer events after a logic update until it gets a chance to render the last frame? I'm going to try doing that when I get the chance later today. I was so focused on the idea of dropping them that I forgot I could just ignore them...
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"
It's supposed to be ridiculously expensive; like I said, this came about because I wanted to stress-test my collision system. These conditions would likely never exist in the finished product (i.e., thousands of objects colliding at once), but I want to make sure that it stutters while still being able to render, albeit at a slower rate. It's not using 100% of the CPU, it's just that since there's so much going on in the logic update that more timer events are generated than can be satisfied.
Dropping them seems to be the right idea, but it only works if they're sequential and there's nothing in-between...