Deltatime just isn´t working and I´m confused as to what to do

EDIT: As dop pointed out correctly, deltatime is working. However, stopping the sprite with tilemovement causes the issue as it stops being framerate independant. I require this stopping. If anyone has an idea how to keep the stopping while still ensuring framerate independance, please let me know!

For reference on dt: construct.net/en/tutorials/delta-time-framerate-71

c3p: wackytoaster.at/parachute/deltatimetest.c3p

Ok so my setup is as following. I have the player object moving via the tile movement behavior. Every step/tile moved, I disable the input and go into a (recursive) function. Once it ran through, I enable the input again.

This leads to a stuttery movement, especially on lower framerates, so I have the player sprite move separately. It´s supposed to closely follow the player object slightly slower and use the brief pause in movement to catch up to the object. Generally this works fine, but it isn´t framerate independent despite the use of deltatime.

The result is that the player object and the sprite go further and further apart over the course of a longer movement, but only at higher fps.

Why? Well, I´m not certain actually... My first thought was, that the function it goes into should technically run through within a single tick (I think) and a single tick isn´t framerate independent. At 60fps it will take 1/60th of a second to complete, at 240 it will take 1/240th of a second to complete. My idea was to add a "wait" into the function that ensures it will always take, e.g. 0.03 seconds.

Not only did that not work, I also dislike the idea of making my function slower than it needs to be.

My second thought was that the jerkier movement at low fps makes the conditions trigger in a way that ends up giving it a different result. Changing up the conditions (or using no conditions) also doesn´t really work, and replacing the "Set X" with the "Move to" behavior also didn´t work out. (I triggerd the "move to" within the same event where I move the player object in my main project)

I combined everything I tried aswell and still, it doesn´t work. The sprite follows at different speeds regardless. I´m trying it at 50fps, 60fps, 240fps and ~2000fps (unlimited frames mode) and while it works out on one end of the spectrum, on the other the sprite and player object desync.

I did end up doing some absolute code-butchery, where I have the sprite move faster the farther it falls behind and this works out about 90% but it´s not great. What the hell is going on? What am I missing? Obviously my main project is a magnitude more complex (and I don´t wanna post it) so maybe there is something else going on? I don´t think there is but I really don´t know anymore :)

Maybe Ashley has any idea on what´s wrong and what I could do?

I see, that makes sense. However, I absolutely need to interrupt the tile movement. I´m checking a bunch of conditions in that recursive function (and do a lot of other stuff if the conditions are met) and I can´t have the player make inputs/move around until the function ran through.

That´s why I attempted using the "wait" to make it always take 0.03 seconds but that also doesn´t work.

How do you "simulate" different frame rates to see that "it does not produce results"

My old screen died so I bought one with 240hz and I switch the hz up or down in the settings to test and compare how far the cubes go apart over the course of the movement across the screen, as that should be the same if it were framerate independent. Also there is the Framerate mode in the advanced options where you can have the game running as quick as it possibly can, which is somewhere around 2000fps in my game. I was already aware before that something isn´t framerate independent, but having the new screen kind of put a little more priority on it.

You explained what you did, as far as code goes, but I do not know what mechanic you are attempting to achieve and what result.

The object with tile movement that stutters is the (usually invisible) player object. The other one that follows is the actually visible sprite of the player. I just don´t want the player character to visibly stutter when moving, as it would if I were to just pin the sprite to the player object. So they are seperate and while the player object is waiting for the function to go through, the visible sprite has time to catch up. (But overall it should always be just slightly behind)

As dop pointed out, dt is working just fine and the dark blue square moves as it should. So the question now is how to make the cyan square move framerate independent. Artificially extending the pause from 1 tick to 0.03 seconds should do the trick, but it doesn´t work.

Here´s a comparison with the 0.03 second delay. I´ve also timed the movement of the cyan square at different fps and it takes 4.3 seconds at 60fps, 4.2 seconds at 240fps and 4.1 seconds in "unlimited" mode. So it is not framerate independent.

So the question now is how to make the cyan square move framerate independent.

Since TileMovement doesn't like being interrupted like this, I would probably remove this behavior and move the sprite (or just a pair of variables) with events. This way you can make sure it's framerate independent.

I don't think I wanna do that, I´m way too deep into using tile movement. And I don´t even think it would solve the issue with the pause. The movement itself is framerate independent, the pause isn´t. Changing the movement to anything else will still have the pause being a problem.

However, I think I found a solution that works well enough for me. I´d say 95%, which is good enough for my case. It´s still hacky, but better than what I had when I started the thread. What I´m doing now is to adjust the speed of the cyan square depending on deltatime, making it slower the higher the framerate. This accounts for the shorter duration spend on the tick it pauses. Basically I just set the speed to 500 + (500*dt)^2 The difference is small enough to not matter, and I probably could still tweak it to be even more precise. I should note that this isn´t some mathematically correct formula, I just cooked it up and found it to work very well. ¯\_(ツ)_/¯

So unless someone stumbles on an even better solution, I´ll roll with this. Thanks for the help everyone.