I was thinking about games on low end machines or phones where the CPU would be limited. If I were to move all of my game logic into FixedUpdate() can I assume that it will always be called with the same time delta? Or would it still be worth adding code to make it take the actual time delta into account?

  • 1
    \$\begingroup\$ It's worth noting that FixedUpdate is "fixed" with regard to the simulation time represented by each step, not with regard to realtime. There's a common misconception that FixedUpdate is called on a regular timer, when in fact it runs at the beginning of each frame and loops back-to-back some number of times to catch up to the current game time. So, reliability with regard to simulation consistency, and reliability with regard to realtime event sequence are distinct questions. If I understand correctly, you're asking about the former - how much game time is simulated in each fixed step, yes? \$\endgroup\$
    – DMGregory
    Nov 11 '16 at 21:00

I've done some tests simulating low framerate conditions, and empirically confirmed that the deltaTime value for each FixedUpdate step does indeed stay consistent.

For example, using the default Fixed TimeStep of 0.02 (50 Hz) and Maximum Allowed Timestep of 0.3333333 (as set in Edit -> Project Settings -> Time)...

  • At 60 fps we get 0-1 physics & FixedUpdate steps per frame
  • At 30 fps we get 1-2 physics & FixedUpdate steps per frame
  • At 15 fps we get 3-4 physics & FixedUpdate steps per frame
  • At 3 fps we get 16-17 physics & FixedUpdate steps per frame, and we hit the max allowed timestep
  • For any lower framerate, Unity clamps the real time elapsed to 0.33333, so we continue to get just 17 physics & FixedUpdate steps per frame

Throughout the whole spectrum, every call to FixedUpdate gets the same deltaTime value of 0.02. The variability in timing is handled solely by running more or fewer iterations, not by scaling the deltaTime value - exactly as we should expect for a "fixed" timestep.

As shown above, when the framerate is extremely low, Unity will limit the amount of time by which it advances the game simulation, capping at 17 FixedUpdate iterations with the default settings.

So, if you want to know that the game time represented by each FixedUpdate iteration remains the same, the answer is yes (as long as you don't assign a new value to Time.fixedDeltaTime directly)

If you want to know whether the realtime interval represented by each FixedUpdate iteration remains the same, the answer is no - at extremely low framerates, Unity will cap the number of FixedUpdate steps, allowing game time to run slower than realtime. Also, as noted in a comment above, all the physics steps and FixedUpdates for a given frame occur back-to-back at the beginning of the frame's execution, not evenly distributed in realtime like a metronome.

In doing this test, I learned some interesting things about how Unity handles Time.timeScale:

  • Slowing/speeding game time with timeScale does not modify the deltaTime of each call to FixedUpdate - you'll just get fewer or more steps in a given frame, again as we should expect from a fixed timestep.

    If you want to increase physics time resolution when running in slowmo, modify Time.fixedDeltaTime when going in & out of the time warp.

  • The enforcement of Maximum Allowed Timestep occurs before multiplying by timeScale. So if I use Time.timeScale = 0.5f to slow the game by half, the maximum deltaTime I'll see in Update will be 0.16666666 instead of 0.33333333

  • \$\begingroup\$ Oh wow. I thought that the update was simply called after the physics step but this appears to show that it is much more involved than that! Thanks for the testing. How did you slow down the frame rate in the tests? just some arbitrary calculation I assume (while(not X amount of time has passed) or something like that)? \$\endgroup\$ Nov 12 '16 at 1:22
  • \$\begingroup\$ I used System.Threading.Thread.Sleep in an Update method to increase the time the main thread takes to complete each frame. :) \$\endgroup\$
    – DMGregory
    Nov 12 '16 at 1:24

So a few years later I stumble upon this article johnaustin.io where someone has an answer to something very similar to what I was wondering about.

Is FixedUpdate always called every 0.02 seconds?

No, FixedUpdate will run once for every 0.02 game-time seconds, but precisely when in real time this happens is unspecified and can vary drastically. See above: “A Heavy Load in FixedUpdate”.

How does the Unity timestep respond to low framerates?

Depending on the source of the slowness, it will do different things. For slow >FixedUpdates, it slows down the overall game-time (the game will run for 0.5 seconds in the span of one real time second). In some cases, the rendering rate can be drastically cut, even if the problem is your FixedUpdate speed.

For slow Updates, FixedUpdates get crunched together during the “catch up” phase between the longer Updates. Otherwise, generally the the Update dynamic timestep just gets longer.

It's a really good read and worth checking out the article to get more information about the fixed update cycle.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.