[FEATURE request] Capability to load a savestate through command line and to change save state folder

[Tartifless]

Hello,

One of my numerous feature requests !

Currently save state files are saved directly in the folder where the game is located, this can lead to an increasing size in the user roms folder, having the ability to set the path in the settings file would be great.

Also, it would be nice being able to load a save state file via command line argument, for example by specifying -savestate 0 (for slot 0), this would directly load the game with the savestate located in slot 0.

Thanks for consideration

[jsgroth]

Making the save file & save state path configurable is doable. I could also add an option to persist saves into the user's local data dir if that would be simpler (would be %LocalAppData%\jgenesis\ on Windows and $HOME/.local/share/jgenesis/ on Linux).

To clarify re: loading a save state at launch, this is for the CLI? Doing this for the CLI is straightforward, for the GUI a little less so.

[Tartifless]

Hello,

I'd rather have the savstates in the emulator folder or in a configurable path than in appdata or user documents.

The load through cli could be for both, currently it's already possible to load a game through cli with the gui version (from what i tested gui and cli work with the same arguments...).

But cli can be enough if too difficult to implement in the gui version.

The objective is really to launch a savestate from a frontend...

[jsgroth]

c33fea4 adds a --load-save-state <SLOT> arg to the CLI that will attempt to load the specified save state slot during startup. If it fails for any reason (file doesn't exist, invalid format, etc) then the game will boot normally with a "failed to load state" message.

Adding it to the GUI isn't difficult exactly, but the GUI path for loading directly into a game is kind of a hack and it doesn't pass through any command-line args other than the file path. I'm not planning to remove that code path or anything, but for things like command-line launch flags I'd prefer to only support them in the CLI unless you really need to have the GUI window open in the background.

[Tartifless]

Oh, i currently use -f and --hardware with the gui, seemed to be working.

[jsgroth]

Huh, are you sure you're using the GUI executable? The GUI should fail with an error if you give it --hardware, e.g.:

error: unexpected argument '--hardware' found

Usage: jgenesis-gui <--config <CONFIG_PATH>|--file-path <STARTUP_FILE_PATH>>

For more information, try '--help'.

That's on the v0.8.0 tag

[Tartifless]

Indeed, i don't pass hardware, but I pass -f

[jsgroth]

As of https://github.com/jsgroth/jgenesis/actions/runs/11111856608 I've added 3 configuration options for the save paths:

• Same folder as ROM (current behavior), config option RomFolder
• Same folder as emulator (will create saves and states subdirectories), config option EmulatorFolder
• Custom path, config option Custom with an additional config field for the path

The save file and save state paths can be configured separately if desired, since the native game save files are significantly smaller (usually only 8KB, rarely more than 64KB outside of Sega CD w/ the 128KB RAM cartridge)

One thing to note is that when using the emulator folder or custom path options, the emulator will create a separate nested subdirectory for each console in order to avoid potential name collisions for the same game on different consoles. Not something that I think the average user was likely to run into but it was something I ran into during testing.

If this works ok then I'll probably publish a release soon-ish because while testing this I found and fixed a pre-existing major bug related to Sega CD save states on Windows.

[Tartifless]

That's great, i have lots of work currently but will try this over the weekend

[jsgroth]

Regarding something I said earlier:

for things like command-line launch flags I'd prefer to only support them in the CLI unless you really need to have the GUI window open in the background.

After thinking about it more I've changed my mind on this. The CLI doesn't support any way to change options while a game is running, so there's benefit to having the GUI available in the background even if most people won't touch it. I went ahead and added the --load-save-state <SLOT> arg to the GUI executable as well, although in the GUI it only has any effect if the -f arg is also used.

I've also just added a new config field load_recent_state_at_launch that, if set, makes the emulator always attempt to load the most recently saved state at launch when starting a game. I'm not sure if that's useful for a frontend but it seemed like a useful feature to have in general.

[Tartifless]

Hello,

Yes this can be useful, other emulators have this feature as "autoload", it's usually coupled with an "autosave" feature, that automatically saves current progress when exiting the emulator.

[jsgroth]

Makes sense - I looked at how a few other emulators do autosave/autoload and it looks like they use the same save state mechanism as normal save states, but they store the autosave in a separate file instead of using the normal save state slots. I may add that in the future.

I just published a v0.8.1 release with all of the changes I mentioned in previous comments. Feel free to open another issue if other changes/features are needed.

[Tartifless]

Noted, thanks, i'll download the latest 0.8.1 and try it all