Hey @PolygonalSun,
Noticed some interesting behavior with the DeviceSourceManager
. see Playground:
https://playground.babylonjs.com/#S9CRXX#10
After a keypress is registered, we then initialize the keyboard’s device via:
Where the inputs are initialized to null. This is all well and good for gamepads, as they are manually polled and updated the next frame, but for event driven devices like a keyboard, the inputs remain null
until that specific key is pressed, as the example scene demonstrates.
Why do we do this? “null” doesn’t seem to make sense to me in respect to an input as I’d consider one to be either: Fully on(1), Fully off(0), or somewhere in between for an axis. We also throw
in the event that we try to retrieve input for a non-existent device, instead of returning any value, which is the only scenario a result of null
return value kind of makes sense to me, as in “this input is invalid”.
I propose a fix via that initializes our device inputs as 0 after registration to avoid this, and maybe get closer to our contemporaries:
https://docs.unity3d.com/ScriptReference/Input.GetAxis.html
https://docs.godotengine.org/en/stable/classes/class_input.html#class-input-method-get-joy-axis
I’m not sure if its a good idea to change the public API as well to make the values returned by DeviceInputSystem.pollInput()
and DeviceSource.getInput()
no longer nullable, but that may or may not be a breaking change