koobas.hobune.stream
FixedUpdate performance doubts
A very helpful answer from user Duck (http://answers.unity3d.com/questions/10993/whats-the-difference-between-update-and-fixedupdat.html) finally made it crystal clear for me the difference between Update() and FixedUpdate(), however one doubt still came to mind: what happens if the code inside my FixedUpdate() takes longer than the actual Time.fixedDeltaTime? How can Unity guarantee that the FixedUpdate() will execute exactly after 0.02 seconds if it takes 0.05 seconds just to run? Does it stop the process and continue on the next step? Or does the Time.fixedDeltaTime lose credibility?
I also read (http://answers.unity3d.com/questions/31843/multiple-scripts-with-fixedupdate.html) that the less FixedUpdate() calls, the better. I curious to know how prejudicial to my performance this practice actually is (or is it even valid?). I current have more FixedUpdate() than the actual Update() calls since my project is supposed to envolve synchronous multiplayer, and time controlled steps are an excelente way of guaranteeing that every client will be experiencing the same simulation. But if the exceeded use of FixedUpdate() is in fact a deal breaker, I would like to know so I can change my strategy as soon as possible.
Any help is welcome, and thanks in advance!
According to the explanation given in the Time Manager, the physics cycle runs at a "theoretically" fixed rate: before drawing each frame, Unity runs physics cycles and adds the fixed time to some internal clock variable until it reaches the actual time. If the last frame was rendered 60ms ago, for instance, 3 physics cycles will run one after another before the new frame goes to the screen. This may seem odd, but from the physics point of view it's ok, since physics uses its internal clock to calculate things, and it always walk Fixed Timestep seconds from one cycle to another (Einstein would love this relative clock!).
The Time Manager defines a Maximum Allowed Timestep that limits the physics cycles between frames. Its default value is 100mS, thus with the default 20mS Fixed Timestep you can have at most 5 physics cycles between frames. If your FixedUpdates are too heavy and take more than the specified Fixed Timestep, the physics will slow down, what will make the rigidbodies move slower than they should.
It will "lose credibility" if it takes too long - this is one of the downsides to using fixed timesteps. It doesn't scale at all to faster or slower computers. Generally as you get to the borderline it will start skipping draw calls so it has enough time to keep the simulation running at 50 updates per second even if it only displays it at 20. I don't know if unity ensures a minimum framerate and slows down the simulation too, but if it does it's pretty much irrelevant because the game was unplayable already. So yeah, get some tests going on an old computer or netbook so you can get that baseline.
As far as I know the issue with fixedupdate calls slowing things down is not at all unique to fixedupdate - there's nothing special about it vs Update(). It just matters more than Start() because start is only called once. As the other question points out, you would need a huge number of them for it to cause a real difference.
As for the whole synchronised multiplayer thing, your simulations can differ for various reasons even if you use fixed update, if you rely on the simulations playing out identically you can run into problems - unity handles some related things, but without knowing about your project I can't really tell if it's relevant.
A bit of false information here. FixedUpdate is the perfect Unity-main-thread-safe option for synchronous games that are actually synchronous. It's very flexible and as long as you set up the synchronous game how it should be set up, FixedUpdate will do wonders. Having every unit call its own FixedUpdate though... not such a good idea.
