These are all good suggestions, but I regret to inform that this extension is a very simple hack that I offered to do for 10 dollars total as I knew the exact thing I have to do. There are 99 lines of code in it, 73 of which are just boilerplate to set up function hooking.
-
I have previously investigated DirectInput support, but ultimately I do not know enough about DirectInput internals to even tell which function I’m supposed to rewire, and it does not seem justified to spend a day figuring that out unless someone actually wants to pay for that - for some reason.
-
GameMaker has externs for whatever rumble that is in XInput API via
gamepad_set_vibration. -
Steamworks.gml has Steam Controller functions. Most of them are very simple wrappers around the C++ API and the documentation may prove useful. Steam Controller API had been deprecated in favor of Steam Input API in the most recent versions of SDK, but GameMaker doesn’t use them yet.
-
This sounds like the kind of thing that I would agree to do if I had absolutely nothing to do and someone was willing to pay for it even though the returns are likely to be marginal or lost entirely to cross-thread and GML<->C++ interoperation cost.
-
Steam Input API allegedly covers that, but see above. I don’t believe that you could really “write your own” without having to reverse-engineer multiple versions of protocols used by each device (as most of these do not have publicly available documentation) or striking deals with each company, which might be why Valve has a monopoly on that for now.
-
There are Async - System events for that.
-
I’m open to writing wrappers for any kind of device - no matter how dead or exotic - so long as someone is willing to cover the costs of getting such a device, or is willing to pay extra for me having to write the code without being able to test/debug it (which in some cases can exceed the cost of a device unit).