We know there's a "rule" that Input
functions shouldn't be used inside the FixedUpdate()
; Input.GetKeyDown()
may not work if we do so, but is it really wrong to use Input.GetKey()
?
Let's say we want to fire something when pressing and holding a key at some rate that is not dependent on hardware performance. I don't want to create a logic to control this using delta time or writing key detection code in Update
and firing code in FixedUpdate
.
Doesn't make sense to just do everything inside FixedUpdate
? What can happen - we may lose some key pressed events, the ones that we didn't want anyway, to keep our desired rate.
But what if one single key event happens, can we lose it? Is there a reset after Update
, so we won't see it on FixedUpdate
?
Tracking input in FixedUpdate absolutely can (and does) lead to input loss. With things like GetKey or GetAxis it may not be terribly important, but you'll absolutely lose KeyDown/KeyUp events. It's best to poll the input in Update and respond to it in FixedUpdate.
FixedUpdate should be used instead of Update when dealing with Rigidbody. For example when adding a force to a rigidbody, you have to apply the force every fixed frame inside FixedUpdate instead of every frame inside Update. In order to get the elapsed time since last call to Update, use Time.
FixedUpdate executes 50 times per second. (The game code runs around 200 fps on a test machine.)
FixedUpdate() Called every physics step. FixedUpdate() intervals are consistent, ie uniformly spaced. Used for regular updates such as adjusting physic (eg. RigidBody) objects.
From the GetKeyDown
docs:
You need to call this function from the Update function, since the state gets reset each frame
So yes, the Input state is reset each frame meaning hardware will have an effect depending on how frequently Update
fires between FixedUpdate
.
There really isn't an easy way to avoid creating a copy of the Input that is used by FixedUpdate, though I would suggest reevaluating your logic to move things in to Update
.
Update:
Regarding Rutter's comment below. I just noticed the OP was asking about GetKey()
, what I wrote about GetKeyDown()
remains true for GetKey()
though the documentation doesn't explicitly say so.
This can be verified by going in to the Time Manager and changing the FixedUpdate rate to some long interval like 1 second. Then do something like:
void FixedUpdate() {
if(Input.GetKey(KeyCode.D)){
Debug.Log("D-Key Down");
} else {
Debug.Log("No key down");
}
}
If you press and release 'D' between the 1 second fixed frames you will only see "No Key Down".
In my experience, Update occurs at frame-time, unlike Fixed Update which can occur multiple times per-frame. In addition, The physics of objects are actually updated before FixedUpdate() is called, which means there could be a delay based on the complexity of the scene.
I believe that Input is actually broadcasted per-frame, so when the FixedUpdate() is behind and needs to catch up by firing multiple times, the Input check will fail.
Additional Resources:
http://answers.unity3d.com/questions/10993/whats-the-difference-between-update-and-fixedupdat.html
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With