Implement For Windows!
AldaronLau opened this issue · comments
System Support Request
This library should support Windows.
I was looking at a implementing this for windows but I'm not sure which way to get input is best in this scenario.
So far I have seen 3 ways to do it:
- Make a Message-Only Window and use joySetCapture for the message queue
- Put joyGetPos on a loop to update it
- Maybe some form of hook into the message
What would you think would be best to do?
@iRaiko in my previous WIP implementation for the older version of stick (which is still in src/ffi/windows.rs), I used joyGetPos - but since then I've rewritten the library to use async for performance purposes. I would say a loop probably has performance implications, so probably a separate thread that blocks waiting for messages is necessary, and then wakes the future when new input messages are received. And if there's a callback API then the callback can wake it. I'm not sure which Windows API can do that, and I also know there are many APIs available, some of them deprecated (which I don't think we should use), but I believe there's at least two that aren't. I'm not sure if this is a thing, but something like Linux's epoll that would work with joyGetPos would be preferable.
@iRaiko On further research, it looks like something like this could be a good starting point for the code. I think both APIs are blocking, so stick would have to start a separate thread to use these APIs.
I also think UWP: Universal Windows Platform would be a cool implementation that might make xinput/directinput unecessary to support. What I don't know is if this is possible to use as a library rather than a framework, which would be necessary. It would be nice, though, because it also covers other Microsoft platforms that aren't Windows (Like VR Headset, Windows IOT, and XBox - which is on stick's list of targeted platforms). It might also require C++ shims, which though not ideal, I believe is worth the extra platform support.
I forgot to mention that it appears as though joyGetPos is deprecated.
I saw that aswell, was looking into using RawInput and since UWP is using win32 api's i assume it would work with that aswell. One question i had was if it is alright to use the winapi crate or if I would implement all the functions myself to avoid external crates.
@iRaiko Using the RawInput API seems like the right choice (I think you're right about it working across UWP platforms). Even though I like to avoid extra dependencies, I think it's a good idea to depend on the winapi crate because it's almost impossible to get the FFI types right if you don't use it.
@iRaiko Just checking in. Any updates on this? Getting stuck on anything that I could help with? Have you decided not to work on it, or just haven't gotten around to it yet (I don't see anything recent on your GitHub)? Just curious to see how it's going, since it's a difficult issue to solve.
Hey @AldaronLau sorry, i had some stuff going on. I have worked on it and will put it up on github sometime tomorrow.
It's very much a mess at the moment but it manages to read the input of the controller without relying on any external crate. Will be working through my to do list on there and if you have any suggestions would be great to hear
@iRaiko No worries. That's awesome, I'll definitely make time to look through it this weekend! I'm new to the draft PR feature on GitHub, but I think it would be helpful. Would you mind opening one (it's ok if it's not for the most recent stick)? If it's a separate repository with history unrelated to stick, then don't worry about it for now. Thank you for putting in the work!
@iRaiko looks like you're on the right track to getting Stick working on Windows! I looked through the code and had a couple bugfixes that I put in a PR on your hidtest repository. Let me know if you have any questions or want help at any point.
Fixed by #29