Persistent mode - properly handle the situation where the controller often disconnects and reconnects

[tvanomr]

Hello, I've decided to modify this app to support a controller usage pattern that I use - gaming on a tablet with attachable bluetooth controller. This controller often disconnects by itself when not used for some time or I disconnect it when i'm done using it. Current implementation destroys virtual controller after real controller disconnects that creates problems if I for example don't quit the game before disconnecting as I often do.
New persistent mode does two things:

• destroys virtual controllers only when 'stop' button is pressed
• preserves 'enabled' state for controllers after they're reconnected (that is needed for some weird controllers or OS configurations when the controller presents itself as 2 controllers to the system).

There are still 2 problems left unresolved:

• when controller disconnects there is some delay between the time it's disconnected and the time when program receives the message and shuts down the working thread. That results in erroneous button/axis state being reported (zero values on all axis/buttons/d-pad) unless the thread checks if a controller is still there every time via DirectInput::IsDeviceAttached() as Joystick::Poll() and Joystick::GetCurrentState() doesn't report such conditions. Unfortunately that adds extra complexity.
• when a tablet goes to sleep and controller gets disconnected there is no WM_DEVICECHANGE being sent to the app. There is no WM_POWERBROADCAST either, it only happens when I connect my tablet to a charger so there is no way so far to properly implement shutting down worker threads on suspend and re-detect devices on resuming.

Some other changes:

• Graceful shutdown. Closing the app removes all virtual gamepads.
• Layout changes: Start/Stop button and checkboxes moved up so that it's still possible to use them in low resolution mode (like 800x600). Configuration dialog also was made more compact to properly fit my desktop on 1280x800 resolution (it should fit even 720p desktop now).
• Graceful working thread termination: a flag and Join() instead of Abort() (Join() should follow Abort() even in current implementation by the way)
• Better null pointer handling.
• Increased sleep time in worker thread from 1 to 5 ms.

[vithrell]

Thanks for contributing to this awesome project! I don't know if author abandoned it but if you already bite into it could you tackle some more issues? I have bluetooth gamepad (ipega) + tablet combo too and this app lets me play some games that wouldn't work with x360ce but there are few that refuse to work properly because of combining virtual controller input with physical controller input (mark of the ninja, super meat boy). I think it is related with issue #19. Even any tips on how to fix it would be greatly appreciated.

[tvanomr]

It's impossible to disable DirectInput controller on the application level because every app should have the same access rights to any hardware properly configured on any OS. The only way to do this is to make(use) custom configurable driver for HID gamepad that presents it as XInput device (I've seen some MotionInJoy hacks for this but didn't try them).
But you can change gamepad order. Simply configure the XOutput connect controller, start in persistent mode, disconnect controller and reconnect it. Unless you have some weird bug (I do have it on one of my tablets) virtual XBox controller should be the first in controller list.
By the way it could be possible to saturate the game with virtual X360 controllers unless the game could work with more than 4 controllers simultaneously and have no way to configure which controllers it uses.