Skip to content
RetrogamingFix Published Updated 6 min readViews unavailable

Fixing Emulator Netplay Desyncs Without Guessing

Eliminate emulator netplay desyncs by matching builds, content, firmware, saves, controller types, and deterministic settings before tuning latency.

A desync means peers no longer calculate the same emulated state from the same input history. It is different from high latency, audio breakup, a stalled connection, or a player dropping from the session. More bandwidth and an open firewall do not repair two machines executing different content or state.

Build a matched baseline first. Every participant should preserve their normal profile, then use a clean, session-specific configuration. Record exact versions and hashes rather than relying on matching filenames or “latest” labels.

Step 1: classify the symptom

Ask each player what appears on screen at the same moment. If one player sees a different score, object position, random event, or game state while the session continues, that is divergence. If everybody sees the same state but inputs arrive late, the problem is latency. If play freezes until packets arrive, it is a connection or buffer symptom.

Note whether divergence occurs at the same in-game event and frame on repeated attempts. A repeatable split strongly suggests deterministic input, content, settings, save, or emulation differences. A disconnect that follows Wi-Fi loss belongs to network troubleshooting even if the user calls it a desync.

Step 2: match frontend and core builds exactly

RetroArch’s official Netplay FAQ requires the same RetroArch version, same core version, and same exact content. Record full version strings and core build identifiers from each peer. “Snes9x” is not enough when nightly and platform builds can differ.

Dolphin likewise requires the same Dolphin version and tries to prevent mismatched versions from joining. For a controlled session, use official releases from the project and isolate a portable profile where the emulator documents that method. Do not exchange arbitrary emulator executables or cores over chat.

Cross-architecture execution can matter. Dolphin’s guide warns that AArch64 and x86-64 recompilers can produce differences affecting its desync detection. If a problem appears only across architectures, reproduce it with like-for-like hosts before declaring the network faulty.

Step 3: verify content by checksum

Every player must use their own lawfully obtained copy of the same game, region, revision, patch set, and disc layout. Compare a cryptographic hash or use the emulator’s built-in checksum tool. Dolphin’s Netplay Checksum tab exists specifically to compare game and, when relevant, SD-card data.

A matching title in a game list proves nothing about bytes. Compressed formats can also have compatibility caveats; Dolphin specifically calls out NKit in its guide. Disable translation patches, randomizers, texture-dependent game mods, and executable patches for the first test unless identical patched output is verified.

Never solve a mismatch by sending copyrighted game images, firmware, keys, NAND data, or private saves to another player.

Step 4: match firmware and mutable storage

Record firmware hashes, region, virtual NAND, memory card, SD card, and in-game save state. Some games read unlocked content, system settings, clocks, Miis, or card data in ways that affect simulation. Dolphin recommends save synchronization and warns that mismatched enabled SD cards can cause divergence.

Begin from a synchronized in-game save through the emulator’s supported mechanism or from a clean boot. Do not distribute version-sensitive save states as a shortcut. A state may embed emulator internals and can fail even when ordinary save data is portable.

Back up every participant’s local save directory before enabling synchronization. Netplay should not overwrite the only copy of long-term progress.

Step 5: remove nondeterministic options

Return CPU engine, timing, region, controller attachments, cheats, overclock, speed hacks, run-ahead, rewind, and core options to the documented netplay baseline. Disable optional peripherals, writable SD cards, microphones, cameras, and real motion controllers unless the emulator explicitly supports synchronizing them.

Dolphin’s Strict Settings Sync can synchronize additional volatile settings, but it cannot transfer missing cheat definitions merely because their names match. Its guide notes that synchronized AR/Gecko enablement does not transfer the actual code files. Verify code bytes or disable codes.

For Wii titles, Dolphin describes Wii Remote netplay as sensitive and experimental; when a game supports GameCube controllers, testing those can isolate attachment-related divergence.

Step 6: choose roles and controller ports explicitly

Confirm which peer owns each emulated port and which device type is attached. A controller profile is local input configuration, while the emulated port and attachment affect shared state. Record expansion devices, multitaps, pak types, and analog calibration where the emulator exposes them.

Start a short deterministic sequence with no spectators and the minimum number of players. Add spectators and unusual peripherals only after the baseline survives repeated runs.

Step 7: tune latency only after determinism is proven

Ethernet usually reduces jitter compared with congested Wi-Fi. Close background uploads and test round-trip latency and packet loss. Adjust the emulator’s input buffer according to its official netplay guide: a larger buffer generally tolerates more delay but increases input latency.

Buffer or rollback tuning can change stalls and responsiveness; it should not be presented as a cure for a repeatable state split. If divergence occurs at the same event on a LAN, stop changing network values and inspect simulation inputs.

Prefer Dolphin’s traversal service or RetroArch’s documented relay workflow when appropriate. Do not expose a machine through router DMZ, disable the firewall globally, or enable broad port forwarding merely to troubleshoot divergence. If direct hosting is required, create only the narrow rule documented for that application and remove it after testing.

Step 8: capture the earliest divergence

Enable logs, checksums, or replay/input recording where supported. Synchronize clocks only for comparing timestamps; wall-clock agreement does not make emulation deterministic. Record the first divergent frame or event, not five minutes of consequences after it.

Run an A/B matrix: same hosts on LAN, same architecture, clean save, no cheats, default settings. Add one variable at a time. If enabling one SD image or code reproduces the split, hash and document it.

Sanitize logs before sharing traversal codes, IP addresses, usernames, filesystem paths, or account tokens. A useful issue report includes exact builds, content hashes, firmware status, controller attachments, save-sync state, host/client roles, buffer settings, architectures, and earliest divergence.

Step 9: verify the repaired session

Repeat the formerly failing sequence at least three times, then play beyond it. Restart every client and reconnect through the normal workflow. Finally restore one enhancement at a time.

The success criterion is identical game state across peers, not merely a session that stayed connected. Separating determinism from transport prevents dangerous network changes and focuses effort on the bytes and settings the emulator actually synchronizes.

Related:

Sources:

Comments