I added a timer in the beginning of my render function and at the end. I compute the seconds that have gone by (about 0.02seconds) and used that to multiply the object's velocity. I had to change my velocity number from 5.0 to 360 for the object to go about the same speed as it did without the timer. If I pay attention closely I can see that the animation is choppy but like I said I have to pay attention very closely.

Am I missing something?

That's just wrong. It's ok to multiply the velocity by this ratio if the velocity is constant, but multiplying the acceleration by this value will screw up the physics.

Thank you sooo much it works perfectly. Is there anything else I should be doing with timers except moving objects?

Sorry, you're absolutely right.

I was thinking about dampening eg:

speed *= 0.99

...I suppose this isn't a problem either 'cause you can write it as:

speed = speed - speed*(1-0.99);

or:

speed += speed*(0.99-1);

which works fine with what you gave:

speed += dt * speed*(0.99-1);

If fact I don't know what I was thinking of... probably just being an idiot.

So, to sum up: the original poster was using time deltas calculated exactly from one frame to the next and Fladimir's fix is to use an averaging of those time deltas to avoid the low resolution Allegro timer problems.

Personally I do exactly the same thing, but have found that averaging only over the last three or four frames is sufficient - no need to average over an entire second or whatever (typically longer than 4 frame) period you calculate FPS over.

Slightly more physically correct would be

position += dt * speed + 0.5 * acceleration * dt*dt;
speed += dt * acceleration;

to take into account that the velocity is not a constant during the integration. The error by neglecting this is O(dt^2), so it is negligible if dt is small enough (and maybe negligible for in general for the purpose of computer games).

I don't use Allegro timers . The TimeKeeper class uses QueryPerformanceCounter under Windows, and gettimeofday under Unixes (I hope that'll work for Macs too).

Maybe we could implement an interface for those high resolution clocks in Allegro itself? Perhaps al_get_ticks(), al_get_ticks_per_sec()? . I think that every platform supported be Allegro provides the interface neccessary to implement that (and if not every platform does, al_get_ticks_per_sec() could return 0).

I really don't like it how even the Allegro's docs recommend to limit the frame rate to a specific number. Tell me, how many commercial games do that nowadays? None. Zero. Null. So why would the Allegro developers do that then?

Maybe because Allegro is considered as a newbie library and copy-pasting a few lines from the manual sounds like the best solution, huh? I'd say the delta time syste is, in fact, much easier to understand for new programmers than the strange increasements and decreasements. Most of us have learned some physics, right?

Makes sense, at least for discussion post 4.2.

Because they have a lot of things to do and making substantial changes to the docs takes a tremendous amount of time - especially if it's something that can be argued pro and con.
That said, there is no inherent problem with using a fixed logic rate for some types of game. It won't do very well for a 3D first-person shooter, but it's fine for a 2D top-down RPG. The main point is that games need to run at the same speed on all computers. Having a fixed logic rate more or less fixes the frame rate as well, since there is no point in redrawing frames if nothing has changed.