koobas.hobune.stream
Why Do Inputs Have to Been in Update (Rather than FixedUpdate)?
I have simple button press action that works fine in Update, but does not work properly if it is in FixedUpdate. That's fine, but I'm just curious on why that is and hoping someone can enlighten me. Thanks.
Well input can be read in FixedUpdate, just not input events like GetKeyDown, GetKeyUp, GetButtonDown, GetMouseButtonDown, .... That's because those events are only true for one frame. By frame we talk about an actual visual frame. Input is always read / updated at the beginning of a frame. During a frame the input information doesn't change.
The FixedUpdate mechanism (physics processing) is implemented just before Update is called each frame. However it's possible that FixedUpdate is not called each frame when your visual framerate is high. Usually the fixed framerate is set to 50 fps by default. That means if you actually have 100 visual FPS FixedUpdate only runs every second Frame in order to get the 50 calls per second. If the framerate is 60 fps FixedUpdate will be called almost every frame but every 6th update it will not call FixedUpdate. If a down or up event happens during such a frame, you will not detect it in FixedUpdate.
I've made a simple simulation years ago to visualize how FixedUpdate works. This originally was a WebPlayer. Recently i've created a webGL build of it. Set the "FPS" slider to your actual framerate. The magenta boxes represent a single FixedUpdate call. Note the yellow vertical line which indicates the current Time.fixedTime while the thick red line represents Time.time Note you can slow down the simulation speed and zoom in / out to get a better view of what is happening. (Note: You shouldn't zoom out completely. WebGL could run out of memory. This wasn't an issue in the WebPlayer but WebGL is very limited)
I've created a CustomFixedUpdate class that can be used to implement as many fixedupdate callbacks at any rate you want. It works exactly like Unity's fixedupdate. Just have a look at the implementation to better understand what Unity actually does. In essence beside the normal game time Unity keeps a seperate timeer (fixedTime) which is incremented each time FixedUpdate is called. Though unlike the normal time where the increment each frame can vary, the fixedTime is always increase by the set fixedDeltaTime value. Unity calls FixedUpdate as long as the fixedTime lags behind the current game time. If the actual framerate is high it's possible that a single fixedTime step jumps over a whole deltaTime period. So the next frame the fixedTime is still ahead of the current time so no FixedUpdate will be called.
Note that if the visual frame rate is quite low (lower than the fixed frame rate) Unity will have to call FixedUpdate several times per frame in order to catch up the game time. This means that input events (up oder down) are recognised twice or even more often since the input only changes between visual frames.
Your WebGL build appears to be missing. Would you kindly fix and update your link?
FixedUpdate is fixed to a set time scale or ticks. If a frame takes 10 seconds (hypothetically) it will call FixedUpdate hundreds of times to catch up for all the missed ticks. There is no way to pick up Input calls on those ticks reliably.
Update is called based on your frame rate along with every other system besides anything using continuous physics. FixedUpdate is almost never needed, or rather should not be used in normal cases. If you want to be micromanaging bullet physics or adding constant force to RigidBodies then yes it has it's uses, but for most players it's not something you should be using.
Input goes in Update along with 99% of everything else.
I am not 100% sure but I don't think that FixedUpdate loops like Update does.
