Time.Deltatime vs fixedUpate

if deltatime sees the difference between frames and adjusts why cant you use that instead of fixedupdate()

 

Time.deltaTime - The time in seconds it took to complete the last frame (Read Only).
where as
FixedUpdate() - is often called more frequently than Update. It can be called multiple times per frame, if the frame rate is low and it may not be called between frames at all if the frame rate is high.

 

want to ask sth at this post too.

if my computer is very lag, and i use fixedupdate to do my "transform.translate"
Will the game also be lag too?

 

Basically - anything that occurs in fixed update is meant to maintain the same frequency regardless of framerate, so if your moving something an exact amount every fixed update, it should maintain a steady speed even if the games slowing down. However there can be problems still if the game is going so slow it is about to freeze, but in general it is my understanding that you can expect FixedUpdate to run at a "fixed" speed.

Hope that makes sense!

 

FixedUpdate == Physics

Update == Everything else

 

Be aware that Time.deltaTime will return different results, depending on whether it is called from Update() or FixedUpdate(). It auto-detects which time diff to return.

Edit for clarity: if you call Time.deltaTime from within FixedUpdate(), it returns the same value as Time.fixedDeltaTime.

 

So since FixedUpdate is called more frequently(depending on framerates) its best for physics and will make things alot smoother depending on framerates. One question though, will using deltatime in Update be the equivalent to FixedUpdate?

 

precisel, you don't need to use Time.deltaTime in FixedUpdate() because its called on a reliable timer, independent of the frame rate.

 

Ok thanks

 

And update IS framerate dependent, and if the game slows down, Update is called less frequently. So the answer is yes and no - using deltaTime in Update () sort of allows you to do similar stuff by multiplying whatever values by deltaTime to make up for the difference in speed - but if that stuff needs reliably updated (at a specific frequency) then it is better to use FixedUpdate because it won't slow down (under normal circumstances) like Update will.

 

Wait up i am confused soo you are telling me Update will slow down if your framerates drop and FixedUpdate does not slow down regardless of the fact that your game is running slow? and i do not get how deltatime makes up for the difference in speed when used in Update please explain more(do not use the word frequency or frequently) i don't like it.

 

Well ok - FixedUpdate is supposed to run at a specific interval no matter what, while Update is called more when framerate is high (let's say 10 or 20 times a second) and it is called less when framerate is low (let's say only 2 or 5 times a second).

So what that means is in Update if you say "myInteger = myInteger + 1;" and also put the same line in FixedUpdate - they will be different numbers (which will grow faster depends on framerate and what deltaTime interval has been set in the time settings).

So basically - things that need updated on a regularly scheduled time (every 50 milliseconds, maybe every 100 milliseconds) should be calculated in FixedUpdate, and things which don't need a regularly scheduled update (maybe certain game logic like checking what level your player is on) can do fine in regular Update.

Ok that is officially the limit of my explanation power on this subject haha, if you still need more info - just google up on deltaTime in general.

 

Ok i get it now but i do not get the idea of using time.deltaTime in Update() if you are only going to do game logic and not any physics. I believe each frame that runs in FixedUpdate() take 0.02 secs to complete each time.

Code (CSharp):

1.  
2. FixedUpdate()
3. {
4.   Debug.Log("Time is: " + Time.deltaTime);
5. }

 

Right - and you can change the frequency of that in the time settings in unity.

 

Just be aware FixedUpdate runs with a fixed simulation time step. This has no relationship to real time. Its an important distinction to be aware of if you are going to get down to the details.

 

You need both time differences. The advantage of using Time.deltaTime in Update() is that you can update things every frame that is drawn. This is essential for smooth animation and input. Using Time.deltaTime in FixedUpdate() (same as using Time.fixedDeltaTime within this method) will allow you to make predictable updates to physics objects such as projectiles. Rendering and physics are best separated. Physics depends on reliable updates, whereas rendering can be a *lot* faster and more frequent. This will make a smoother experience. However Update() can be fast or slow and run many more times... or many fewer times than FixedUpdate(). That is why you need access to both time deltas and use them appropriately for your game. See this page for more info.

 

Ahh see guy guys are getting over my head now lol - I might learn a thing or two if I'm not careful

 

I read the documentation
"If the frame time is 10 milliseconds then the object will step forward by distancePerFrame one hundred times per second. But if the frame time increases to 25 milliseconds (due to CPU load, say) then it will only step forward forty times a second and therefore cover less distance. The solution is to scale the size of the movement by the frame time which you can read from the Time.deltaTime property"

I just dont get it when he says "the solution is to scale the size of the movement by the frame time". Sorry but these things tend to trouble me when i do not know why i am using certain code at random places.

 

So... you're simulating a 2D aircraft moving in a straight line at constant speed across the screen. You have to draw this aircraft at certain discrete moments (frame render) In between these moments, the aircraft has moved some distance. Now let's say that the time interval between frames 1 and 2 was 10 milliseconds. The aircraft has moved according to the velocity you gave it. If the time between frames 2 and 3 is 25 milliseconds because the CPU got caught up processing a load of AI or garbage collecting, then you would expect the aircraft to move further during that interval than the previous interval. So in 25 milliseconds, the aircraft moves further than it does in 10 milliseconds. What you are doing is taking the time interval between frames and using that varying factor to scale the movements to compensate.

velocity = distance / time

Or, to work out how far your aircraft has moved for the current time interval...

distance = velocity * time

"time" in this equation is the time since you last rendered your aircraft. Which is Time.deltaTime. If you assume that Time.deltaTime is constant, when in actual fact the simulation is running at variable frequency, the aircraft won't be in the correct place when you go to update it.

Hope that explains it

 

So you are multiplying the distance value by the time it took your plane to render in the previous frame how does that help? i understand how velocity or speed =distance/time distance= speed or velocity * time. Also i thought update is called once per frame so if one frame takes 25 milliseconds long how is the distance of the plane greater than the 10 milliseconds when it should be equal or do you mean after time.deltaTime has been utilized in code then it will move farther? if so are you telling me that time.deltaTime is using the time since it last rendered to determine the distance for example:

if a car goes a distance 5m per frame and the first frame took 10millisecs
then the next frame takes 20millisecs so if you use time.deltaTime the car will go 10m
on the second frame meaning the car is now 15m in distance. Because the second frame
was longer you compensate for the time by doubling the amount of work being done on the object.

 

You're correct. In the equation "distance = velocity * time", the time value is Time.deltaTime. Hopefully you recognise that in Update (as opposed to FixedUpdate) you can expect Time.deltaTime to be different every frame, so you need to feed this value into your movement calculation for each frame/update you process.

Now if you consider the Rendering/Physics separation mentioned earlier, we have just been talking about the graphical rendering. The physics update can be relied upon for constant time intervals, but you can't just use this for all your time deltas in your game because input and your graphical output will be updated "as fast as the computer can go" to give you smooth results. When the your Update method is called, it will use whatever state the physics has produced at that moment in time. So they can run entirely separately. Other game systems give them unique threads to run in. Unity doesn't quite do multi-threading in the traditional sense but that doesn't matter here. All that matters is that you are sampling your game world at discrete time intervals and then telling it how the world has changed in the time taken since the previous frame.

If you need more information on this, I would suggest googling some basic game-dev or simulation tutorials or look on YouTube since you probably need a few visuals to help

 

I do not get what you are saying but i will take your advice on googling it.

 

FixedUpdate() is called 50 times per second by default. That is less frequent than your standard framerate

 

Please don't necro posts from five years ago, especially, if you can't give proper advice.

- in 2015 we more likely were targeting 30FPS than 60FPS
- for a lot of mobiles we were definitely targeting (still do today) 30FPS
- the post says "often", and this is because he was talking about FPS dips. When your FPS is dipping below 50 and you have the default 50 times per second default setting there will be frames when the FixedUpdate runs more than once in a frame, the lower your framerate the often will be double FixedUpdate per Update. And when you drop to 25 FPS, you will have two FixedUpdate calls per Update
- also he mentioned the case when your framerate is higher than the 50FPS, then you will have frames where there is no FixedUpdate calls at all