Straight Line vs. Delta Time: Calculation woes

I'm having some trouble adapting the movement system in my game to delta time. The game takes place on an isometric grid and the characters are supposed to move in straight lines between grid coordinates. I had a system for this that worked perfectly, but then I implemented delta time and the characters now move in crooked lines. I know the cause, but can't think of a good solution.

I've attached an image, showing the lines in which the character moves. As you can see, the dotted line is sometimes straight but is crooked for the most part. The occurance is random but it depends on the current framerate and how it affects the delta time.

Please login to see this attachment.

The game initially ran at 30 fps. I've now set it to 1000 fps and use tompa's deltaTime formula:

+Always
- delta = (timer - timerLast) * 0.001
- timerLast = timer

My old system for moving the characters worked as follows:

+On Movement Start
- moveTimeTotal = 128 / 8
- moveTime = 0


+Always
- character.X = character.FromX + (moveDistance.X * (moveTime / moveTimeTotal))
- character.Y = character.FromY + (moveDistance.Y * (moveTime / moveTimeTotal))
- moveTime ++


+moveTime > moveTimeTotal
- Stop Movement


(the moveTimeTotal calculation is just an estimation to move the character in even steps, 128 is the grid width)

With this system, the character would move (roughly) X+4 and Y+2 each cycle. Resulting in a straight line from Point A to B.

After implementing delta time, I've had to multiply the timer values. This is because the deltaTime returned floating values and I use an array to store all the values (which doesn't handle floats). It now looks like this:

+On Movement Start
- moveTimeTotal = (128 / 8) * 1000
- moveTime = 0


+Always
- character.X = character.FromX + (moveDistance.X * (moveTime / moveTimeTotal))
- character.Y = character.FromY + (moveDistance.Y * (moveTime / moveTimeTotal))
- moveTime = moveTime + ((30 * delta) * 1000)


+moveTime > moveTimeTotal
- Stop Movement


("30 * delta" was also just an estimation. I used the value 30 because the old fps was 30 and I thought I could achieve a similiar speed)

With this system, the character might move X+4 on one cycle and X+5 the next since the way the value moveTime increases each cycle is uneven.

Basically I need to figure out a way to use deltaTime but get a result where the value moveTime, on each cycle, still increases by 1 or at least an even number dividable by 2. Any ideas?

I switched things around a little. I added an additional counter affected by delta time, and that in turns controls when the character moves. It now looks like this:

+On Movement Start
- moveTimeTotal = 128 / 8
- moveTime = 0
- moveDelta = 1000


+Always
- moveDelta = moveDelta - ((30 * delta) * 1000)


+ moveDelta is lower/equal than 0
- character.X = character.FromX + (moveDistance.X * (moveTime / moveTimeTotal))
- character.Y = character.FromY + (moveDistance.Y * (moveTime / moveTimeTotal))
- moveTime  ++
- moveDelta = 1000


+moveTime > moveTimeTotal
- Stop Movement

This works fairly well I guess. When the FPS is 60 or greater it behaves the same, but at 30 it moves a bit slower. I realise this moves against the idea of delta time, but it still looks quite smooth and it's never supposed to run slower than 30. Would still welcome a better solution.

Just curious, as the delta time counter (delta) keeps increasing, won't there eventually be a problem with the value getting too large?

Edit: I just noticed that I already made a thread about a similiar problem, couldn't find it when I searched yesterday though. I never found a solution back then either...

d'oh, yes I meant the timerLast value. So the game can run for two weeks before that happens? Sounds like I won't have to worry about it!

Buffers & trigonometric ratios, eh? I always had a rough time with trigonometry, but considering how useful it seems I guess I will have to try and get properly acquainted with it. Thanks!

That's excellent, Oliver. Thanks!