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.
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.
