That's one thing delta timing protects against. If you're going to make a sophisticated AI, you will give it time to "think". So 5 milliseconds elapses and the AI needs 3 ms to make a decision, it takes the 5 ms, thinks for 3, then does it's action for 2 ms. Next frame comes around, 10 ms has elapsed, maybe the AI needs more time to act or maybe you use some of that time completing an action and the rest on thinking (or starting to think) about the next action it will take.

You may want to skip on a variable delta time approach, GP2X. As you've pointed out, when delta time changes it can affect the accuracy of motion and thus obtain different results all the time. This is dramatically apparent when doing multiplicative movement or using smooth-shifting acceleration values. You can counteract this problem with exponents, but it can really become a mess when trying to do things like collision detection.

The approach I personally use now is similar to delta time, but not. The idea is to run your logic at a very high fixed framerate, and then between each rendering of the screen you count the number of logic frames to process and process that many of them. So if your game logic runs at 200 FPS and you're getting a framerate of 50 FPS, you make 4 logic updates between each render of the game screen.

The way that works is to set up a very high frequency timer in Allegro. (This will work perfectly fine in Windows as Allegro knows how to use the Windows High Performance Timer, I dunno about other operating systems.) You want your logic to run at a very high framerate. Too high can kill the framerate, too low will look choppy. I find 200 FPS works well. Your timer should simply count up a variable.

When it comes time to do a run of your game loop, copy the timer's variable and reset the actual timer to 0. Then, simply process your logic as many frames as the copied timer value has counted up. Once done, render the current state of the game to the screen, rinse and repeat.

A fixed logic rate ensures that you will get the same results on any system, and making the logic framerate independent of the actual framerate ensures that it will still look and play right, even if the actual framerate dies horribly because the player's trying to run your game on a 486 CPU.

If the logic rate is high enough, jitter is very hard to notice. I should know, I've been testing my current project, which runs this way, at numerous framerates arrived at through varied wait times introduced into the game loop. Even triple buffered at 120 FPS, which my CRT monitor can handle, with a logic rate of 200 FPS, the game looks perfectly fine. Having a high logic rate means that if the actual framerate drops low enough that timing artifacts could theoretically be noticed, the difference between seeing say 6 fixed frames and 7 fixed frames processed for a split second becomes trivial and will still go unnoticed.

Also consider television where movies run 24 FPS and TVs run interlaced 60 FPS from a 30 FPS signal. We don't see timing artifacts there, do we?

I actually had a system where I was interpolating between frames based on how far along the game was between two fixed frames during render. This is the type of system some commercial games use, such as those made with the Quake 3 engine, but I found running a higher logic rate was just as effective, easier to program, and not as big a drain on the rendering framerate as I originally expected. PixelShips Retro, one of my games in the Depot, runs a 30 FPS fixed framerate and uses the interpolation system I came up with, thus even if it only runs 30 FPS internally, it can look like it's going ANY framerate perfectly smoothly.

With a delta-time approach, having limits on the amount of change which can occur before updating acceleration deltas can get very confusing, because now you not only have to track how much movement is left while moving an object, but you also have to track the change in acceleration for each movement step. I've done it before and the math was insane, and it gets even harder when you do multiplicative acceleration compared to linear. x_x;

I think what it boils down to is this:

Delta Time Approach
Pros: Can achieve the best looking framerates, less processor intensive.
Cons: Difficult to program and get accurate.

Fixed Logic Rate Approach
Pros: Much easier than Delta Time to program and get accurate.
Cons: Cannot render framerates above its maximum limit, more processor intensive.