How do I get a stable deltatime?

Ashley himself says you don’t need delta time there!

During the aiming stage and trajectory calculations, delta time is irrelevant. You only need it after firing the projectile to adjust its speed.

you're fundamentally doing the wrong calculation.

Maybe. I don't argue. But let me explain my logic. Maybe you can tell me how to do it better.

With a simple example.

The sprite moves every tick by 1 pixel along the X axis, and stops when there is a collision. Usually, we multiply this number by dt, right? Now, I need to calculate the movement and write to a variable the time after which the sprite collides with an obstacle. I use a loop, and instead of ticks, I use a loopindex. If I didn't use the tajectory forecast, I would multiply the movement by dt. So, I need the object to move inside the loop exactly as it would move outside the loop, i.e. in real time. How else can this be implemented?

If you're doing something like stepped collision checks, then you can just use any fixed time step. The only difference it makes is how many checks/collision accuracy. For example you could just use a fixed time step of (1/60) and it will have about the same accuracy as frames when running at 60 FPS but with no variation at all because you used a fixed step.

Computing the exact path an object will move is a tricky problem. Between collisions we can calculate the path exactly but when the collisions occur will vary. The reason for this is motion if done in steps so once a collision is detected it’s usually overlapping a bit already. Typically the exact point where the objects just started colliding would be somewhere between the steps.

Two solutions come to mind.

The first is to calculate the exact time of collision. Fairly complex but basically when an object isn’t colliding one step then overlaps the next you’d find the position in between where the objects touch. Then you’d have it bounce and do the calculation again for the remainder of the step. You’d need to do this both for the predicted motion and normal motion. You’d probably want full continuous collision detection with swept volumes to not miss glancing collisions with corners. Anyways you could get a pretty accurate path that way. But there is always some precision loss with the calculations so the actual path will diverge from the predicted path a bit the further down the predicted path you go.

Another idea is use a fixed timestep to calculate the path of the object. That would give a consistent path. Then to move the object just move it over that calculated path. Basically you’d calculate a list of xy positions with the time at those points. Then you can interpolate the moving objects position over that in a frame independent way. So you could for example simulate the path at a fixed 30hz and no matter the screen refresh rate it would follow the exact path.

The main annoyance of that is you wouldn’t really be able to use behaviors for the motion anymore, but I guess the same can be said about the other idea.

I’ll see if I can drum up an example of the second idea later.

Here's my tests with the ideas I mentioned.

With this you simulate the path and simply reuse that same path when you want to move along it. You can make the simulation step anything, but when moving along the path it moves in a framerate independent way.

dropbox.com/scl/fi/ksuj6rfhow2q5gf19jdcq/path_perdict.capx

Here's an iteration on the idea. The previous capx simulates by moving, and once a collision is detected it uses the normal to push the object out and bounce. This one finds the time of collision by assuming motion is linear between steps and interpolating when the collision occurs and moving to that point before bouncing. This could be done even better, but it seems fine.

dropbox.com/scl/fi/70e4s84lsjz1wyxo65lwi/path_perdict_percise_contact.capx

Anyways, just some examples to demonstrate the ideas I mentioned.

this code is a bit complicated for me. I will need some time to analyze it. But it looks very cool. Thank you very much!