New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin assumes XInputGetState will be called first #3
Comments
Well, the only issue I found with XInputGetCapabilities is games not accepting controller input. I was able to debug an app that crashed using this DLL and I found out the crash is caused by a module not being loaded, so I'm assuming it's an issue with WinRT, which Windows.Gaming.Input is using. Also, I will look into thread safety. |
That doesn't really matter. |
Oh, right. I'll figure out a better way ASAP. The reason I did it this way, because initializing the game pad on DLL injection caused crashes, and I didn't figure out to delay the initialization. |
InitOnceExecuteOnce on top of each function using |
Alright, I've updated the configurable branch. I know I should have asked sooner, but if you know a proper way to implement InitOnceExecuteOnce, please let me know. |
I wanted to take a look and potentially submit a PR back, but looks like the project cannot be opened. Did you commit your .vcxproj changes only partially or something? Anyway, in your case |
Sorry about that, the vcxproj should be fixed now |
Ah, I just used the example by Microsoft. So I can safely remove all stuff related to creating an event object in the callback function? |
Sure thing - just initialize |
Alright, thanks a lot for the help |
I can totally see games call XInputGetCapabilities before XInputGetState, and that will cause a crash.
Current
m_gamepad
initialization is also not thread safe, so in an unlikely event of two thread racing unexpected results may occur.The text was updated successfully, but these errors were encountered: