A few corrections/clarifications in the Netplay README
This commit is contained in:
parent
2a0202ccf5
commit
827009d2d3
|
@ -41,15 +41,15 @@ ring, other is the first frame that it's unsafe to overwrite.
|
|||
Read is where it's read up to, which can be slightly ahead of other since it
|
||||
can't always immediately act upon new data.
|
||||
|
||||
In general, other ≤ read and other ≤ self. In all likelyhood, read ≤ self, but
|
||||
In general, other ≤ read and other ≤ self. In all likelihood, read ≤ self, but
|
||||
it is both possible and supported for the remote host to get ahead of the local
|
||||
host.
|
||||
|
||||
Pre-frame, Netplay serializes the core's state, polls for local input, and
|
||||
polls for input from the other side. If the input from the other side is too
|
||||
far behind, it stalls to allow the other side to catch up. To assure that this
|
||||
stalling does not block the UI thread, it is implemented by rewinding the
|
||||
thread every frame until data is ready.
|
||||
stalling does not block the UI thread, it is implemented similarly to pausing,
|
||||
rather than by blocking on the socket.
|
||||
|
||||
If input has not been received for the other side up to the current frame (the
|
||||
usual case), the remote input is simulated in a simplistic manner. Each
|
||||
|
@ -57,12 +57,13 @@ frame's local serialized state and simulated or real input goes into the frame
|
|||
buffers.
|
||||
|
||||
During the frame of execution, when the core requests input, it receives the
|
||||
input from the thread buffer, both local and real or simulated remote.
|
||||
input from the state buffer, both local and real or simulated remote.
|
||||
|
||||
Post-frame, it checks whether it's read more than it's actioned, i.e. if read >
|
||||
other. If so, it rewinds to other (by loading the serialized state there) and
|
||||
runs the core in replay mode with the real data up to read, then sets other =
|
||||
read.
|
||||
other self > other. If so, it first checks whether its simulated remote data
|
||||
was correct. If it was, it simply moves other up. If not, it rewinds to other
|
||||
(by loading the serialized state there) and runs the core in replay mode with
|
||||
the real data up to the least of self and read, then sets other to that.
|
||||
|
||||
When in Netplay mode, the callback for receiving input is replaced by
|
||||
input_state_net. It is the role of input_state_net to combine the true local
|
||||
|
|
Loading…
Reference in New Issue