Long story short, while I helped my friend with his "up to the neck in MS API" game, I wrote him complete drop in solution library for XInput over SDL. And since making patch for wine was easier than testing his half done game... well, it came to full featured XInput handling
It supports: - hotplugging/unplugging (well, only if game didn't use DInput to scan new devices. if it is pure XInput, then it just works) - all controllers supported by SDL are XInput capable - haptic works
And before cleaning it, I just wanted to ask if XInput over SDL is wanted or not. There is no point in working on regular patch if that is out of question.
Just short points why SDL and not native (which I'm not interested in even remotely): - far better API than XInput - controller database is updated - completely cross platform - same source can be reused to port game ... but, don't treat this as I would try starting some holy war. If it doesn't fit in wine plans, no problem. I can still provide it as standalone patch for those that want it
with regards wh1sper_123
On 26 July 2014 22:52, akjsdfk sdkfnskd wh1sper.123.wtfit@gmail.com wrote:
And before cleaning it, I just wanted to ask if XInput over SDL is wanted or not. There is no point in working on regular patch if that is out of question.
I'm no authority on this, but I suspect we'd like to avoid an SDL dependency for this.
No problem whatsoever ;) Coders should always be able to decide their goals for the project and I already suspected answer like this. As I said, I can always make unofficial patch for those that want XInput
I'd just ask one question if I may. Tried asking over irc, but it was dead as graveyard during the night.
http://msdn.microsoft.com/en-us/library/windows/desktop/ee417014(v=vs.85).as... btw, beware... this code is broken in so many places it is not true (C++ examples are in much better state, though even after compiling them I couldn't test it because it required VC++120d). But, it is nice example to get the gist. More or less 99% of games use one or another variation of this code
What this does? Enumerates DirectInput devices, then enumerates all system devices for each and every DirectInput device it was found, instigates device creation and then checks if device ID contains "IG_". If that string was present, it decides on using XInput. Some games go even a bit further and send XInputSetValue on all ?XInput? controllers as secondary check, where it uses fallback on DirectInput if error occured.
Every other solution out there simply hacks on CoSetProxyBlanket in order to provide those extra devices, which is not exactly clean solution, but if you don't have source like on Windows it is perfectly understandable. Though in wine case, this could be implemented in much cleaner fashion
What should really happen in correct implementation? Each and every XInput device should provide 2 devices, not 1 according to MS specs. 1 for DirectInput and 1 for XInput. And XInput device should contain "IG_" in device ID.
Question: I'm not really versed in Windows, in fact I didn't used them for 20 years, nor do I plan to do that in future. My experience with installing W8 just to compile those examples was terrible enough to need serious yoga and meditation treatments for next 30 years or so
This would spare me a lot of discovery. Which part of Wine is responsible for device creation and enumeration in the case I specified? I would like to finish it up and provide both devices needed
Also, 1 more bug (not in wine, but rather in implementations) as far as controllers go. Some games just do incomprehensible and check string for device name. So, if device name is not exact as MS specified, game won't work no matter what.
with regards wh1sper_123
On 28 July 2014 13:24, Henri Verbeet hverbeet@gmail.com wrote:
On 26 July 2014 22:52, akjsdfk sdkfnskd wh1sper.123.wtfit@gmail.com wrote:
And before cleaning it, I just wanted to ask if XInput over SDL is
wanted or
not. There is no point in working on regular patch if that is out of question.
I'm no authority on this, but I suspect we'd like to avoid an SDL dependency for this.
From what I could tell, SDL has a game controller api that's very
similar to xinput, which is pretty nice, and it can be configured to map to any controller. So, although it is a heavy dependency, it could get us a good solution very quickly.
Few other advantages: * The resulting xinput library could be used on Windows to support non-xinput-compatible controllers. * Steam has a controller configuration GUI, which happens to be compatible with SDL. The only alternative for picking up this configuration would be to duplicate logic from SDL. (Admittedly, this only helps for Wine-based ports of games on Steam, and possibly other games when Steam is used as a launcher.)
We have very little control over heavy dependencies like SDL and can end up with unfixable bugs. One immediate concern is that SDL sets up signal handlers during initialization.
I'd be interested in seeing your code for this even without the cleanup.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-07-26 22:52, schrieb akjsdfk sdkfnskd:
- hotplugging/unplugging (well, only if game didn't use DInput to
scan new devices. if it is pure XInput, then it just works)
My 2c is that this is more of an issue than SDL. Using SDL is probably fine if there are good arguments that support its use and the Wine-internal layering makes sure that xinput_*.dll, dinput and winmm see the same joystick configuration. You could think about calling SDL from winex11.drv or dinput.
- far better API than XInput
I guess here you mean the X input extension rather than Microsoft's xinput_*.dll, right? I guess XInput works better in remote X11 situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I don't really know how SDL talks to the joystick.)
On Mon, Jul 28, 2014 at 12:50 PM, Stefan Dösinger stefandoesinger@gmail.com wrote:
Using SDL is probably fine if there are good arguments that support its use and the Wine-internal layering makes sure that xinput_*.dll, dinput and winmm see the same joystick configuration. You could think about calling SDL from winex11.drv or dinput.
SDL has two different api's, a joystick api and a game controller api. They roughly correspond to dinput (generic joystick support) and xinput (support for gamepads with a specific button layout) respectively.
The advantage of using SDL is that we don't have to worry about how to map any joystick to the required xinput layout, because SDL does that for us. That advantage only applies to xinput.
The advantage of using SDL is that we don't have to worry about how to map any joystick to the required xinput layout, because SDL does that for us. That advantage only applies to xinput.
Not really true, you can do it other way as well https://wiki.libsdl.org/MigrationGuide?action=fullsearch&context=180&... this is off course if controller is mapped in SDL (which is happening a lot lately since configurations made in steam bpm are reported directly to SDL2 AFAIK) . - you can always request axis/button id by name. - you can always load custom simple SDL string mapping for your controller
That is one great thing of SDL, it always works both ways. It provides low (device) and high level (just works) access to everything
with regards, wh1sper_123
On 28 July 2014 22:58, Vincent Povirk madewokherd@gmail.com wrote:
On Mon, Jul 28, 2014 at 12:50 PM, Stefan Dösinger stefandoesinger@gmail.com wrote:
Using SDL is probably fine if there are good arguments that support its use and the Wine-internal layering makes sure that xinput_*.dll, dinput and winmm see the same joystick configuration. You could think about calling SDL from winex11.drv or dinput.
SDL has two different api's, a joystick api and a game controller api. They roughly correspond to dinput (generic joystick support) and xinput (support for gamepads with a specific button layout) respectively.
The advantage of using SDL is that we don't have to worry about how to map any joystick to the required xinput layout, because SDL does that for us. That advantage only applies to xinput.
Another advantage of using SDL, is that we can use the SDL haptic wrapping functions for OSX, Linux, and even Android. In that way we can simply write code for DInput FF -> SDL haptic wrapper, which can be platform independent. Than we would instantly have support for DInput FF on OSX and Android too. The downside is the extra overhead, e.g.: instead of DInput FF -> Linux FF, it becomes DInput FF -> SDL -> Linux FF and this might have some implications to latency-critical applications such as racing-simulators.
Or am I missing something?
Elias
-
akjsdfk sdkfnskd -
Elias Vanderstuyft -
Henri Verbeet -
Stefan Dösinger -
Vincent Povirk