Is it really wrong to use Input.GetKey() on FixedUpdate?

Question

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?

Answer 1

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".

Answer 2

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