Open markvideon opened 4 months ago
After some experimentation, I have some comments about this.
Windows.Gaming.Input manages input devices and events. It seems like we would need to look at other Windows APIs for other features.
The two 'core' classes representing devices of concern are:
A particular device may be recognised as a RawGameController and it may also be recognised as a Gamepad. For instance, I found the Switch Pro Controller was recognised as a Gamepad and a RawGameController when connected via Bluetooth, and only as a RawGameController when connected via USB.
RawGameController has a number of properties such as device name and hardware device ID that can also vary depending on the connection type. E.g. I observed RawGameController.DisplayName with a value of "HID-compliant game controller" for most controller and connection type combinations, but notably when an Xbox Series S/X controller was connected via USB it was reported as "Xbox One Game Controller".
Win10 has been unable to operate in the past two weeks, is this the reason?
Win10 has been unable to operate in the past two weeks, is this the reason?
This GitHub issue describes rewriting the Windows plugin to use a new API, it is not directly related to any problems people may be facing with the current implementation of gamepads_windows.
This sounds promising:
GameInput is a functional superset of all legacy input APIs—XInput, DirectInput, Raw Input, Human Interface Device (HID), and WinRT APIs—in addition to adding new features of its own.
However it is distributed via NuGet, which does not play well with CMake according to this issue.
Win10 has been unable to operate in the past two weeks, is this the reason?
This GitHub issue describes rewriting the Windows plugin to use a new API, it is not directly related to any problems people may be facing with the current implementation of gamepads_windows.
Is there a specific plan for this? Where can I see the answer? Please provide me with a link, thank you
Any progress on this? I added support for web on this package but I don't like the old windows implementation so I had to remove/ reimplement the windows package. How xinput_gamepad is implemented is perfect for me.
Still a work in progress. A number of Windows specific issues seem to be popping up (i.e. #34 and #42), I will try to find more time to spend on this.
gamepads_windows
currently appears to use the Joysticks API. As per its documentation, it has now been superseded by Windows.Gaming.Input, which provides some functionality comparable to the Game Controller Library provided by Apple.There is a larger project to make Windows APIs accessible as Dart packages via FFI. One such package is
windows_gaming
. https://github.com/halildurmus/dartwinrt/tree/main/packages/windows_gamingIt may be worth exploring making use of this package.
EDIT: I've come to understand that migrating to this API may affect compatibility with controllers that don't support XInput.