Hello and welcome to another episode in the Godot basics tutorial series. In this episode we will be taking a look at Delta time when dealing with game programming and especially when dealing with game engines. Delta time is probably the most important thing to understand in your game programming journey. In summary delta time - also referred to as a lapse time and can also be referred to as Delta Timing - is a concept used by programmers in relation to hardware and network responsiveness. The The name Delta time comes from the physics math formula for the change in time Delta coming from the Greek letter followed by time and in the physics episode we went over that briefly but a quick summary it change in time is basically t to minus t 1. Moving on specific to game programming we refer to the elapsed time between the last frame that was drawn onto the scream and the current frame that is drawn to the scream as delta time. One thing to keep in mind is that in Godot delta time is a flow value.

We're gonna take a look at issues with flow values towards the end of this episode. Let's go ahead and take a look at an example in this game we are running at 4 frames per second. And so to understand delta time we have four frames are first frame is at position time 1 or second frame is that position time 2 or third frame is at position time 3 and fourth frame is at position time for now the distance between R time 1 and our time 2 is what we refer to as delta time in game programming we have two concepts for creating equations. The first is called frame rate dependent. The second is called frame rate independent. So first let's look at a frame rate dependent problem and solution. So we still have the same thing four frames per second and we're showing four frames to our user every second. Now let's say for this exact user we know four frames are going to be shown to them. Now we have a game object and we want it to move 100 pixels per second. So when we want our game object to move we tell it that we would like our game object to move 25 pixels per frame.

And if we start here at zero we are at zero pixels. When we move one fourth of our time in this case point twenty five we are at twenty five pixels. When we move to half a second. Our game object is at 50 pixels from its original position. A displacement of 50 pixels. And then when we go two point seventy five our game object is now seventy five pixels away from the original position. And then when we hit time one as in when one second has elapsed we have went one hundred pixels. In this case to our right and this is fine if we know that our specific user is only going to show four frames per second. However when we deal in game programming we cannot assume that every other computer is going to handle their games at 4 frames per second. As a matter of fact depending on hardware CPI you. All that fun stuff. Every computer is different. Some are faster than others. And so let's take a look at an example when we're dealing with a user that has 60 frames per second.

Now we're still frame rate dependent as in we are. Code is still telling the game object to move 25 pixels per frame. However since our new user is now running at 60 frames per second this is an inherent problem. Now in the last example we wanted our game object to move 100 pixels per second and that was fine for our first user whose computer could only handle four frames per second but now our new user probably has a supercomputer can run their game at 60 frames per second. And this is the problem with the first concept of being frame rate dependent. In this case it's a simple math formula. Take the amount of frames we can run per second which is 60. Multiply that by our old code which is 25 pixels per frame and now our game object is moving one thousand five hundred pixels a second. Compare that to what we really want happening which is 100 pixels per second. And so the first way of dealing with movement in this case the first concept being frame rate dependent has an issue.

So now how exactly do we go about dealing with this problem with the fact that people have different computers they run at different speeds. Basically that takes us back to Delta time delta time. Basically these couples are graphics from our logic. And so in this case when we want to write a formula to have the same behavior among multiple computers we use delta time. And so we would say if we would like our game object to move 100 pixels per second we take the amount of pixels we would like to run at and we multiply it by delta time. This ensures that no matter what computer specs a person has or uses we ensure that the behavior is the same among multiple Oh hardware situations where we are no longer dealing with the amount of frames a user has. But we are dealing directly with time itself. And so in theory when we combine our Delta times for the first second we will in fact get to a 100 pixels per second or at least somewhere close to that. So when exactly do we want to use delta time as a beginner when you are dealing with movement.

That is the perfect candidate for using Delta time. Also one more thing if you are dealing with any physics formula that has the actual delta time in its formula you will want to use the game engines version of delta time on top of that you're not just limited to movement. Basically anything that requires you to be frame rate independent is a perfect candidate for delta time. Now we will be looking at two virtual methods in Godot that give us delta time just to make one thing clear all game engines give you a way to handle time through the use of delta time. Now every game engine is different. For example in Godot it's called Delta. In unity it's called Delta time I believe. However all game engines again provide you with some way of being frame rate independent. Now the last thing I want to point out is that Godot does give you delta time in the form of a float value and there are issues with floating point and there are limitations with floating point and floating points just means a float value. Now when dealing with float values our position is not precise. So it does do rounding and in some cases it cuts off after a certain position point.

Now doing complex math calculations when dealing with flow will get you near the correct answer but not the exact answer. On top of that different hardware is deal with floating point calculations differently. So although we call this deterministic. So although our float point calculations are deterministic on a single computer they are not deterministic when dealing with multiple computers multiple computers will give different results. But those computers will give the same result every time. Now this is Godot specific but in this case when we have the literal integer value one which in Godot will round to a float point and we add it to a very precise number in this case I believe it's to tend to the negative seven.

As you can see here Godot will just give you back the value one. Now in most cases this is not a big deal. As for example when we want to move our character 100 pixels per second or float value will in a sense get us close to 100 but not the perfect 100. And that's just something to keep in mind. It should not be a deterrent from using delta time as a matter of fact all flow values have this issue it's not just a Godot problem it's basically a programming problem. However in your programming journey as a beginner this should not deteriorate. But it is something to keep in mind because sometimes you'll use more complicated math than your maybe perhaps pull your calculator and you'll see that the value in your calculator is very different than the value given to you by the Godot console. And that doesn't mean you're doing anything wrong in your Godot calculations. It's just a limitation of float values. Well that's all I have for you in this episode. Thank you so much for joining me. If you have any questions or comments please feel free to leave them in the comments section down below. I look forward to seeing you in the next steps. Have an amazing day