Improve Android arcade emulator performance without breaking timing
Begin from defaults, keep throttling enabled, and measure one repeatable scene after the device warms up. Reduce display and frontend overhead first, test a different supported renderer second, and use frameskip only as a visible compromise. Do not change CPU clock or machine timing to make an unsupported game appear fast.
Do this in order
- 01
Restore default emulator settings and close screen recorders or overlays.
- 02
Record app/core version, device model, Android build, battery mode, and display refresh rate.
- 03
Measure a repeatable gameplay section for at least ten minutes.
- 04
Check sustained emulation speed and audio underruns, not only rendered FPS.
- 05
Reduce shaders, scaling filters, and excessive output resolution before core timing changes.
- 06
Retest one change at a time and keep the best verified baseline.
Decision and diagnostic table
| Signal | Interpretation | Action |
|---|---|---|
| Starts fast, slows after minutes | Thermal or power limit | Cool device, remove case, compare power mode |
| 100% speed but uneven display | Frame pacing or refresh mismatch | Test supported renderer and display rate |
| Below 100% with crackling audio | Core workload exceeds sustained capacity | Reduce overhead or choose a lighter supported target |
| Only one game is slow | Machine complexity or driver-specific issue | Compare driver status and device tier |
FPS is not emulation speed
A skipped video frame can preserve game timing while reducing visual smoothness. Conversely, a frontend can display frames while the emulated machine runs slowly. Use the core’s speed percentage or equivalent timing statistic.
Keep the same save point or attract-mode segment so changes are comparable.
Test sustained, not burst, performance
Phones can boost briefly and then throttle as temperature rises. A ten-minute run exposes whether a setting is genuinely sustainable. Record device temperature only if Android exposes it through a trusted diagnostic; do not invent precision.
Battery saver, charging state, background capture, and high-refresh displays can all change results.
Preserve correctness
Disabling synchronization or changing the emulated CPU clock can create sound, input, physics, or save-state errors. Treat those controls as machine-specific experiments, not general performance fixes.
If current MAME cannot sustain a demanding machine on your device, document that boundary. A deliberately versioned fallback can be considered, but it needs its own accuracy, license, and romset review.
Performance testing does not justify downloading a popular commercial game. Use your own lawful dump, creator-authorized content, or a synthetic fixture.