Straight Line vs. Delta Time: Calculation woes

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.
• 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.

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

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

My old system for moving the characters worked as follows:

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:

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:

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...

• Quote

won't there eventually be a problem with the value getting too large?

Yes, the timerLast value should function for about 2 weeks before getting to large. You could try buffering it in a string, if you dare I have to test it myself before verifying it as a solution. It's probably better to do an extension... hmm, I should do that.

Quote

I never found a solution back then either...

The natural next step is to utilize buffers for XY movement. Then learn trigonometric ratios. Muddymole has them on his site, I have them in my examples and so does SolarB.

• 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!

• To calculate DeltaTime I have switched to the method below.

Code
``````• Always
- Set DeltaTime to 1 / ( FrameRate + 0.0 )``````

That way I avoid the problem of DeltaTime becoming too large, and also I only use a single value instead of two. The added bonus is that in the case of a frame rate drop, FrameRate will fluctuate more smoothly because it is based on the average frame rate of the last 5 loops or so (must be confirmed by Yves).

• Quote

Set DeltaTime to 1 / ( FrameRate + 0.0 )

Really, Olivier...