mirror of
https://github.com/dolphin-emu/dolphin.git
synced 2024-11-15 13:57:57 -07:00
8b7bfe6cf9
The old implementation always polled the local 1st Wiimote and used that as input for the Wiimote that is mapped to the player. But the reporting mode for Wiimotes can be different, even when using the same extensions. So an input for Wiimote 1 with a data size 4 could be used for Wiimote 2, which actually requires data size 7 at that time for example. The 2nd problem was that the code added a dummy input into the buffer, when the reporting mode changed. But when the data from the other player hasn't arrived yet, the data in the buffer is out of order. Well, i think this is the problem, i'm not 100% sure, because i don't fully understand how the buffer works. But on the other hand, i'm pretty sure this will just force sync the players on reporting mode changes, instead of allowing them to be apart. Pros: - No more desyncs caused by big bugs in the code. - Can use different extensions for different players. Cons: - Higher latency, because instead of polling 1 controller per player at once, all controllers are polled in order, send to the other players, before the next is processed. - Have to setup the Wiimote, which the player is going to use, instead of the 1st one. Now, if the controller config could temporarily be overridden with the one from another slot, the 2nd problem could be fixed. But at the same time, we would lose the ability to use different extensions. (unless we hack around it somehow, or properly send the used extension to the other players) |
||
|---|---|---|
| .. | ||
| AudioCommon | ||
| Common | ||
| Core | ||
| DiscIO | ||
| DolphinQt2 | ||
| DolphinWX | ||
| InputCommon | ||
| UICommon | ||
| VideoBackends | ||
| VideoCommon | ||
| CMakeLists.txt | ||