Home

This is a fork of RetroArch intended to fix its wonderful-but-imperfect Netplay.

Done and merged upstream:

• Removed the "here there be dragons" sign that prevented anyone else from looking at this code.
• Added a README that lightly documents how RetroArch's Netplay works.
• Netplay ring buffer hardened to prevent overruns, which previously caused insane desyncs.
• Ripped out UDP. Everything is done over TCP now. The previous implementation demanded reliability and in-order guarantees anyway, so UDP was just silly. Note that the protocol has also changed in more fundamental ways, so it's not really possible to make a "UDP or TCP" option except by having two incompatible implementations of Netplay.
• Removed all limits on the size of the replay buffer. You want to allow 10 seconds of drift? 10 seconds of drift it is!
• Made stalling work without blocking the UI thread.
• General bugfixes to make Netplay bulletproof.
• Remote pausing. The Netplay support for remote pausing is in upstream. The frontend support for telling Netplay that it's paused is in netplay-new-features-iffy, because it uses an ugly polling approach, and there may be something better.
• Stalling without rerunning frames. Netplay is now one of the many reasons the frontend may pause.
• Support for loading state over Netplay. Similarly to remote pausing, because the frontend changes were iffy, they're in netplay-new-features-iffy.
• Frame CRCing as a last resort for sync. Configurable by netplay_check_frames or the --check-frames option.
• Deterministic player flipping.
• Fix spectator mode. It used to slowly lose time. Lately, it doesn't even work. I haven't touched it, so it continues to not work.

Done:

• Loading state over netplay (frontend changes). In netplay-new-features-iffy pending a decision on the right way to do it.

Todo:

• Infinite testing, of course!
• Rewindless mode. This is strictly-wrong Netplay, but with frame CRCing, can work fine. If one disabled both rewinds and frame CRCing, one would be left with ZSNES-style netplay (no attempt at sync)
• Maybe: Support for input grappling (two players controlling the same input device). Useful for e.g. handhelds.
• Probably not: UDP as redundancy for TCP: Still send input over TCP, but send it over UDP as well, and use the UDP data whenever possible. That gets the speed of UDP with the reliability of TCP. The only reason I'd bother is if people continue whinging about TCP vs UDP (most of whom haven't even tried the Netplay as is...)
• Super-future: Support for launching Netplay on an existing session.
• Super-future: >2 player netplay. Not as difficult as it seems, just need an array of buffers, frames and replay.
• Super-future: Netplay input support for devices other than the simple retropad.