Netplay: Fix synchronization for the Wiinote netplay #4016
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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)
mimimi085181
force-pushed
the
sync-wiimote-netplay
branch
from
c603ae3
to
8b7bfe6
Compare
|
The code LGTM, if @JMC47 confirms this does what it should, we can merge. |
|
Yes, i'm waiting for JMC to test this. I'm really interested in a case where both players are apart as much as possible with a large buffer. And then the reporting mode is changed, like by going to the home menu on new super mario bros. If it works as i think it does, it will make the player, who is ahead, wait for the other, before continuing. |
|
This works for games that let Wiimotes stay connected at all times. There are still a lot of weird behaviors, but, those were pre-existing issues. |
| } | ||
|
|
||
| } // unlock players | ||
|
|
||
| while (m_wiimote_current_data_size[_number] == size && !m_wiimote_buffer[_number].Pop(nw)) | ||
| while (!m_wiimote_buffer[_number].Pop(nw)) | ||
| { | ||
| // wait for receiving thread to push some data | ||
| Common::SleepCurrentThread(1); |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
Cons:
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)
This change is