Hi, I've been trying to get to grips with the timer events and timers because I'm trying to work on the speed of animations.

I wrote this code :

I get this output :

Got timer event.
timer count (first time) is 4.
Incrementing loop_count.
Got timer event.
timer count (second time) is 4.

If someone would take the trouble to take a look at the code you might notice that despite the output confirming that a timer event and the ++loop_count; line have both occured imbetween the two points where al_get_timer_count is called the two calls to al_get_timer_count() both return 4. This doesn't make any sense to me. Does someone know why it's happening?

Trying to wrap my head around what you have

start: glc = false, cl = false;

1st iteration: a printed, b ignored, c processed
cl = true, glc = false, tcb is set

cl is true so loop_count increments once

2nd iteration: a printed, b processed, c ignored
cl = false, glc = true, tca is set, tc is calculated (tca-tcb)

cl is false and will always be false after this point
loop_count not incremented.

3rd iteration: a ignored, b ignored, c ignored

Nothing happens after that because cl is false and glc is true

What is it supposed to do?

Your code doesn't really make sense. Keep it simple. Allegro has everything you need in the timer event itself.

do {
   ALLEGRO_EVENT ev;
   al_wait_for_event(queue , &ev);
   if (ev.type == ALLEGRO_EVENT_TIMER) {
      old_ticks = tick_count;
      tick_count = ev.timer.count;/** forgive I can't remember if this is right*/
      do_stuff_with_ticks(tick_count - old_ticks);
   }
   else {...}
   
} while (!al_is_event_queue_empty(queue);

No, the code isn't familiar but it makes perfect sense. It does exactly what Daniel described. Thenks Daniel for working it out.

What it's meant to do is simple :

It calculates how many clock ticks it takes to run the code after the event loop.
I need to know this because I need to how frequently my drawing code gets executed. (I simplified the program and left out the drawing code).

So it makes a record of the timer count. Then it does one run of the code after
the event loop. Then when the code gets back to the event loop it waits for the next timer event and records the count.

What doesn't make sense it that according to the event queue there's a new timer tick but the timer count hasn't changed. The manual does say that once al_wait_for_event get's an event it copies the event into the ALLEGRO_EVENT * provided and removes it from the queue so the next ALLEGRO_EVENT_TIMER should be a new clock tick meaning the number returned from al_get_timer_count should be larger.

BTW If I call al_flush_event_queue which shouldn't be necessary the code works as expected.

Don't use al_get_timer_count. That is supposed to be always up to date. Use the tick count from the event. If you need to profile, use a high performance timer. There is one available in Eagle.

How frequently compared to your logic timer? Or do you want an FPS counter?

Normally you would just draw once per logic update. And maybe skip the drawing when the event queue is not empty after the logic is done to avoid getting behind.

Thanks very much to both of you.

It's got to be only as frequent or less frequent right? If it can't be more frequent I'd have to decrease the ticks_per_second passed to al_create_timer() EDIT : if I wanted to slow down the graphics updating ?.

I did also want an FPS counter and I figured that was sort of what I was doing in a not so normal way.

al_wait_for_event will limit your frame counter to events. If you want to calculate FPS then draw every loop iteration and only process an event if there is an event.

Check out my Tic Tac Toe game. I don't wait for events.

You could remove the 'dirty' check and add a couple vars (frames and seconds). At each draw, increment a frame counter. At each timer increment a seconds counter. FPS = frames/second;