-
Notifications
You must be signed in to change notification settings - Fork 0
Save States
Oxide includes a ROM-specific save-state system with 3 slots per ROM.
Each ROM can use 3 save slots.
Slots are available through:
- top bar menus
- keyboard shortcuts
- debug terminal shortcuts
- explicit
.statefile loading
A save state stores:
- CPU state
- Display state
- Memory snapshot
- ROM identity information
- Slot metadata
Current save-state data structures include:
EmuSnapshotSaveStateMetaPersistedSaveState
Save states are stored under savestates/.
Folder names are derived from:
- sanitized ROM name
- stable FNV-1a hash of ROM bytes
Typical layout:
savestates/
└── <rom-name>-<rom-hash>/
├── <rom-name>_01_<timestamp>.state
├── <rom-name>_02_<timestamp>.state
└── <rom-name>_03_<timestamp>.state
When saving:
- Oxide verifies that a ROM is loaded
- runtime state is cloned into a snapshot
- metadata is generated
- the slot file is written to disk
- in-memory slot state is refreshed
- a status/overlay message is shown
Manual saves may ask for overwrite confirmation if the slot is already occupied.
Shortcut-triggered saves bypass the manual confirmation dialog.
When loading:
- Oxide checks whether the slot exists
- CPU and display state are restored
- memory is restored when valid
- runtime accumulators are reset
- emulation resumes from the restored state
Oxide can also load a save-state file directly from disk.
That path is separate from the in-memory slot cache and can be used even outside the top-bar slot menus.
When a ROM is loaded, Oxide scans the matching save-state directory and repopulates slot metadata automatically.
This ensures that save/load menus reflect current on-disk slot files.