Search Unity

Do you use device states, buffers and events?

Discussion in 'Input System' started by dmytro_at_unity, Sep 27, 2021.

  1. dmytro_at_unity

    dmytro_at_unity

    Unity Technologies

    Joined:
    Feb 12, 2021
    Posts:
    212
    Hey folks,

    I'm curious if anyone is using our low level API's related to device states, buffers and events to do something interesting, some of them are:
    - InputState
    - InputStateBlock
    - InputStateBuffers
    - InputStateHistory
    - InputEventTrace
    - IInputStateCallbackReceiver
    - IInputStateChangeMonitor
    - InputSystem.QueueEvent
    - InputSystem.QueueStateEvent
    - InputControl.ReadValueFromStateIntoBuffer
    - InputControl.WriteValueFromBufferIntoState
    - And many others.

    Would be interesting to know how you use them and what is the use case?
    Thanks a lot!
     
  2. Kleptine

    Kleptine

    Joined:
    Dec 23, 2013
    Posts:
    282
    Hey @dmytro_at_unity!

    I just wanted to chime in here!

    We definitely have had great success using low level access to the Input System package. In fact, our entire game is founded upon it. Our game is based on making looping clones of yourself, so we save the raw input buffers for every input device in the game, and replay them on loop as fake devices in the Input System.

    There may be as many as 25 clones in the game, with 3-5 input devices each!

    To be clear, we actually don't use these APIs themselves. Instead we:
    - Forked the package to expose pointer overrides for currentStatePtr, previousFrameStatePtr, etc in InputDevice
    - Create a new InputDevice from the recorded layout.
    - For each new frame, we swap the currentStatePtr to point to the next input buffer in the recording.
    - For reading input, we use the InputDevice methods (ie. ReadValue)

    This makes it quite fast, as these 'fake' input devices aren't actually mounted into the InputSystem.

    At various points in the project I've tried to convert this to using QueueEvent, so that it actually pumps these InputDevices through as normal input events (so we could use Actions, etc). Unfortunately, the APIs were quite challenging to use.

    I needed more information on the overall architecture.
    - QueueEvent takes an StateEvent, but constructing a new StateEvent from a raw input byte buffer was unclear.
    - Should I be using DeltaEvent instead of StateEvent?
    - There's not much info on certain terms: ie. what FourCC code am I supposed to be using for my input buffers?

    It kept segfaulting, which was tricky to debug because I don't have source access to the engine code.
    - This made the actual work very painstaking, and is the primary reason I set it aside.

    In the end we didn't actually need these fake devices in the InputSystem, because we don't use Actions. And there was an argument to be made that our 'pointer swapping' approach might be considerably faster! So we set this aside.

    Hope that's helpful -- this is all to say that I really appreciate having that kind of low level control! But if I were to take another stab at using it, I think I would need to open a forum or support thread to get some of the answers I needed.