Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Input.Get vs new input system?

Discussion in 'Input System' started by newage_lightbulb, Oct 7, 2020.

  1. newage_lightbulb

    newage_lightbulb

    Joined:
    Oct 6, 2020
    Posts:
    3
    Hello, I'm wondering if there's any real reason for a project that uses the old Input.Get* system to change to the new input system?

    Are there significant performance gains? Is the old system slated for deprecation?

    Because many of us didn't write our game logic to be event-driven it seems to me most people who switch to the new input system just write a master Input singleton or object that receives events from various devices and then provides an interface very similar to Input.Get to read the data. In that respect I'm largely thinking "if it ain't broke don't fix it". But maybe I'm missing something about the new system?
     
    linojon likes this.
  2. newage_lightbulb

    newage_lightbulb

    Joined:
    Oct 6, 2020
    Posts:
    3
    For anyone interested, I answered my own question. The new input system is much, much more powerful ... but the confusing documentation can make it quite challenging to initially work with.
    So I recommend upgrading, particularly if you plan to provide a remap/multibind interface to your users. But just keep in mind that it will be a challenge and you'll spend a lot of time trying things and Googling.
     
  3. benthroop

    benthroop

    Joined:
    Jan 5, 2007
    Posts:
    262
    Hey so what did you end up doing? I agree that polling input is appropriate much of the time, especially for analog sticks.
     
  4. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    Some random comments RE transitioning.

    We're gradually working on making the step more straightforward. Agree that the current docs aren't really addressing this rather common need adequately.

    We're also still in the process of adding some APIs where something was very straightforward to do in UnityEngine.Input but isn't nearly as straightforward with UnityEngine.InputSystem. The upcoming 1.1-preview.2, for example, finally adds IsPressed(), WasPressedThisFrame(), and WasReleasedThisFrame() to the action API (equivalent to GetButton(), GetButtonDown(), and GetButtonUp()).

    Another effort that's currently ongoing is to have a transparent reimplementation of
    UnityEngine.Input
    on top of the input system. It simply switches the underlying DLL so that the existing APIs can be used without having to modify any code.
     
    ctrble, TJHeuvel-net, SamJ and 7 others like this.
  5. dannyalgorithmic

    dannyalgorithmic

    Joined:
    Jul 22, 2018
    Posts:
    100
    Everyone liked this ^
     
  6. SomeGuy22

    SomeGuy22

    Joined:
    Jun 3, 2011
    Posts:
    722
    Rene, will these polling options only reset in sync with the Update() step? Or do they run on some internal clock? I'm not sure how the old system did it, I thought I read somewhere that it will account for FixedUpdate() too but researching now that seems to be incorrect.

    For example, if an Action is pressed "this frame", but then is reset after a single Update(), it would mean you couldn't reliably check it from FixedUpdate() because the next fixed step could come after the reset occurred. Also worth noting you couldn't check it from a custom "thread" i.e. a looping coroutine in order to save on resources. Obviously devs can write their own system to handle this but I'm curious about the implementation of these checks and if the "reset time" can be altered.

    A separate concern (let's assume it resets on Update) is: now what happens if you press and release and then press and release again all on the same frame? Is the Action "Pressed This Frame" for 2 frames in a row to account for the double press? Or is it "Pressed This Frame" for 1 frame and then "Released This Frame" for the other? In practical situations I would assume the second scenario makes sense for most purposes, but I'm still interested in the logic here.
     
  7. Rene-Damm

    Rene-Damm

    Joined:
    Sep 15, 2012
    Posts:
    1,779
    "Frame" here corresponds to the update slice configured in the input settings. So Update() by default. But can be switched to FixedUpdate() or manual updates.

    ATM this is an either/or. With "Update Mode" set to fixed updates, it'd track each FixedUpdate().

    Both WasPressedThisFrame() and WasReleasedThisFrame() will be true for the frame. Basically, the former says "was the button pressed N>=1 times during the frame?" whereas the latter says "was the button released N>=1 times during the frame?" and either is independent of the other. Where the distinction matters, the callback API will have to be used.

    ATM there's no redistributing/deferral of events going on there. I.e. the detection is quite literal.

    If both presses and releases matter to a piece of game logic, with some care this can be dealt with even if a press and release happens in the same frame (which in practice, will be *very* rare and pretty much only occur in automated test situations or with very low frame rates ////EDIT: or, well, in device switching situations where control of an action moves from one device to another).

    Code (CSharp):
    1. // Do.
    2. if (fire.WasPressedThisFrame())
    3.     StartFiring();
    4. if (fire.WasReleasedThisFrame())
    5.     StopFiring();
    6.  
    7. // Don't.
    8. if (fire.WasPressedThisFrame())
    9.     StartFiring();
    10. else if (fire.WasReleasedThisFrame())
    11.     StopFiring();
     
    Last edited: Oct 12, 2020
    SomeGuy22 likes this.
  8. SomeGuy22

    SomeGuy22

    Joined:
    Jun 3, 2011
    Posts:
    722
    Got it, that makes perfect sense. Thank you for clearing that up, can't wait to try it out!

    One last curiosity I have--even though as you said this situation is rare, what would be the result of "IsPressed()" if an action was pressed and released within the same frame? As you've said the detection is literal, so technically wouldn't this action not be pressed? Practically for game mechanic purposes I might expect it to return true until the next frame occurs but I guess that's open to interpretation and doesn't matter too much--if you need recurring behavior you should be able to let a 1 frame press slide.

    Also, don't we already have InputAction.phase, InputAction.triggered, and InputAction.ReadValue which provide similar information? I'm reading the docs again and it seems that ReadValue works off of phase, so it seems like both do not accumulate as I just mentioned? But triggered appears to accumulate over the Frame, i.e. it will remain true even if a release occurred. Is there any advantage or change in behavior to using IsPressed() rather than any of these other options?