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.
This commit adds support for temporary desync in netplay. When frontend
features that can't be truly synced, in particular rewind, are used,
netplay is momentarily disabled. As soon as the feature finished, e.g. a
rewind ending, netplay resumes with a state load. For rewind, netplay
peers won't actually experience the effect of rewind, but they will load
the rewound state.
This commit makes spectator mode and slave mode in netplay always stay
ahead of the input, thereby avoiding rewinds, which is sort of the
point. This also changes catch-up detection to be a bit less eager, so
that they hopefully don't flap between stalling for server input and
catching up with that input.
This used to be a configuration option because spectator mode and "net"
mode were incompatible. When the ability to switch between player and
spectator was added, the configuration option was removed, since it was
no longer a mode toggle. This re-adds it, mainly so that I can use it to
implement regression tests.
This patch transfers core_reset across netplay. Resets effectively
worked before thanks to check_frames, but this makes resets work even
without check_frames, and in particular should allow resets to force
sync in savestateless cores, bringing them one step closer to actually
being usable by non-experts.
Previously, the host would time out waiting for the guest to enter a
password, as the timeout was not conditionalized on whether the guest
was actually playing. This fixes that.
The SRAM transfer in netplay handshake now uses autosave_lock and
autosave_unlock. Will possibly fix a hang/crash bug on Android with
netplay and autosave conflicting.
Previously, if two clients were connected to the same server and one of
them was ahead of the server, the only way to rectify that situation was
for the client to get so far ahead that it stalled, as the server could
only catch up with an ahead client if all clients were ahead. That's
unrealistic. This gives the server the alternate option of demanding
that a client stall. This keeps things nicely in line even with >2
players.
Since the quirks protocol was that a core could report variable
savestate size, but the host then tells it "no", we should actually
accept the variable size quirk in netplay, since RetroArch refuses to
allow cores to actually produce variable-size states.
In the previous catch-up system, we would only try to catch up if we
were falling behind the farthest-behind peer. However, as they would
also only try to catch up to us, everyone basically agreed to the
worst-case latency. It makes more sense to try to be in parity with your
direct peer than with indirect connections.
Previously, we could be stalled by one player but still reading data
from another, which would wedge the client because we would never act
upon the newly-read data. Now we act upon data even if we're stalled.
Fixes bugs in initial connection with high latency.
Making the netplay handshake protocol send the core and content as an
explicit command, so that the other side can (notionally) choose to load
it. That isn't implemented, of course.
The idea:
* Use a fixed number of delay_frames (eventually to be fixed at 120,
currently still uses the config variable, 0 will still be an option)
* Determine how long it takes to simulate a frame.
* Stall only if resimulating the intervening frames would be
sufficiently annoying (currently fixed at three frames worth of
time)
Because clients always try to catch up, the actual frame delay works out
automatically to be minimally zero and maximally the latency. If one
client is underpowered but the other is fine, the powerful one will
automatically take up the slack. Seems like the most reasonable system.
Gregor Richards