Per-game settings: overclock, internal resolution and save states

A game stutters, you raise the overclock of the emulated processor, the problem goes away. Three days later, another game starts crashing at the same spot every time, and a third one loses its audio. The culprit isn't the console: it's the setting left active for the whole catalogue. Emulation isn't something you set once and for all. Every title has its own engine, its own programming habits, its own original flaws. Frontends plan for exactly that: one general configuration, and exceptions saved game by game. Here is how they work, what internal resolution, overclock, save states and rewind are really worth, and at what price.

Why a global setting always ends up getting in the way

Emulation options are almost never pure improvements. They are trade-offs: accuracy against speed, fidelity against comfort. What suits one game doesn't suit the next.

The most common example comes from period slowdown. Many Super Nintendo games slowed down when the screen filled up, and the difficulty was tuned around that slowdown. Removing it everywhere makes some titles more pleasant and others unplayable.

Same logic on the image side. Doubling the internal resolution goes through easily on a PlayStation 1 racing game and makes a busy 3D fighting game drop frames. A global setting forces you to hold back to the worst case for the whole catalogue.

How a per-game override works

The principle is a stack of files, from the most general to the most specific: the general configuration, then a file belonging to the emulation core, then a file belonging to the folder, then a file belonging to the game, which has the last word.

The Libretro documentation describes these three override levels in RetroArch and says where they land: a .cfg file stored in /config/<core-name>/, named after the core, after the content folder or after the game. Only the settings that differ from the previous level are written: a well-made override file fits in a few lines.

Two mechanisms not to be confused

There are two families of settings, and they are not saved in the same place.

• Frontend settings (image, audio, latency, rewind) are locked in from the quick menu, Overrides entry, then saving for the current game. Result: a .cfg file.
• Core options (internal resolution, overclock, emulation accuracy) are locked in from the quick menu, Options, then Manage Core Options and Save Game Options, which saves the options for the current content only. Result: an .opt file.

For those files to be read back automatically, two switches must be active in the configuration settings: Load Override Files Automatically and Load Content-Specific Core Options Automatically. That is the number one cause of “I saved it, but nothing happens”. The labels vary with the RetroArch version and the firmware, and some proprietary frontends work differently, to be confirmed depending on the version: remember the logic, not the wording. The basics are in our guide to RetroArch settings.

Internal resolution: what it changes, what it costs

Internal resolution only concerns 3D systems. The emulator has the scene computed at a higher definition than the original console: polygon edges become sharp, textures stop shimmering, the 2D interface generally stays unchanged.

On a 2D game, this setting doesn't exist. A Super Nintendo or Game Boy Advance image is a fixed grid of pixels. What can be adjusted there is the scaling and the display filters.

How far should you go? Lower than you'd think. On Linux consoles built on the Allwinner H700, from the RG35XX Pro to the TrimUI Brick, the PlayStation 1 runs well at native resolution and the headroom for double is thin, game by game. On recent Android machines, Retroid Pocket 5 or 6, the headroom really is there, on PS1 as well as PSP. The reflex stays the same: one notch, ten minutes on the busiest scene, step back down if it drops frames. Our PS1 emulator comparison details the differences between cores, often more decisive than the multiplier.

Two side effects. A high resolution brings out the flaws of the era: poorly drawn fog, stretched textures, a blurry 2D interface next to sharp 3D. And it works the graphics chip continuously, so it heats up and draws power, even when the game isn't stuttering.

Overclocking the emulated processor

This is about speeding up the processor simulated inside the emulator, not the chip in your console. You are not touching the hardware: you are asking the software to act as if the original machine were faster. The actual load does go up, though, since there are more instructions to simulate.

What it is for: removing slowdown that was present on the original console, shortening certain loading times, holding the frame rate when the screen fills up. It does not fix an emulator that is too slow for your machine: if the game stutters because the processor is struggling, emulated overclock makes things worse.

The options are explicit, including about their risks:

• Beetle PSX, CPU Frequency Scaling (Overclock): from 50% to 750%, in steps of 10%, default 100%. The documentation states that some games have an internal frame rate limiter and gain nothing, and recommends keeping the default value in most cases.
• PCSX ReARMed, PSX cpu clock on versions with a dynamic recompiler: from 30 to 100, default 57. The documentation warns that this setting causes compatibility problems and should only be changed for games that need it.
• Snes9x, Reduce Slowdown (Hack, Unsafe): disabled, light, compatible or max. The name says the essential, and max mode breaks more games. The SuperFX Frequency option, from 50% to 500%, only concerns cartridges with a SuperFX chip.
• Mupen64Plus-Next, Count Per Op: the number of cycles counted per instruction, hence the simulated speed. Some games only accept one specific value.

Don't confuse this software overclock with the hardware overclock offered by some custom firmwares, which raises the actual frequency of the chip. That one puts the machine's lifespan on the line.

Save states: useful, but fragile

A save state is a photograph of the core's memory at a given instant: registers, RAM, the state of the simulated chips. Nothing to do with the native save, which the game writes itself into its battery or onto its memory card, and which stays readable by any decent emulator.

Hence the limits. A state can only be read back by the software that wrote it. RetroArch's help is explicit: these files are generally not portable and may not work with other versions of the same core. Changing core, updating the firmware or moving from one console to another is enough to make them unreadable. Your progress only holds if it was saved inside the game.

Not all cores are equal either. RetroArch shows a support level for each one: none, basic (save and load), serialised (which adds rewind), deterministic (which adds run-ahead and netplay).

Two comfort options are worth knowing: Save State: Auto Save, which creates a state when the game is closed, and Save State: Auto Load, which reloads it at the next start-up. Handy on a handheld you switch off mid-session, but it doesn't excuse you from saving inside the game. The full subject is covered in our article on saves on retro handheld consoles.

Rewind and its price

Rewind records states continuously into a memory buffer: holding a button takes the game back a few seconds. It is comfortable on demanding platformers and racing games.

The cost is announced bluntly: RetroArch describes the Rewind Support option as causing a heavy performance loss while playing. On a Linux machine that was barely holding its frame rate, switching it on is enough to make the game drop frames. Two settings go with it: Rewind Frames, the number of frames rewound per step, which sets the speed of the rollback, and Rewind Buffer Size (MB), the memory reserved for the buffer, which determines the depth of history.

Two refusals come up often. RetroArch announces that rewind is unavailable because the core doesn't handle serialised states: change core or give up. Or that it is impossible because the implementation uses threaded audio: it is the audio driver that forbids it. In every case, this setting is switched on game by game, never globally.

The method: one setting at a time, and write it down

Per-game configurations become unmanageable if you stack them at random. A simple protocol is enough.

1. Choose a reproducible test scene: the section that stutters, reached in under a minute. A save state just before will do for that single purpose.
2. Change one setting only, by one notch.
3. Play ten minutes, not thirty seconds: the effects of an overclock show up late, and heating changes the behaviour.
4. If it works, save for that game only: core options on one side, configuration override on the other.
5. Write it down: a text file on the microSD card, one line per game, title, core, settings, date.
6. If in doubt, go back to clean: Reset Core Options and Unload Override.

One last marker: many problems blamed on settings come from elsewhere — an incomplete file, an unsuitable core, a worn-out microSD card. Before spending the evening on it, go through our common causes of a game that won't launch. And if you keep running into the power ceiling, the problem is in the emulation tier you are aiming at, not in the configuration: our retro handheld consoles are sorted by emulated system, each with the state it ships in, ready to play or ready to configure.