@spleen1981
TLDR; I have savestates working for EJS core wasm build of scummvm.
retro-scumm has no savestates, in-game scummvm saves only.
want savestate code or pass?
========================
retro_serialize_size() returns 0 today, so the core reports no save-state support.
I've implemented it for the Emscripten/EmulatorJS port and it works — retro_serialize()/retro_unserialize() drive a real engine save/load into a reserved slot on the emu thread and copy that slot's bytes to and from the frontend buffer, with the deferred engines (SCUMM, SCI) handled.
Before offering it I'd rather ask whether you want it at all, because I can argue it either way.
Against: ScummVM is not a machine emulator and already has a save system that works on every platform, including here. A desktop RetroArch user gains nothing — my implementation is a wrapper around saveGameState(), so they'd get the same saves with less information. and all Scummvm saves for each game get packaged into savestate file. one file carries all saves for that game session.
For: frontends offer save-state buttons whenever a core is running, and on this core they currently do nothing.
My own motivation is frontend-shaped rather than general — ROMM's launcher and its sync are built around save states — so I'm wary of pushing a ~240 line feature upstream mainly because it suits my deployment.
If you would want it, I'd send the general mechanism only. One piece would stay in my fork regardless: I report refusals through a file the frontend reads, because RetroArch's OSD is not visible under EmulatorJS, and that is exactly the platform-specific kind of thing you flagged on #112.
if not, 'sall good
@spleen1981
TLDR; I have savestates working for EJS core wasm build of scummvm.
retro-scumm has no savestates, in-game scummvm saves only.
want savestate code or pass?
========================
retro_serialize_size() returns 0 today, so the core reports no save-state support.
I've implemented it for the Emscripten/EmulatorJS port and it works — retro_serialize()/retro_unserialize() drive a real engine save/load into a reserved slot on the emu thread and copy that slot's bytes to and from the frontend buffer, with the deferred engines (SCUMM, SCI) handled.
Before offering it I'd rather ask whether you want it at all, because I can argue it either way.
Against: ScummVM is not a machine emulator and already has a save system that works on every platform, including here. A desktop RetroArch user gains nothing — my implementation is a wrapper around saveGameState(), so they'd get the same saves with less information. and all Scummvm saves for each game get packaged into savestate file. one file carries all saves for that game session.
For: frontends offer save-state buttons whenever a core is running, and on this core they currently do nothing.
My own motivation is frontend-shaped rather than general — ROMM's launcher and its sync are built around save states — so I'm wary of pushing a ~240 line feature upstream mainly because it suits my deployment.
If you would want it, I'd send the general mechanism only. One piece would stay in my fork regardless: I report refusals through a file the frontend reads, because RetroArch's OSD is not visible under EmulatorJS, and that is exactly the platform-specific kind of thing you flagged on #112.
if not, 'sall good