koobas.hobune.stream
Are Update() and FixedUpdate() called in different threads?
http://unity3d.com/support/documentation/Manual/Update%20Order.html
suggests that FixedUpdate() and Update() are called independently, i.e. if the Update() Callback gets stuck for a second, it does not say FixedUpdate() would wait at all. Thus, if I call the same method from Update() and from FixedUpdate(), would I need to synchronize (mutually exclude threads calling a critical code section)?
No, Unity scripts are all run in the same thread. If Update gets stuck for a second, the entire game will freeze for a second.
No, the whole scripting runs in one thread. The whole scripting API therefore isn't thread-safe. You can use your own thread but you can't access the API (unity checks the threadID).
FixedUpdate is not run in "fix" intervals. It's a "fixed" Update. It just runs before Update (at least i guess, maybe right after update). It's deltaTime value has a fix value but it doesn't match the realtime. If you have only 30 fps and have a fixed rate of 60, FixedUpdate will be called twice before the next update. If you have 120 fps FixedUpdate is only called every second frame. The acumulated calls will reflect a 60fps rate but it's just "corrected" ;)
http://www.unifycommunity.com/wiki/index.php?title=Event_Execution_Order
Only one thread, okay.
But... "deltaTime has a fix value but it doesn't match the realtime" - can you please elaborate on that?
I mean, if I trap Update() for a second then return, and I have FixedUpdate at 60Hz, does that mean I have 60 "FixedUpdate" calls before "Update" is called again?
And do I have to use less computing time than 1sec/60 for every call into FixedUpdate? What happens if I slip and I need 1.2sec/60 for a few calls into FixedUpdate during that said second?
@ehaase: Theoretically, yes you could have 60 FixedUpdate calls in a row, but realistically the maximum allowed timestep value in the time settings prevents that. (The side effect is that physics are slowed down if it kicks in.) If you are using so much CPU time in FixedUpdate that you're preventing it from running at the specified interval, basically your code is broken and you need to fix that by massively reducing the amount of code in FixedUpdate or substantially reducing the number of times FixedUpdate runs per second. But if it was just a brief hiccup, FixedUpdate will always attempt to run at the specified interval by running more frames after that, again with the maximum allowed timestep functioning as a sort of "brake" if necessary.
