[garbear]

Retroarch saves the saves/save states next to the ROM

for example a SNES game

game name.sfc - ROM
game name.srm - SRAM Save
game name.state1 - Save States

One thing just noticed save stats are very big compared to even the roms
for example

This is a save state for a SNES rom, the rom is 512KB and its save state is game.state1 = 5883KB but zipped = 66KB
maybe in the future they can be compressed? it would save some hard drive space and a lot of space if you do lots of save states over time.

I personally dislike save states and SRAM being saved along side the roms.

+1

There should a default folder to use out of the box, user-configurable to be any folder the user wants, with saves stored in sub-folders organised by system name to keep save files for the same game on different systems separate from each other so there is no filename conflict. You wouldn't want your save state for Dig Dug on the Gameboy overwritten when you played Dig Dug for the Atari 2600.

This makes them more portable, more shareable, easier to manage etc.

Folder for system should be optional. You can always add _nes, _c64, _snes, _pcx to filenames

3 years ago, I did a retroplayer build that had a full-blown savestate manager. It was backed by a database, and supported 0-9 save slots, auto-save every 30 seconds, auto-save on exit, and manual saving. The savestate manager showed which of these types of savestate it was, the time it was created, a thumbnail, and also the total playtime up to that point. Savestates were named automatically, but could be renamed in the GUI.

Internally, savestates were stored in a folder under USERDATA in separate folders named after the libretro core (savestates aren't cross-compatible between cores). The filename was derived from the CRC of the ROM, so the saves followed the ROM even when it was relocated.

This works better than saving next to the ROMs because many locations aren't writeable (e.g. loading a ROM from within a zip) and the name would have to be appended with the full gameclient ID, e.g. game.libretro.snes9x-next, along with the other info (slot number, etc.) so filenames would quickly become unwieldy.

I dropped it from the code because the size of the RetroPlayer patch became too large for me to handle. Now, however, the code is in good enough shape that I can take on a project like this again. Is this something I should reintroduce?