This makes sure ReceiveRaw() won't block forever, so Poll() has chance
to SendRumble().
Practically, it seems the Joycons frequently send inputs so it's not
necessary, at least for the bluetooth version I got.
I was using two Joycons as a single controller. One (often right, sometimes
both, sometimes left) of the Joycons seems to have random lags.
This patch reliably removes the lag for me.
Potentially fixes#32.
More context:
I first excluded the possibility that the Bluetooth connection is lagging,
because when I click the "locate" button, both Joycons can rumble
immediately without lag.
Reading the existing issues seems to suggest something was wrong with
threading. When I tried moving both Joycons' "Poll" to a single thread,
by calling both ReceiveRaw() and other.ReceiveRaw() in a single Joycon
Poll thread, and removing "lock { ...}"s), lag still exists.
I then suspected the I/O loop is too busy so the code does not have time
to consume events in time. By adding some debug prints, I was able to
confirm that at the time the code receives an event (after hid_read),
it was already too late. However, it is strange that a) hid_read almost
always returns immediately, b) a single "poll" still takes a few
milliseconds. Finally, I found "SendRumble" is the culprit causing
the majority of the few milliseconds delay. Therefore the patch.
The 5 seconds is not a scientific choice. It works for me. I don't have
a USB controller to test it right now.
On some original Nintendo controllers gyro drift occurs (moves
constantly to the right, for example).
Not dividing the neutral point by 2 seems to fix the problem, and
it doesn't seem to effect other controllers negatively (tested
with 8bitDo N30 pro and SF30 Pro).
- Rumble support
- Ability to rebind keys
- No longer need to use "Also use for axes/buttons"
- System-wide compatability (use your joycons with Steam, or something)
- Requires ViGEm driver (provided in release)
