Saves, states & backups

There are two different ways to preserve progress in an emulator: a normal save made by the game, and a save state made by the emulator. Both are useful, but they contain different information and have different compatibility expectations. A reliable setup uses the game’s save system and keeps separate backups, with states as an additional convenience.

Know which kind of file you are using

A filename or screenshot thumbnail alone is not enough to tell you what can safely be transferred. Keep the source application and export method with the backup, especially when moving between desktop and browser play.

Make a normal save and test persistence

1. Reach a point where the game offers its own save command.
2. Save through that in-game menu and wait for the operation to complete.
3. Close the game normally rather than terminating the application mid-write.
4. Launch the game again from the library.
5. Use the game’s Continue or Load option and verify the expected progress.

This confirms that progress survives a fresh launch. Loading a state immediately after saving does not test the same thing, because the state can restore a running context without following the game’s normal boot-and-load path.

If persistence fails, check the configured save location and whether the application can write there. Keep your library and saves in stable user-accessible locations. Do not assume that the folder containing the executable is always the active save directory.

Use states as snapshots of the running machine

The quick menu exposes Save State and Load State. Choose a test position, save it, advance a little and load it again. The running session returns to the captured machine state; later actions in that session are no longer the current timeline.

The reviewed core serializes much more than a position in the game. It records processor state, memory and multiple hardware components, along with format and game-identification information. It checks relevant compatibility data when loading. This is why a state can resume in the middle of an animation, but also why a state from another version is not automatically interchangeable.

Some state formats include cartridge savedata as additional information, and load flags determine how it is restored. Do not assume that every Load State operation leaves normal save memory untouched across all frontends and configurations. Preserve a separate copy of the normal save before testing old states or changing core versions.

Build a backup you can actually restore

A useful backup includes the normal save, the exact game revision or identifying details, and the emulator version. If you also keep states, label them with the build and configuration that created them. Date-stamped copies prevent a later experiment from silently replacing your only working save.

Close the running game before copying files so the backup is not competing with an active write. Use the emulator’s save-directory settings and the launcher’s Open GBAx Data Folder as starting points to locate configuration; a custom save directory may be elsewhere. Confirm the actual save path rather than guessing from an operating-system default.

Test restoration using a copy. Start the matching game and check progress through its own menu. Keep the original backup unchanged until the result is confirmed.

Move progress between desktop and browser

Prefer a normal game-save export as the first transfer attempt. Use the same game revision and region, and check the import format expected by the destination player. A compressed archive, a raw cartridge save and an emulator state are not interchangeable just because their filenames resemble one another.

1. Export or copy the normal save from the source environment.
2. Keep that original export in a separate backup folder.
3. Load the matching game in the destination environment.
4. Use the destination’s save-import controls with a copy.
5. Restart or reload the game as required by that player, then check its Continue/Load menu.

The current website does not synchronise saves with the desktop launcher. A successful import into one browser also does not create a cloud backup or copy it to another device.

Browser storage needs an export habit

The web player can keep data in browser-managed storage. That data belongs to the browser profile and site environment; it is not the same as a file you deliberately downloaded to a backup folder. Clearing site data, using another profile or private browsing, or losing that local browser data can interrupt continuity.

Use the player’s export/download controls regularly and verify that the resulting file is saved on your device. Keep the same catalogue/local-file route when testing whether stored progress is found: the current integration assigns game identities separately for catalogue entries and local files. Export/import is the explicit way to move between those contexts.

When a save does not load

First identify the file type and the game revision. Then record how the file was created and imported. If a state fails but the normal save works, the problem may be state compatibility rather than lost game progress. If a game reports corrupt data after a normal-save import, preserve the source file and compare format, size and revision before trying another conversion.

For the hardware model behind normal saves, read Cartridges, save memory & peripherals. For loading failures and installation issues, use Troubleshooting GBAx.