According to the Unity source code, there is a delay of one frame when using the OnScreenControl, is this still be the case in 2021?
If there is a better solution to this problem, please let me know.
// OnScreenControl.cs Line 194
////FIXME: this gives us a one-frame lag (use InputState.Change instead?)
m_InputEventPtr.internalTime = InputRuntime.s_Instance.currentTime;
control.WriteValueIntoEvent(value, m_InputEventPtr);
InputSystem.QueueEvent(m_InputEventPtr);
We are having issues with this, please respond
Hi there, by default there is still a one frame delay when using OnScreenControl. One thing you could do if you absolutely need to process the input in the same frame is to take control of the input system update by setting the Update Mode to Process Events Manually (Project Settings → Input System Package), and then have a MonoBehaviour that calls InputSystem.Update once in it’s Update method and again in LateUpdate, or at any other two points that make sense for your use case. The downside is you’ll be paying a performance cost for pumping the input system twice per frame, but that might be an ok trade-off for you.
I can try but I think this is cause of a bug, where OnScreenButton does not register OnPointerUp when it is exactly 1 frame after OnPointerDown (same frame is ok, other frames after also ok).
You can create empty project, setup new InputSystem, create a button in InputActions with keyboard binding, Put OnScreenButton on canvas, setup targetFrameRate to 1 (for easy debuging), and log InputActionPhase of the action.
Works ok in editor but not in build.
Also works if instead of a button you create a Value-Vector2 with stick binding
Does not work for Value-Analog with keyboard binding
Hi @Lejv , sounds like a different issue than the OP. We’d definitely appreciate if you could create a bug report for this one (Unity Editor → Help → Report a bug).