Information below are not from my head - I have collected and copypasted them from several sources. The reason I put it on a single place was that I simply need to understand
FixedUpdate() method on my own, which I am doing by coding, testing and blogging about it at the same time.
Unity documentation says that the
FixedUpdate() method is called at regular interval, while
Update() function is called as many times as possible, so we say
it is called every frame, see
there. Having a fixed interval is pretty useful, because of physics: E.g. if we add a force every
Update() instead of
FixedUpdate(), the game would run differently depending on the frame-rate.
Now, if you have call like the one below:
void FixedUpdate ()
{
Debug.Log("FixedUpdate time :" + Time.deltaTime);
}
You will notice in the console window that the
deltaTime property, which returns in seconds time it took to complete the last frame, will return always the same fixed time. This is little misleading - Unity detects if the current call to
Time.deltaTime is originated during
FixedUpdate() call and returns
Time.fixedDeltaTime value instead.
As mentioned
here, calling something in regular intervals is not possible because of different devices performance. The solutions is that if
FixedUpdate() hasn't been getting called often enough to average out to the correct interval between calls, it gets called multiple times (or isn't called if the frme rate is too high).
It is mentioned aslo in the Unity
documentation: "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."
In pseudo code I think the game loop is so
mething like the one below. The physicsTime is a virtual time, which si increased by adding
physicsStep fixed value every time all
FixedUpdate() method on all game objects are called. If we e.g. set the
physicsStep to 0.02 and in the while loop is the difference between virtual time and real time (
Time.time - physicsTime) is 0.07, because of e.g. low hardware performance during the scene rendering, the
FixedUpdate() will be called 5 times in a row before next
Update() call will be executed:
while (1)
{
while ( physicsTime < Time.time )
{
CallOnAllGameObjectsFixedUpdate();
physicsTime += physicsStep;
}
CallOnAllGameObjectsUpdate();
}
In other words, first the appropriate number of physics steps are executed in order to "catch up" with the real time (and each step,
FixedUpdate() is called on each object which implements it). Next, the graphics for the frame are rendered, followed by
Update() on each object which implements it.
So, it is not true that
FixedUpdate() is called in regular interval, but it is guaranteed that the same (almost) number of
FixedUpdate() calls will be executed every second.
See another nice
explanation:
Let's set the physics timescale is 0.02, which this gives us 50 physics updates per second. If our game were running nice and fast at 100fps, we'd have two frame renders for every physics step - and therefore two calls to our
Update() functions, for every call to our
FixedUpdate() functions. (Key: "F" for FixedUpdate and "U" for Update)
0 0.1
| |
.____.____.____.____.____.____.____.____.____.____.___
F F F F F F
U U U U U U U U U U U
If our game is running slower, say - at 30 frames per second (and therefore 30 calls to all
Update() functions per second), it would mean that we actually sometimes have more than one physics step between each frame render. In the case of 30 fps, the result would be that sometimes two physics steps are executed between frames, and sometimes one, which would look something like this, for the first 10th of a second:
0 0.1
| |
.____.____.____.____.____.____.____.____.____.____.___
F F F F F F
U U U U
So, in most normal circumstances, you'll always get the desired number of physics steps per frame, and interleaved with these will be the visual frame updates, at as fast a rate as possible.
