In resimulation mode, we only copy the buttons. The reason for this
is nonobvious:
If we resimulated nothing, then the /duration/ with which any input
was pressed would be approximately correct, since the original
simulation came in as the input came in, but the /number of times/
the input was pressed would be wrong, as there would be an
advancing wavefront of real data overtaking the simulated data
(which is really just real data offset by some frames).
That's acceptable for arrows in most situations, since the amount
you move is tied to the duration, but unacceptable for buttons,
which will seem to jerkily be pressed numerous times with those
wavefronts.
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.
As well as the implementation magic, we now send a platform magic in our
connection header. If the core reports platform dependence and the
platform magic differs relevantly, the connection will be refused.
Since netplay_send_info (client handshake) and netplay_get_info (server
handshake) were practically identical, they've also been merged into a
single netplay_handshake.
This effectively disables check_frames if frame 1's CRC differs between
host and client. This is necessary because some important cores have
nondeterminism in core_run, thus mandating check_frames, while some
important cores have nondeterminism in core_serialize, thus mandating no
check_frames.
Without early saves we couldn't properly detect savestateless cores. We
still can't, really, but we can at least EVENTUALLY detect this
condition. netplay_net has been fixed to do so.
This changes netplay host mode's behavior in net (normal) mode from
immediately blocking to waiting for a connection while allowing the game
to run, like spectator mode.
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.
Rather than counting on the complexicon of used_real calculations, set
used_real when... real is used. (Problem: If the core doesn't read input
at all, used_real won't be set; todo: test with handhelds.) Minor
resilience fixes.
working":
(1) Fixups to the stall logic to make sure it always receives frames
while stalling :)
(2) Disused the used_real field. It was misconfigured and would
frequently claim to be using real data when real data hadn't been
used... this means more replays for now, but used_real will be readded.
(TODO)
(3) Stall duration is now related to sync frames, and thus configurable.
(4) Delta frames were having the good ol' initialization problem, as
frame==0 was indistinguishable from unused. Quickfixed by adding a
"used" field, but maybe there's a better way.
(5) If serialization fails, switch immediately to blocking mode
(stall_frames = 0). Blocking mode barely works, but if serialization
fails, no mode will work!
(6) I'm not sure which bug my replaying-from-previous-frame was trying
to fix, but the correct behavior is to replay from the last frame we had
vital information, not the frame prior. Notionally this should just be
an efficiency thing, but unsigned arithmetic at 0 made this a "just
ignore all input from now on" thing.
