How do I properly use delta-time

Hello!

Recently, I've discovered an issue with a different speed of moving objects on different PC's. At first, I thought that this is some weird bug, but after I did some proper research (which I should have been done at the start), I found the function called "delta-time". This prevents moving sprites, that do not use behaviors, from acting differently, depending on FPS and a system that runs the game. I found a tutorial and a post about that, but I still can't wrap my head around it. Let's say, that every tick a sprite moves on 6px to the right (Self.X + 6), then what will be the analogue of six pixels, if I choose to use delta-time function? Is there any formula that can be used to translate the sole number of pixels into its delta-time analogue? Many thanks in advance!

Update: Looks like the only way is to rewrite all of the functions that use simple sprite movement and find out the new "speeds" from scratch. This whole time I was seeing the distorted movement speed that was based more on the specs of my PC than on real numbers (I suddenly realised that 6px per second is much much slower that I saw everyday in my browser for the past month

See this illustration:

https://www.dropbox.com/s/hr8lufxsfsm1x ... .capx?dl=0

So. Simplified.

Think about dt as the factor you need to divide Something/Second into Steps/Tick.

'Something per second divided in Steps per tick' = 'that Something per second' * dt

Or, if you need something to fly at a speed 400 (units in pixels/second), then move it every tick at 400 * dt (now in units pixels/tick)

If I am correct It exists because anything that is using delta time to correct itself is skipping over showing you certain frames to show you the correct frame as if your computer was keeping up. The measurement is totally disregarding the performance of your computer to keep the game to a consistent speed. I imagine if old NES games like Castlevania were to use delta time than instead of slowing down you would have been playing nintendo at 2-5fps which would have made it much harder to dodge say an unexpected fireball.

As far as converting the numbers, I know exactly what you are talking about. 400px per seconds never turns out to be 400 * dt for me I myself have had to make totally different wild estimates on numbers when using delta time, but I eventually find the right one.

If I am correct It exists because anything that is using delta time to correct itself is skipping over showing you certain frames to show you the correct frame as if your computer was keeping up. The measurement is totally disregarding the performance of your computer to keep the game to a consistent speed. I imagine if old NES games like Castlevania were to use delta time than instead of slowing down you would have been playing nintendo at 2-5fps which would have made it much harder to dodge say an unexpected fireball.

As far as converting the numbers, I know exactly what you are talking about. 400px per seconds never turns out to be 400 * dt for me I myself have had to make totally different wild estimates on numbers when using delta time, but I eventually find the right one.

I see...well, since the tutorial says that behaviors already used built-in delta-time, it means that everything is not so bad, in my case. Most of "moving" things, except some "enemies" sprites are being moved using behaviors in my project, so I'll just have to tinker with the rest (which consist the smaller part of game's objects). Thanks for the answer, though!

Whenever you are doing some sort of calculation every tick, you will most likely need to take dt into consideration.

Executing "Set X to Self.X + 6" every tick will make your sprite move 6 pixels per tick to the right. Which is ~360 pixels per second on a ~60 fps machine. So if you want your sprite to move 360 pixels per second to the right, whatever the framerate is, then simply do "Set X to Self.X + 360 * dt".