mirror of
https://github.com/libretro/opera-libretro.git
synced 2026-11-07 04:25:58 -10:00
LibretroAdmin
54fe4f3754
A state stored the whole 22 MB DRAM allocation -- sized for the
largest memory configuration and the high-resolution VRAM copies --
plus both ROMs, whatever the game used, and the DSP's 70 KB of decode
tables. V4 keeps everything else as it was and changes two chunks:
- MEM2 replaces MEM. It holds the memory configuration, then only the
RAM that configuration uses (DRAM, VRAM and VRAM's three high-
resolution copies), then NVRAM. The copies are kept whether or not
high resolution is on, because it can be switched mid-game and the
state size must not change under a frontend that sized its buffers
once; the configuration itself is fixed for a session. The ROMs are
left out: they are the BIOS and font loaded for the session and
never change. For the stock 2 MB/1 MB configuration that is 6 MB of
RAM instead of 22 MB, and 2 MB of ROM gone.
- DSP2 replaces DSPP. INSTTRAS, REGCONV and BRCONDTAB are decode tables
opera_dsp_init() builds and nothing changes, so they are not stored;
a load keeps the running core's.
V3 states still load: MEM and DSPP are still read, and the tables a
DSPP chunk carries are stepped over. A core without this change
refuses a V4 state as an unknown version.
Measured with a libretro driver, stock configuration, together with
the array I/O change before this:
size serialize unserialize
before 25550222 3.8 ms 4.2 ms
V4 6605970 0.5 ms 0.6 ms
Checked: a V3 state saved by the previous core loads and plays the
next 240 frames with audio and video identical to the original run; a
V4 state does the same; save-load-save is byte-identical; a replay of
60 frames from a loaded state matches; a sweep flipping 9721 bytes
never lets a refused load change the running state; and the changed
files build big-endian (PowerPC).