mirror of
https://github.com/libretro/RetroArch
synced 2025-01-30 12:32:52 +00:00
c7d0bf90f6
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.
How Netplay works (as documented by somebody who didn't write it): Note that this documentation is all for (the poorly-named) “net” mode, which is the normal mode, and not “spectator” mode, which has its own whole host of problems. Netplay in RetroArch works by expecting input to come delayed from the network, then rewinding and re-playing with the delayed input to get a consistent state. So long as both sides agree on which frame is which, it should be impossible for them to become de-synced, since each input event always happens at the correct frame. Within the state buffers, there are three locations: self, other and read. Self is where the emulator believes itself to be, which inevitably will be ahead of what it's read from the peer. Other is where it was most recently in perfect sync: i.e., other has been read and actioned. 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 ≤ self. If read > self, logically it should try to catch up, but that logic currently doesn't seem to exist (?) In terms of the implementation, Netplay is in effect an input buffer and some pre- and post-frame behaviors. Pre-frame, it serializes the core's state, polls for input from the other side, and if input has not been received for the other side up to the current frame (which it shouldn't be), “simulates” the other side's input up to the current frame. The simulation is simply assuming that the input state hasn't changed. Each frame's local serialized state and simulated or real input goes into the frame buffers. Frame buffers that are simulated are marked as such. Post-frame, it checks whether it's read more than it's actioned, i.e. if read > other. If so, it rewinds to other and runs the core in replay mode with the real data up to read, then sets other = read. 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 input (whether live or replay) with the remote input (whether true or simulated). In the previous implementation, there was seemingly nothing to prevent the self frame from advancing past the other frame in the ring buffer, causing local input from one time to be mixed with remote input from another. The new implementation uses a not-at-all-better strategy of simply refusing local input if it steps past remote input. Some thoughts about "frame counts": The frame counters act like indexes into a 0-indexed array; i.e., they refer to the first unactioned frame. With self_frame_count it's slightly more complicated, since there are two relevant actions: Reading the data and emulating with the data. The frame count is only incremented after the latter, but the nature of the emulation assures that the current frame's input will always be read before it's actioned (or at least, we should certainly hope so!)