refactor!: Update to windows GameInput api
Breaking changes: Event keys does change. The new axis names are based on GameInputGamepadState. The new button names are based on GameInputGamepadButtons
dwXpos->leftThumbstickXdwYpos->leftThumbstickY- ...
button-0=>abutton-1=>b- ...
The range of analog axises has changed to [-1.0, 1.0].
Gampad id:s are different. It now uses GameInputDeviceInfo.deviceId.
Fixes:
- Crash when gamepad is disconnected
- Possible stale thread on disconnect https://github.com/flame-engine/gamepads/issues/79
- ~~Sleep(1) in input loop to reduce CPU load https://github.com/flame-engine/gamepads/issues/54~~ I used Sleep(8), then 4, but had issues with missing events so I am down to Sleep(1) in the PR, so might not be the best CPU reduction at the current state.
Non-goal For now as it appears that the different platforms use different names on buttons, axis etc. I have not tried to mimic a different platform in the gamepads library, but instead tries to keep it close to GameInput API, which does break against the current windows bindings.
Testing/feedback Feel free to test this out. For me it works, but love if people test it out, break it and report issues or suggest fixes. :)
Pop this in your pubspec.yaml to use this PR:
dependency_overrides:
gamepads_windows:
git:
url: https://github.com/lea108/gamepads.git
ref: windows-api-rework
path: packages/gamepads_windows
Not sure if this is a "fix" or "feat" PR. but the motivation is to fix issues and make it more stable.
Which is yet to find out if this is/becomes more stable overall than the current windows bindings.
The new API is just the means I ended up following as it has potential to remove the read thread entirely if GameInput RegisterReadingCallback() actually would work.
Since buttons now use named values like "a", "b", "menu" etc. I decided to drop the "button-" leading part of the key. I did take a look on other platforms and could not see that they use this prefix so decided to drop it for slightly shorter key values.
Not sure if this is a "fix" or "feat" PR. but the motivation is to fix issues and make it more stable.
Maybe a refactor:, but doesn't matter that much. :)
Great Work! I have been waiting for this for very long time. :)
Hi! I'm currently trying out your implementation and I'm struggling with
...\windows\flutter\ephemeral\.plugin_symlinks\gamepads_windows\windows\gamepad.h(11,10): error C1083: Datei (Include) kann nicht geöffnet werden: "GameInput.h": No such file or directory [...\build\windows\x64\plugins\gamepads_windows\gamepads_windows_plugin.vcxproj]
Is there anything special I need to install? I installed Microsoft GDK and fiddled a bit with the CMakeLists.txt of my project. I have limited experience with Windows dev
Hi! I'm currently trying out your implementation and I'm struggling with
...\windows\flutter\ephemeral\.plugin_symlinks\gamepads_windows\windows\gamepad.h(11,10): error C1083: Datei (Include) kann nicht geöffnet werden: "GameInput.h": No such file or directory [...\build\windows\x64\plugins\gamepads_windows\gamepads_windows_plugin.vcxproj]Is there anything special I need to install? I installed Microsoft GDK and fiddled a bit with the CMakeLists.txt of my project. I have limited experience with Windows dev
For me the file is located at this path:
C:\Program Files (x86)\Windows Kits\10\10.0.26100.0\um\GameInput.h
I believe that is Windows SDK which I think has been a requirement for Flutter on Windows, potentially via Visual Studio. ~~But looking at the current installation instructions for Flutter with Windows, it looks like it is no longer a requirement.~~ (I looked on the wrong Windows instructions, please see my next comment)
I am also a bit of a beginner in how to manage C++ dependencies in Windows, so potentially made a mistake here by assuming that Windows SDK can be taken for granted.
I see now, the install instructions for Windows as a target, does still require installing Visual Studio and the Desktop Development C++ task.
I am still not sure if that installs Windows SDK or not for you.
It would be helpful to know if it is the case that it will make Windows SDK installed or not. Especially because if it doesn't, this PR likely has to use NuGet to get the header files.