Netplay: Redesign Wiimote data exchange.

[AdmiralCurtiss]

Complete rewrite of how Wiimotes work in netplay. Should solve basically all the weird issues you can run into when using Wiimotes in netplay.

Feature set:

• Full syncing of button state, motion state, camera state, Motion Plus and all supported emulated Extensions.
• Automatic configuration; that is, no need to manually match the configured Wiimotes before starting netplay or anything like that.
• Successive local controller assignment (ie, all players use their own Wiimote 1 mappings)
• Changing button configuration mid-netplay, including the currently attached Wiimote extensions.
• Handling of Wiimote idle timeouts
• Handling of reconnecting a disconnected Wiimote, including cases where the game does not allow player 2 to connect a Wiimote before entering multiplayer mode
• Packet batching

Not implemented in this PR: (because it's not critical and the PR is already huge)

• Input Host Authority Mode
• Golf Mode
• Wiimote EEPROM syncing (always uses a default one, so no on-Wiimote stored Miis or whatever)

[JMC47]

What's the big thing stopping Wii Remote configuration working like GameCube controllers in this?

[AdmiralCurtiss]

The way the GameCube Netplay index re-assignment is implemented is a bit unorthodox; without going into details, it relies on the fact that polling a GameCube controller is fundamentally stateless. The poll at timepoint X+1 is independent of the poll at timepoint X. This is not true for Wiimotes, as they have internal motion simulation state that relies on the actual time point.

Practically speaking, we probably need to split the simulation update from the poll in order to make this work. This should also allow an optimization (that we have for GC) where we pack multiple controller polls into a single packet if multiple players are on the same Dolphin instance.

[Techjar]

Practically speaking, we probably need to split the simulation update from the poll in order to make this work. This should also allow an optimization (that we have for GC) where we pack multiple controller polls into a single packet if multiple players are on the same Dolphin instance.

Yeah, though might that cause issues for the game itself since it could get data updates at an inconsistent rate?

but in practice that's hard to get to because we disable the Controller mapping window during Netplay

That was done specifically because changing stuff would break NetPlay. If we can fix that then it will no longer be necessary. I think it still breaks if you change what's in the GC controller ports, but I'm not 100% sure.

[AdmiralCurtiss]

Yeah, though might that cause issues for the game itself since it could get data updates at an inconsistent rate?

Well we would still call it at the same time from the game's perspective, I just mean we split it out from the current Update() into two functions that we call one after the other with the netplay sync in-between.

Basically right now I do in this PR:

for (wiimote in wiimotes) {
  target_state = wiimote->UpdateSimulationState();
  Netplay::Sync(target_state);
  wiimote->UpdateEmulatedState(target_state);
}

But what I want to do is:

for (wiimote in wiimotes) {
  target_states.push(wiimote->UpdateSimulationState());
}
Netplay::Sync(target_states);
for (wiimote in wiimotes) {
  wiimote->UpdateEmulatedState(target_states[i]);
}

[Techjar]

Oh okay so it'd still be synchronous, just split into two distinct steps instead of interleaving the simulation update and data push.

[AdmiralCurtiss]

Yeah, exactly.

[AdmiralCurtiss]

Alright, I think this is ready now. Please test and review.

[JosJuice]

JMC asked me to look through this PR. Can't say I read every line of code (in particular not the part about controller numbers), but the approach seems sound overall.