When I started using Allegro, I was in a rush to finish a college project with it, hence my study time was low. Originally, I just used the clock() method of somewhat governing my game. For ChristmasHack, I decided to use/learn the allegro methods.

After a little messing around and reading other discussions about timers (there's quite a bit if you do a forum search), I've got a basic understanding. I thought I'd present my methodology and see what the general consensus is, pros and cons.

Without further ado,

My timer function is very simple:

volatile int system_timer;
void GAME_TIMER()
{
    system_timer++;
}
END_OF_FUNCTION(GAME_TIMER);

In the init routine at the beginning of the game, I do the following:
install_int_ex(GAME_TIMER, MSEC_TO_TIMER(1))
where the idea is that system_timer increments every millisecond. The LOCK variable and function commands immediately follow.

Here's where system_timer begins to control things, at least, if I've imagined this correctly. I kind of use a time stamping method. Typically what I do is create timestamp-like integers that remember when a certain time occurs and when there is a certain amount of difference between the timestamp-like integer and the system_timer, then whatever to follow is allowed. e.g.

if(abs(system_timer - some_timestamp_integer_x) > some_determined_amount_of_time)
{
     //do whatever it is that you want to do
     some_timestamp_integer_x = system_timer;
}

To further explain, each one of my AI bots has it's own private int called "move_timer" (defined in the class) and public (this could be private as well) int "move_speed". Changing the "move_speed", I can have my AI bots walking at different speeds:

if(abs(system_timer - bot.move_timer) > bot.move_speed)
{
    // take a step in whatever direction bot is facing
    bot.move_timer = system_timer;
}

The whole idea is to have just one timer variable and the others just pretending like they're timers. What do you think? Is that a bad idea? If so, why?

If I rememeber right the allegro timer is only accurate to ~10ms, but that should be good enough for any game.

I wouldn't think so either, but I had no idea how accurate allegro could get it, so instead I opted for 1 millisecond and then shoot for an approximation. So if a certain timestamp was waiting for there to be a difference of 50ms, it might not be till 51ms, 52ms, etc. until it actually validates the difference and updates the clone. At least, that was the idea. Since I'd probably never say "when 53ms have passed", I'll probably change it to 10ms or something a little more agreeable.

I don't know. If 200ms works for you I don't see a reason. Remember, don't fix it if it isn't broken

If you're happy to throw a Win32 specific call in to your code, you can use timeBeginPeriod to get a much better resolution on all Windows since 95.

It is a good idea. If you aren't using an update method that syncs to the retrace you might also want to consider a frame cap implemented via rest() so that all the laptops and modern desktops can power save and/or switch off some fans.

Allegro timers have 2 major problems. First, their granularity, which differs per platform (and possibly per system). While 10ms is short enough an interval, the frequency generated from the interference of the game timer (the rate at which your position variables are updated) and the screen refresh rate (the rate at which they are displayed) can lead to very noticeable "jumps" in what is intended to be smooth movement, since there will not be a constant number of timer ticks between two (screen) frames. For example, if refresh rate is 72 Hz, and the timer runs at 10ms, then there will be 100/72 ticks per frame - some frames will contain a single logic tick, while others contain two. So in some frames, the character will move twice as far as in others.
The second problem is that allegro timers are "active" timers, meaning that for each tick, a function needs to be called, even if the logic doesn't do anything. The finer the timer resolution, the more cpu it will eat. While at 25 Hz (50msec), the cpu load is barely noticable, at 100 Hz (10 msec) the difference starts to play. "Passive" timeing methods (that only read a timer that is running anyway, such as system clock or windows' QPC), OTOH, only require a single function call per screen update; the timer itself is running anyway, you won't need a dedicated thread or process, nor does it need constant polling or updating.
In short: Allegro timing methods look nice, elegant, and useful, but aren't. I only use them as fallback when other methods aren't available.

I was recently misdirected to a page about a timer lib named "ltimer". I didn't check it but it was presented as better than any other. I guess it was win32 only. Maybe Allegro can use the algorithms of that or another nice working one(for matching ports at least) For now, I will stick with Allegro's timers since I don't like using too many external libs together.

I think clock() is even worse than allegro timers.

If all you need is a variable that gets updated frequently use platform specific stuff. QueryPerformanceCounter on windows and gettimeofday on *nix work perfectly.

Steven it's a game, it's not a nuclear station control software. Allegro is more than enough for a game.

I think that doesn't stop almost every professional game developer from using it

As fro clock, this s what manual says about it:

       Note that the time can wrap around.  On a 32bit system where CLOCKS_PER_SEC equals  1000000  this  function
       will return the same value approximately every 72 minutes.

       On  several  other  implementations,  the value returned by clock() also includes the times of any children
       whose status has been collected via wait() (or another wait-type call).  Linux does not include  the  times
       of  waited-for  children  in the value returned by clock().  The times() function, which explicitly returns
       (separate) information about the caller and its children, may be preferable.

I don't remember the granuality of it but I think it was quite bad. The CLOCKS_PER_SEC usually don't mean anything because:
POSIX requires that CLOCKS_PER_SEC equals 1000000 independent of the actual resolution.

Up until now, I have found only three methods that produce smooth animation.
Number 1 updates logic along with screen refreshes. That is, every physical vsync equals one logic tick. Unfortunately, this means that the speed of your game depends on screen refresh rate, and unfortunately, modern system may or may not allow you to set it to a value of your choice. For all other systems, you have to either adjust all time-related variables (acceleration, speed, etc.) to fit the actual refresh rate.
Number 2 uses the RTSCXVKR-whatever counter. This method has several flaws though. First of all, it only works on pentium compatible cpus. Macs are out (though there may be similar mechanisms there). Secondly, there are cpus with variable clock frequencies (notebooks mainly), and since the counter counts cpu clock cycles, its speed may vary on such machines. And thirdly, there is no reliable way to detect the exact cpu speed except measuring it against yet another timing source, like for example RTC.
Number 3 uses QueryPerformanceCounter. It's windows-only, but Linux has gettimeofday() which is supposed to be comparably precise. I haven't found any problem with these yet, except that QPC is not guaranteed to work (but windows can tell you whether it does or not).
So what I did is this: I wrote a rather simple wrapper that uses QPC when available, and falls back on allegro timers in the rare cases when QPC isn't available. With some clever defines, this can easily be extended to support gettimeofday as well. In every project that needs timing, I include that wrapper, providing me with a fool-proof 3-function api (init_timers(), get_timer_delta() and done_timers()).

Try these: http://www.twinkies.com/images/box_hohos.jpg HoHos

heh, they look tasty