Fixing a Game That Runs Too Fast or Too Slow in an Emulator
The game runs, but noticeably faster or slower than it should — usually a frame-timing or region mismatch, not a broken core, and quick to isolate once you know where to look.
A game that’s audibly or visibly running at the wrong speed almost always traces back to one of a small number of specific, checkable causes — a display refresh-rate mismatch, a region/timing difference, or the host system genuinely not keeping up — rather than a deep emulator bug.
Step 1: check the on-screen performance counter first
Settings → Onscreen Display → Onscreen Notifications → Display Framerate
If the reported frame rate is well below the core’s target (commonly 60fps, though this varies by system and region), the host isn’t keeping up in real time — skip to Step 4. If the counter shows a stable, correct rate but the game still feels wrong, the cause is more likely one of the timing mismatches below rather than raw performance.
Step 2: check for a region/timing mismatch (NTSC vs. PAL)
Many older consoles ran at genuinely different frame rates depending on television standard — commonly 60Hz (NTSC) versus 50Hz (PAL) — and a game running under the wrong region’s timing will play audibly and visibly faster or slower than intended, even with the emulator working perfectly correctly. Confirm which region the specific ROM/disc image is from, and that the core is configured to match it, rather than assuming a default:
Settings → Core → check for a region or "Timing" override specific
to the loaded core, if the system has this concept
Step 3: check “sync to exact content framerate” settings
Modern displays commonly refresh at 60Hz, which doesn’t exactly match every classic system’s actual native frame rate (some run closer to 59.94Hz or 50Hz). A frontend’s dynamic rate control feature adjusts audio pitch very slightly to keep video perfectly smooth against the display’s fixed refresh rate — turning this off can, counterintuitively, fix a very subtle “not quite right” speed perception in some setups, at the cost of reintroducing a small amount of audio/video drift over long play sessions:
Settings → Audio → Synchronization → Dynamic Rate Control
Step 4: confirm the host isn’t simply overloaded
If Step 1’s frame counter showed a genuinely low rate, the fix is reducing load rather than chasing a timing setting: lower internal resolution, disable demanding shaders, and confirm dynamic recompilation is enabled rather than falling back to a slower interpreter, if the core offers that choice:
Settings → Core → check for a "CPU Emulation" or "Recompiler"
option specific to the loaded core
Some systems (particularly sixth-generation consoles like the PS2 or GameCube) are demanding enough that even a reasonably capable host system needs dynamic recompilation enabled to sustain full speed — see how CPU emulation works for why interpretation alone often isn’t fast enough for these systems specifically.
Step 5: rule out a frame-limiter fighting VSync
A frontend’s own frame limiter and the display driver’s VSync can occasionally conflict, producing stutter that reads as “wrong speed” rather than smooth motion at a consistent rate. Testing with VSync toggled off (temporarily accepting potential screen tearing) isolates whether this specific interaction is the cause.
Why region and refresh-rate mismatches are the most commonly missed cause
Unlike a raw performance shortfall, a region/timing mismatch produces a game that runs at a consistently wrong speed rather than one that stutters unpredictably — which makes it easy to mistake for “my computer isn’t fast enough” and go straight to lowering settings, when the actual fix is confirming the loaded content and the core’s timing configuration actually agree with each other.