6

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?

Roberto
  • 11,557
  • 16
  • 54
  • 68

2 Answers2

9

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

Jerdak
  • 3,997
  • 1
  • 24
  • 36
  • Absolutely true for `GetKeyDown()`, but in my experience `GetKey()` has been fine. Has that changed in the past few versions? – rutter Oct 08 '13 at 23:20
  • 3
    @Rutter Thank you for pointing out that I addressed the wrong function, see my update. I suspect that it's not something you'd notice with the default 0.02s fixed rate since `GetKey` is for continuous key presses. – Jerdak Oct 09 '13 at 00:22
  • Thank you, that's a good experiment to prove that GetKey() is reset each frame even the documentation doesn't explicitly say so. – Roberto Oct 10 '13 at 20:18
  • 1
    *"If you press and release 'D' between the 1 second fixed frames you will only see "No Key Down"* - The same is true if you read it in Update - if the key is pressed between frames, you won't catch it. Since the FPS of `Update()` is more variable than `FixedUpdate()`, this actually sounds like a reason to do it in `FixedUpdate()`... – BlueRaja - Danny Pflughoeft Feb 11 '14 at 02:21
  • 4
    @BlueRaja-DannyPflughoeft Doubtful. Forcing `Update` to sleep to simulate slow framerate shows keyboard input getting queued in background. Even if that wasn't the case, inputs is purged between frames and nothing guarantees `FixedUpdate` will run in any particular frame whereas `Update` is guaranteed once per frame. Meaning `FixedUpdate` shouldn't be used for input. – Jerdak Feb 11 '14 at 03:13
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

10001110101
  • 420
  • 4
  • 10
  • According to the flow chart http://docs.unity3d.com/uploads/Main/monobehaviour_flowchart.svg I think FixedUpdate() is called "before" the physics update? – Marson Mao Aug 03 '15 at 09:19