koobas.hobune.stream
Exact difference between fixedDeltaTime and deltaTime?
Hello.
P.S. :Whatever I say is regarding mobile platform but may apply to other platforms as well.
I have read that to make a game frame rate independent, one must multiply all calculations with Time.deltaTime which is basically the time required to complete the last frame. However, when the system slows down or when relatively heavy background applications pop-up,(which I have experienced first hand) the game also starts lagging. However when I multiply the same calculations with Time.fixedDeltaTime, the game runs exactly at a specific rate or "speed" no matter how many background applications pop-up mid game play. So this would be the best way to do it right? Well actually, NO! When I run the same game on another system(phone), the speed or rate of the game is altered. Case in point, when I play the game on my SGS4 it runs faster than on another slightly lower end device.
THE QUESTION: THE LAG THAT I EXPERIENCE WITH Time.deltaTime, is that lag natural? Is it acceptable? I mean, a lot of games made by professional developers DO LAG!
Also,any reason why my game runs so jerky on the other device but runs so smooth on my SGS4? It's a relatively simple game, not very heavy.Neither GPU intensive,nor RAM intensive.
I don't know the reason your game lags but the use you are giving to Time.deltaTime and Time.fixedDeltaTime is possibly wrong.
Time.deltaTime is the time interval between current frame and the last one, which is the same than the time interval between two call to the Update() method. This means that Update() is going to be called a different number of times depending on the performance of your game.
On the other hand you have the method FixedUpdate() which works essentially as Update() but with the difference that it is going to be called a fixed amount of times per second. Naturally Time.fixedDeltaTime is the difference between two calls of FixedUpdate() and it always holds the same value.
As you see, it would make no sense using Time.fixedDeltaTime in the Update() method, if you do so you should move the logic that uses Time.fixedDeltaTime to the FixedUpdate() method. Same goes for Time.deltaTime, it is wrong (or at least very wierd) to use it in FixedUpdate().
Personally I use Update() for input recognition, since it is more likely to catch a key because it gets called more often. I use FixedUpdate() for everything else.
Could the reason possibly be because the game object that I'm talking about doesn't have a rigidbody or rigidbody2D? It moves with the help of code like :
"transform.position.x += someValue Time.deltaTime" OR "transform.position.x += someValue Time.fixedDeltaTime"
You would be recommended to multiply someValue by Time.deltaTime. Time.fixedDeltaTime would be suitable if you are in a FixedUpdate function (as opposed to just an Update), but even then Time.deltaTime will work fine, because that automatically returns the right value depending on whether you are in an Update or a FixedUpdate function. Of course, there's a limited amount they can do to prevent lag - if your virus scanner starts up and slows your game down to a few frames a second, it will be noticeable regardless of having used Time.deltaTime.
$$anonymous$$odifying Time.timeScale appears to modify Time.deltaTime and Time.fixedDeltaTime both away from the amount of time between the last two frames. If you set Time.timeScale = 0.5f, it will halve the values in both delta times. Can you explain what is happening?
What I was expected was there to be a value that gives the actual delta time in reality and another to give the delta time in the game (which would be halved), if you understand how I am thinking about this.
Please explain if you will.
Yes, the point of the timescale is to affect the perceived time. So at a timeScale of 0.5 everything should move half as slow as usual. This is done by scaling deltaTime by the timeScale. If every delta calculation uses Time.deltaTime, everything will advance slower when the timescale is lowered.
If you check the documentation you will notice that there is also an unscaledDeltaTime. However you almost never need this. Where it might come in handy is when you want to have some specific things to still run when you set the timescale to 0 to pause the game.
If you have any further questions, please ask a seperate question. Comments are not meant to ask questions or to answer them.
unscaledDeltaTime is good for fps calculations though. Thanks a lot for the breakdown. Note my "Answer" below too, as I learned a bit more about all of this in the meantime.
You should use Time.deltaTime whether you're in FixedUpdate or Update. It will return the actual amount of time that has elapsed between calls of the method you use it in (it automatically detects whether its in FixedUpdate or Update and returns the correct value).
Time.fixedDeltaTime is the target update rate for FixedUpdates. The actual time elapsed between FixedUpdate calls may not match it.
See https://docs.unity3d.com/ScriptReference/Time-fixedDeltaTime.html (The docs recommend you use Time.deltaTime instead)
Time.fixedDeltaTime is a value to set, not read:
Time.deltaTime is the amount of time between frames -- the inverse of which would be your frames per second. It is a value you READ. It cannot be set.
Time.fixedDeltaTime relates to physics, and is the same interval. However, it is a value you SET. You can also read it. One use is to modify it when you do slow down, so your physics works: "Note that the fixedDeltaTime interval is with respect to the in-game time affected by timeScale."
