Add / Improve libretro save files integration [$15]

[anothername99]

This bounty is about making the Reicast core be more in line with other cores regarding saving.

To complete this bounty:

• Make Reicast store its save files in the libretro savefiles directory.
• Add support for game-specific, rather than global, save files. This is supported by all the Beetle cores for instance and it makes a huge difference. Game-specific saves make organization easier and space becomes a non-issue.

Bountysource link: https://www.bountysource.com/issues/59499673-libretro-save-files-bounty

--- There is a **[$15 open bounty](https://www.bountysource.com/issues/59499673-add-improve-libretro-save-files-integration?utm_campaign=plugin&utm_content=tracker%2F500311&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F500311&utm_medium=issues&utm_source=github).

[skmp]

Hmm, first one seems rather easy. Second one has some harder questions -- how do we handle multi disk games and (avoid) rips with bad meta-info?

[skmp]

Could do per game-id saves, which should be mostly alright. Would need some way to notify the host app of the game id.

[anothername99]

In general I think it's a lot less messy if we name save files after the disc image's file name.

So basically:

Sonic Adventure.gdi <-- disc file name

The names of save files could then reflect this:

Sonic Adventure.a1.vmu Sonic Adventure.b1.vmu Sonic Adventure.c1.vmu Sonic Adventure.d1.vmu

Multi-disc games can be handled the same way, except we load an m3u file instead. Beetle PSX for instance has support for this. m3u files are plain text files with a format like this: Star Ocean 2 Disc 1.chd Star Ocean 2 Disc 2.chd

[baka0815]

But then accessing the "memory card" via BIOS would no longer be possible, right? Or am I missing something?

[AbandonedCart]

I feel like this obliterates the purpose of a VMU. Playstation and other consoles with memory cards treated them like a mobile device treats an sdcard. It is an external storage area where data is saved in blocks. It is quite possible that, given the fact there is only the "pause menu" VMU display, that the actual functionality is overlooked. A single VMU file is meant to be treated no different than a ROM file. Dicing them up into collections of save blocks would eliminate any further development of the VMU.

(See below)

[anothername99]

I did overlook playing VMU games because you currently can't play VMU games in reicast-libretro at all. However, it could perhaps be handled by selecting a VMU mode when loading the Dreamcast game. A menu option, Load Content (Special), could perhaps be added to RetroArch, and in this case this option would lead to the VMU game being loaded instead of the main Dreamcast game. Since for example Chao Adventure is put on the VMU by Sonic Adventure, I think this design would make sense. However, it would be nice if @twinaphex could give us his opinion on such a solution.

This however is for VMU games originating from a Dreamcast game. For the purpose of running entirely separate VMU games that have no ties to any Dreamcast game, it would probably make more sense if the user moves the VMU file out of the save folder entirely and puts it in a ROM folder instead. Then the user can choose to load the VMU file in either a dedicated VMU emulator or in Reicast if Reicast supports that.

As for putting multiple VMU games on a single VMU, is this practical? Chao Adventure for instance takes up the majority of space on the VMU. I can see space becoming even more of an issue in this case and I would rather just put one VMU game on one VMU.

[anothername99]

@baka0815 In reicast-libretro, you still need to select a Dreamcast game in order to be able to access the BIOS menu, so this wouldn't change. I don't know how the BIOS is handled in standalone Reicast though.

[AbandonedCart]

@anothername99 (Blah Blah VMUs are a console in themselves Blah Blah Soul Calibur special edition VMU game that communicates with full game, but remains a separate item Blah)

Even without this project hosting a feature to act as VMU hardware, breaking it up still hinders portability as a VMU file for those that do. An array of various configuration options to get normal functionality just seems like it would add unnecessary confusion for the user.

Keep in mind that if you want to see something done differently in RetroArch, then you can submit it directly. Given the hierarchy that reicast is used as a core in that project, there is room for it to branch off and handle some things differently. @twinaphex may not be interested in VMU functionality, in which case the individualized saves are a more preferable solution.

As for the bounty aspect of it, it seems like this is a preference, since it doesn't actually address an issue that prevents expected functionality. Expected functionality is a "VMU unit" versus "save files"

[anothername99]

@LoungeKatt But in your example, the VMU game still originates from Soul Calibur, and Soul Calibur is the only Dreamcast game that you would expect your VMU game to influence. In that way, they are directly related, even though it's possible to play the VMU game while your Dreamcast is turned off. So in this case, playing Soul Calibur's VMU game is a side-feature of Soul Calibur, and I think it would make sense to treat it as such. Doing so makes the design simple.

If the user wants to play a VMU game that does not come from a Dreamcast game, say, a homebrew VMU game that they downloaded from the internet, that's quite a different use-case and I would suggest something more like a stand-alone VMU emulator for that.

Also, if a user doesn't like game-specific save files, it could be made optional.

[AbandonedCart]

I think trying to explain may be a lost cause, but making it an option to enable per game saves over optional to disable it would keep expected functionality without preventing the feature.

[AbandonedCart]

"Make Reicast store its save files in the libretro savefiles directory."

This is talking about submitting that separately to libretro as part of collecting the bounty, right?

[anothername99]

I don't know whether the team has plans to upstream the libretro port. If not, then it would have to be submitted separately to https://github.com/libretro/reicast-emulator. However, if a bounty hunter wants to do all the work except the libretro part, I could narrow the scope and exclude that.

[eadmaster]

instead of creating a separate MC file for every game, another solution would be implementing folder-based virtual MCs like PCSX2 and Dolphin.

[skmp]

@b10z wana take over this one?

[b10z]

@b10z wana take over this one? Sure! i'll take a look as soon as i am done with archives.