Only works on Stride windows

[TobyKLight]

I ran into a problem trying to make a skia based app where VL.GameControllers requires a stride window to have focus before it will return controller data.

I couldn't find a workaround. I think this is the way it works inside Stride. It only passes the input when a stride window has focus.

I could hack it and output a skia texture to a stride window... but in my case that potentially adds complexity with existing Skia based input collection.

I think an ideal solution wouldn't be inside the current repo... could make an alternate input collection method that uses the same code for mapping to the SDL profiles. But if you did that in this repo all the stride dependencies would remain.

I will look into making a fork of the repo using SFML to collect input if it can provide the same level of info about the controller as stride does. (Which is ironic as SFML and SDL are similar frameworks but for my case I already use SFML for the audio playback... so that's one less dependency for me.)

[heavy-d]

Yes, for input detection Stride needs a focused window, definitely a downside in this case.

[TobyKLight]

Ok I looked further into it and experimented with a SFML based approach.

SFML was promising, it gave the vendor and product IDs that would be needed for the SDL mapping lookup.

SFML basically has the same problem as stride approach: You need an SFML window open in order to reliably get the state of its joystick classes. This shouldn't be the case as it has an independent joystick update method but it's bugged.
See SFML/CSFML#136

For anyone else who ends up following this path I will now turn to XInput based approach on windows, of which there is already a contrib. A shame not to be able to work with any controller although apparently lots of controllers do work with xinput.
https://github.com/domjancik/VL.IO.Xbox360Controller