Emulator

I've considered this many times, but always convinced myself that it wouldn't be wanted before discussing it.

Potential issues:
FAT: there is a maximum of 127 files on a memcard which could be reached even with a single game (extreme case timesplitters save + 126 profiles)

block limit: not sure if this is likely, but only 2043 files are available at most.

tracking modified saves would be fairly simple, using either a write through or write back when a block is modified.

One thought to eliminate FAT/block limits would be to only place files with the same gamecode on the virtual memcard, most games would work great with this,
the only game that I am aware of that looks at other saves is SSBM (pikmin trophy is save is on memcard)

also, how to deal with memcard A/B, were you thinking two separate folders?

the only game that I am aware of that looks at other saves is SSBM (pikmin trophy is save is on memcard)

Also MGS, with the famous Psycho Mantis boss fight in which the boss comments on the games you've played :)

also, how to deal with memcard A/B, were you thinking two separate folders?

Yeah, two separate folders is probably the best option. Same thing for regions. Basically, replace each of our current .raw blobs by a directory.

I think we could simply refuse to load if there is not enough space on the virtual memcard. It should never happen unless a user starts putting files in the directory himself (games would detect that error condition).

I prefer using separate 512KB memcards per game. They're small enough to throw around, can quickly be increased to larger sizes and easily written to a real card, if necessary.

that would be simpler to do, but how would you propose to handle the (small) number of games that use more than 59 blocks?

If we do that it might be better to still have a GCI per game, and generate the memcards on the fly. GCIs are much better for most users (easily manipulable with other tools).

That still doesn't address the issue of games looking at saves for other games (MGS, SSBM, I know ToS2 (Wii) also looks at ToS1 (GC) saves, etc.).

In my experience .GCIs suck. Most tools meant to deal with them crash regularly (including dolphin) either due to bugs or "non standard" GCI+lack of sanity checking, and they're a pain in the ass to get onto a real memory card (especially if somebody gives an sjis GCI) compared to a raw dump that can just be directly written (with the card id patching handled automatically by GCMM).

With regards to games accessing saves that aren't their own, I thought the SDK allows them to access any saves with the same company/maker ID. Wii games do the same thing by using the current ISFS GID (which matches the maker code). But it looks like this isn't the case for MGS, since its maker code is A4 while nintendo's is 01.

I'm for this change, I think it'd be an improvement if you could support both. That's just my opinion, though.

The reason I like this change is that it makes handling saves easier, I can easily transfer saves to other people without tools. I don't know anything about the technical complications or how games will react to it, I just like it theoretically.

branch memcard_directory is a start to this. seems to work with all games that I've tested with

Do you think it's stable enough to ask people to test it as it is? I can create a forum thread if you don't want to do it.

What about the migration path for this feature? I think we want this enabled by default, so we probably need to not "lose" everyone's saves. Is there a timestamp that we could use in each memcard file? If there is, we could maybe use the most recent saves from + ...

there is a timestamp that shows when it was last modified, but for migration I was thinking that on first use it takes the saves from the default memcard
something that could happen if the directory doesn't exists

it is stable enough for testing, but I neglected to bump the state version so maybe I should push that before having people test.

The code currently assumes a nonfragmented memorycard.
if the user were to use the IPL to move/delete saves and then continue on to play a game without stopping, fragmentation may occur
I plan on addressing this shortly

also there is the matter of deletion. if a save is deleted by the game/ipl/sysmenu currently it does nothing, I plan on having it delete the gci from the system when this occurs, unless there is a reason to ignore this action

Maybe rename it to .gci.deleted or something like that? Just to make
sure, I don't think there's any reason to not delete the deleted saves
but we're never too sure.

as of latest commit to the branch it should be stable enough for widespread testing.
the save path is currently hardcoded to be relative to the User dir,
should we allow user to specify the directory?

I would like to request a code review so that I can fix any problems caught by that and merge to master.
I got a little outside testing from the forum post, not as much as I'd like, but from my own testing I believe it is working properly

Good Job LPFaint! Merged as of Dolphin 4.0-1939.

4.0-1939 -> https://dolphin-emu.org/download/dev/01fc1a6c5452f26ddac80742776026bd659b6db0/