The previous default policy in netplay for sharing was to always share.
This appears to be causing more confusion than anything else, mainly
because the UI is terrible. The UI is a different problem, but for now,
I've changed the share policy: If you netplay with only one input
configured, it will share; if you netplay with multiple inputs, and
don't explicitly ask to share one, each device will get one client.
network/netplay/netplay_frontend.c: In function ‘netplay_announce_cb’:
network/netplay/netplay_frontend.c:734:32: warning: format ‘%X’ expects argument of type ‘unsigned int *’, but argument 3 has type ‘int *’ [-Wformat=]
sscanf(val, "%08X", &host_room->gamecrc);
~~~^ ~~~~~~~~~~~~~~~~~~~
%08X
Unsurprisingly, netplay and runahead are wildly incompatible; both rely
on internal rewinding, without communicating this fact to each other.
Somewhat more surprisingly, netplay already has all the infrastructure
for negative input latency, as it's structurally the same as receiving
delayed input from a peer. This patch makes the two features
"compatible" by disabling runahead per se when netplay is active, and
using runahead's configuration to adjust netplay's own input latency
feature, which is now allowed to be negative. The effect is mostly the
same (modulo the second core support), and it doesn't confuse netplay
peers.
Really silly bug had netplay forgetting to unset device availability
when a client goes to spectator mode. As a consequence, in certain
configurations, later joins would automatically choose the wrong device,
and you'd have to manually specify a device to get the right one. This
fixes that.
Netplay sync incorrectly checked whether the replay pointer was behind
the unread pointer twice, when in the second check it should only have
been checking if it was behind the current execution pointer. Because of
how resimulation works with device sharing, I THINK this could affect
sync. Even if it can't, it's wrong.
