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.
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 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.
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.
Adding a key to toggle between playing and spectating. This key takes
the place of the previous flip key, although player flipping does
continue to work (and must be rebound if you still want it)
For the time being, if NAT traversal is successful it simply announces
it as an OSD message. In the future it will be used to inform a
matchmaking server of the public port.
This patch also included minor fixes to the NAT traversal implementation
to make the select it demands actually doable.
This commit:
* Reorders the Netplay settings menu to put more useful options at the
top.
* Renames the swap_input setting from "Swap Netplay Input", which is
meaningless and confusing, to "Netplay P2 Uses C1", which is oddly
truncated but at least true.
* Removes the is_client setting altogether, as that's no longer how
client vs. server mode is determined (each are separate options when
enabling Netplay)
Moved settings values into settings->netplay, and global->netplay.enable
is moved into netplay itself, and is no longer a configuration value
whatsoever, as that conflicts with the behavior of the netplay menu.
A couple fixes are still necessary for the client, in particular to
recover a "lost" hostname, but now it is possible to start server or
client mid-stream, and to disconnect intentionally.
Spectate mode is now far more similar to net (normal) mode, and, more
importantly, it works. In addition, spectate mode will not fast-forward
to catch up with the server if it lags too far behind.
Every frame (soon to be configurable), the server does a CRC-32 hash and
sends it to the client. If the client finds that its own hash is
different from the server's, it requests a fresh savestate.
This is a last-ditch effort to sync if all else fails, and it's a
best-effort situation. The size of the buffer should assure that we
always still have the frame around to CRC, but I imagine there are edge
cases where we don't. If you're in an edge case, the CRC is ignored.
Assuming the core supports saving/loading states, and (crucially)
assuming the states are portable across the architectures on both sides
of the connection, Netplay now supports the transmission of savestates.
Right now the frontend doesn't actually send any such requests, as it's
not clear exactly where the code for that should be.
This works in either direction, although I'll admit I have no idea what
happens if they both load at the same time.
Support for remote pausing, and with it, support for Netplay pausing the
frontend correctly. With this patch alone this doesn't work, since
there's no clean way for the frontend to tell Netplay that it's paused.
for this, and in particular, it now sometimes stalls in a way that makes
it very difficult to actually input anything (whoops :) ). Simply
setting the sync frames higher avoids that. With supported cores, this
is incredibly risilient, but when it fails, it mostly fails to freezing,
which is less than ideal.
TODO: Stall frames should be configurable. All the UDP code is still
there but commented out, should be gutted. The original fast-forward
code is now commented out, but really both fast-forward and stalling
should be options; the only complication is that it needs to send
simulated self-input for fast-forward.
twinaphex