Is the GDK suitable for Enterprise .Net developers for Gamepad Input

[ShadowMarker789]

Microsoft Documentation says (Under Getting Started):

GameInput is the recommended API for all new code, regardless of the target platform, because it provides support across all Microsoft platforms (including earlier versions of Windows), and provides superior performance versus legacy APIs.

And also says:

GameInput is available on all Windows platforms—PC, Xbox, HoloLens, IoT, and others—and is callable from GDK, Win32, and Universal Windows Platform (UWP) applications. Most importantly, it's available on earlier versions of Windows all the way back to Windows 7 via a redistributable installer package. This enables a single input codebase to be used across the entire Microsoft ecosystem, with no platform/version special-casing required.

For enterprise developers using C# and the .Net toolings Is the GameInput APIs from the GDK suitable to use?

We are migrating from .Net Framework v 4.5.2 to .Net 6 since v 4.5.2 ran out of support a while ago.

In this upgrade process we were reviewing our APIs and was going to move from SharpDX.XInput which uses XInput v1.4 if available, falling back to v1.3, v9.1.0 sequentially if those are not available.

Our use-case is embedded machine remote control using the gamepads to remotely control unmanned machinery.

For .Net developers are we expecting there to be C# bindings available, and if not what's the modern recommended way for .Net applications to read input from controllers?

[BL1NDX3N0N]

There are major differences between XInput and newer input APIs. Newer input APIs are built specifically to handle features of gamepads following the release of the Xbox One. For example, haptics such as impulse triggers featured in Xbox One controllers are not available for interop in XInput. The same can be said for gamepad extensions such as keyboards which I am sure newer input APIs facilitate such functionality.

If you are not trying to target the Xbox One (and newer) or access the complete feature-set of controllers after the Xbox 360, which means you just want to poll for joystick and button input, then XInput will be more than sufficient for your use-cases. Anything more beyond that, you should be utilizing newer APIs Microsoft has to offer. I do want to mention that XInput isn't going anywhere, tons of modern games still utilize the API and it must exist for backwards compatibility but I cannot speak on behalf of Windows IoT. In regards to performance, you are not a user-group that is going to be taking advantage of such performance gains nor will they be noticeable for your current application, so it is negligeable. As far as newer APIs offering backwards compatibility, I heavily assume such is done by deferring calls to legacy APIs which include XInput and/or DirectInput.

If you are wanting a new wrapper that is more intuitive and documented for XInput than what you have now I seriously recommend you check out a wrapper I made over XInput 1.4 for those targeting .NET.

https://github.com/BlindEyeSoftworks/BlindEye.XInput

The licensing is pretty basic but if you do not like it I give you complete and express permission to apply your own license to it and use it however you like. If you need a custom build for your specific use-case I am also more than happy to write such free of charge if it's within scope. If there is anymore info you need in regards to XInput and newer APIs feel free to ask. I have updated my answer to correct mistakes and provide more insight, I will also be updating my answer once I have more information on the APIs available for those shipping code for Windows IoT.

EDIT:

After digging around through some source code and documentation it is becoming pretty apparent that the GameInput API is its own entirely brand new API serving as a replacement for XInput. Nowhere was I able to find, nor prove, that calls are deferred to legacy APIs such as XInput either, meaning they would not be shipped with Windows IoT nor would said drivers and legacy APIs be compatible. I do not know if you are wanting to use these gamepads wirelessly but if so it is going to be even more trickier since the only hardware Microsoft lists as compatible would be a USB Xbox 360 controller, meaning dongles would not be an option without creating your own driver. As far as the Xbox One's Bluetooth capable controllers, I am not seeing any drivers available for such. My recommendation is that depending on the amount of machines needing to be controlled you can setup a single server which you will be able to connect controllers to and address them to specific machines. That server would then consume input and send them over the network to applicable IoT devices. Microsoft has created a similar sample here doing such for controlling robots. But to answer your main question, aside from rolling your own drivers and an API, the GameInput API would be very well suited for your application since it is expected to be used in the AAA game-industry. Unless someone else is able to chime in, or another option does exist which I have overlooked or missed, it seems as though said API is really your only option for IoT aside from utilizing a server.

[BL1NDX3N0N]

Very interesting. Did not know the library came pre-installed and thought it was something developers needed to redistribute themselves (hence the SDK). Once I have some time I will do some more RE work and testing on this. For the most part however, you shouldn't be attempting to wrap it yourself as Microsoft has already done that for you and you already have access to the API from a managed environment. Going this route is reinventing the wheel. I was decompiling only because I wanted to see if calls were being deferred to legacy APIs for backwards compatibility, I was not suggesting you consume the newer API yourself.

[ShadowMarker789]

Very interesting. Did not know the library came pre-installed and thought it was something developers needed to redistribute themselves (hence the SDK). Once I have some time I will do some more RE work and testing on this. For the most part however, you shouldn't be attempting to wrap it yourself as Microsoft has already done that for you and you already have access to the API from an unmanaged environment. Going this route is reinventing the wheel. I was decompiling only because I wanted to see if calls were being deferred to legacy APIs for backwards compatibility, I was not suggesting you consume the newer API yourself.

There are redistributables so I hear. I have not yet found any. 🤷‍♀️

Also turns out many of our clients are still running Windows Server 2012 R2 which really dampens things as that one did NOT have GameInput preinstalled.

I can always do runtime checks for API availability and polyfill from older APIs as necessary.

E.g.:
Prefer GameInput
Else XInput 1.4 (Realistically everyone should have XInput 1.4)
Else XInput 1.3
Else XInput 0.9
Else DirectInput (Should never not be available)

And have a IInputProvider interface, and a set of classes, one class for each underlying implementation.

[BL1NDX3N0N]

I actually did some questioning around with a group of people I work with and asked them to look in their system directories for the DLL in order to confirm whether it ships with Windows, all of their systems (10 and 11) contained the DLL. So as far as redistributables go, seeing how it appears as though Windows ships with it, I don't exactly know what you would be redistributing unless said redistributables are intended for older versions of Windows which did not ship with it such as Windows 7 and 8. At this point it is just speculation because Microsoft is not being very open about this in their documentation and if they are being open then it is surely difficult to find information I may have overlooked.

I do not know if I would go to the extent of checking if the API is available however unless you plan on running this software across numerous versions of Windows. Even if such is the case, you are the one installing Windows and configuring the environment correct? If so, then it should always be available as you would be the one making sure it gets installed. I was also under the assumption this software was going to be exclusive to Windows IoT devices, if such is the case then the Game Input API is the only API available for said platform. Nowhere was I able to find documentation that indicates XInput and respective drivers are shipped or supported on Windows IoT.

Sorry for the small ramble, I have been up for two days straight assisting others and my brain is deprived right now. Need to get some sleep but please keep me updated! In the morning I'll send a message out to a group of people that are part of the Microsoft game dev community, they actively work with the GDK and Microsoft employees who also work with it tend to hang out there to help others. I think it is worth a shot.

[BL1NDX3N0N]

If there are any specific questions you would like me to ask them please note them here!

[ShadowMarker789]

If there are any specific questions you would like me to ask them please note them here!

Yeah, mostly the redistributable packages, do they even exist? Are they in fact a thing?

Regarding Windows IoT, I'm talking about the Windows 10 IoT 2019 LTSC and the Windows 10 IoT 2021 LTSC both of which are built off of an Enterprise version of windows, so it's fully-featured, full windows. Just doesn't have a bunch of preinstalled apps and whatnot.

For us, we're running this on basically anything and everything. Some of our clients are running this on Windows Server 2012 R2, and are considering upgrading to Windows Server 2019, but I don't know if GameInput comes in Server 2019.

I know that XInput works on the IoT devices we're running. One of the hardware devices is an AdLink MXE-5501 machine, which is quite a powerful industrial computer for its ability to survive 65 C ambient air temperature.

Also we are NOT the ones installing windows sometimes. Sometimes it's done for us, and we just have to work with whatever virtualized server we get provided with. 🙃

So yeah, basically - Redistrutable for GameInput? and do they plan to make wrappers for the GDK/GameInput for us .Net developers?

Thanks

[BL1NDX3N0N]

Sorry for the late reply, have been waiting for a response but have not been given one as the server has been pretty quiet lately. In my above comment about the DLL being shipped with Windows as well for the DLL being able to be redistributed, it should be pretty straight-forward to create your own bindings for the public API. To do such you can just use the public documentation for function names, parameters, and data types.

I am considering creating my own bindings like I did with XInput and releasing it but with the API still being relatively new I am going to wait as Microsoft may very well be working on one already. Each time I have tried to get ahead of Microsoft they have always released a similar project not even half-way through the course of my own which they also do a much better job at and have a much larger audience and reach.