refactor!: Update to windows GameInput api

[lea108]

Breaking changes:
Event keys does change. The new axis names are based on GameInputGamepadState. The new button names are based on GameInputGamepadButtons

• dwXpos -> leftThumbstickX
• dwYpos -> leftThumbstickY
• ...
• button-0 => a
• button-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 read_thread may be stuck after gamepad update in windows  #79
• Sleep(1) in input loop to reduce CPU load High CPU usage #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

[lea108]

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.

[lea108]

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.

[spydon]

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. :)

[zhuhaichao518]

Great Work! I have been waiting for this for very long time. :)

[zhuhaichao518]

Should we still have a thread reading the gamepad state？Can we use RegisterReadingCallback to listen to the update of gamepad states?

[lea108]

I have an experiment branch on my github using that. I haven't wired it up back to Flutter, but it prints out to the log when those events are recevied.

However, it requires both developers and end-users to install an MSI that the NuGet package downloads which requires elevated user privileges in Windows.

I had a chat with @spydon in discord where we decided that due to that limitation, it was better to stay at GameInput v0 which this PR uses that does not require this MSI to be installed in order to receive gamepad data.

That said, if you have a game title that ship with an installer, at that point it probably is doable to include it. But then I think it is more and more common for even games to install to you user folder to skip the elevated user privileges dialog.

[lea108]

If it wasn't for the requirement to install this .msi-file, I am all with you and I think using the callback would be better as GameInput itself has an input thread that calls the callback.

Now it is a question of priority - easy setup and easy distribution vs best possible performance.

[zhuhaichao518]

Makes sense!

[jonasbark]

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

[lea108]

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.

[lea108]

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.

[jonasbark]

I set up a new Windows machine following the official instructions (Visual Studio + C++) and it worked without issues. My initial issue was also fixed by... a restart.

What I did notice is that the analog button values are reported in the opposite format to that on e.g. Android. For my test device (an 8bitdo mini) Windows reports button pressed as 1.0 and button released as 0.0. I have yet to confirm if it's the same case when not using your fork.

EDIT: also happens without your fork

[Erhannis]

So, what's the status, here? I saw some comments about requiring installation of third party software to get it to run, is that still the case, or was that for a different variation or st? Are there any changes that still need to be made?

[lea108]

So, what's the status, here? I saw some comments about requiring installation of third party software to get it to run, is that still the case, or was that for a different variation or st? Are there any changes that still need to be made?

I have asked around in main Flutter discord and as far as I have been able to gather, Windows SDK will be installed as part of installing the requirements to build Flutter apps for Windows. And this PR uses GameInput v0 so the developer should not need to install any additional requirements. Nor should the end-user.

Runtime 3.0 workaround
In d04a6f1 I had to implement a work-aronud for that if an end user does have the GameInput 3.0 runtime installed, the behaviour of GameInput runtime changes even if we use the v0 API version. This looks to have been fixed now in in the 3.1 release of the runtime. I am unsure how widespread the 3.0 runtime is among end users. NuGet has download counts, but it doesn't tell if a popular game has redistributed it to many users.

PR Status
I fixed the clang-format warnings. For me with one controller it works. I haven't done multiple-controller testing yet. There is a rare loss of input from sticks, which has improved by lowering the sleep() value. Overall for me it is much better than crashing my game, but then I don't know how common the crashes are and I am biased as I wrote the PR and it solves the issues for me.