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.
An unfortunate hack for cores that translate the keyboard input device
into keydown/keyup events without saving that in the savestate. We
simply replay the previous frame's input before loading the rewound
frame's state, to assure that both the state and the keyup/down state
are correct.
Ideally, cores would save this as part of the state, but it's a bit
proximal and a fairly significant change for those that use it, so it's
easier to fix in netplay.
This abstracts away the details of particular input devices for netplay,
and adds support for mice and (similar) lightguns. Unfortunately, in
practice, no core handles mice or lightguns in a savestate-safe way, so
they need to be used in stateless mode to be reliable, but they do work.
(1) All mode change code unified, so server mode changes and client mode
changes and announcements go through the same functions
(2) New messages which are translateable and work with multiple input
devices
The new input handling makes adding and removing players more
complicated, since data can be present that's not expected from the
connected clients list, or absent that's expected in the list but
actually shouldn't be there.
Squashed commit of the following:
commit 6e1fea3b16bb330ed2862eb00d2e911221c48a34
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 22:16:02 2017 -0500
use the baked in address instead of sockaddr
commit 84f2d389fd6352b3037f48c18d133d2f1063d461
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 22:05:57 2017 -0500
send replies
commit c6733009cc5a25e58391c5fc693b277ea27404b3
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 21:53:12 2017 -0500
send replies
commit a6816c9481f7ea89a3c97597233e54c6354716e7
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 21:46:55 2017 -0500
send replies
commit c2453b73ccafbd53192507affbc11d5f279c2e7c
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 21:26:34 2017 -0500
look for common interfaces
commit fb42e6470242689f5e6160149ef91f0f0abf068d
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 20:06:50 2017 -0500
send broadcasts in all interfaces
commit b7730596df9775fb815007689e9c7cc06b317b03
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 20:00:17 2017 -0500
send broadcasts in all interfaces
commit b620a78052d1b95e81d346f3e5efb233e0547793
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 14:30:31 2017 -0500
add more logging
commit c016c7d559cd631172a58f99cd3e1a1365965b8e
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 14:12:03 2017 -0500
update log messages
commit 0a49ba61f56f2ca483fa76c7a04f0709c68b95ad
Author: radius <andres.430@gmail.com>
Date: Sat Nov 18 13:50:47 2017 -0500
fix lan room listing for rooms > 1, allow connecting in arbitrary ports
Netplay state demotions, i.e. changes from playing to spectating or
disconnected states, could cause chain disconnections of all other
clients. This was due to a bug in when MODE change messages were sent.
Clients rely on the server sending all messages in its own order, and as
a consequence, the server typically holds messages for retransmission
until they can be retransmitted at the correct time. MODE messages were
not held, so could be sent early. When they were sent early, this caused
other clients to panic and disconnect.
A smaller but much stupider secondary bug was also fixed, in which the
first connection could be dropped due simply to writing connections[0]
instead of connections[i] somewhere.
twinaphex