This means that we are now no longer touching files that haven't technically been written to. Some games use timestamp information to automatically highlight the save that was last written to, so this should fix a small but annoying bug where it would highlight the wrong one.
Do note that while there is a much simpler check that looks like this:
// Remove (== don't flush) all memory card pages that haven't actually changed.
for ( auto oldIt = m_oldDataCache.begin(); oldIt != m_oldDataCache.end(); ++oldIt ) {
auto newIt = m_cache.find( oldIt->first );
assert( newIt != m_cache.end() ); // if this isn't true something broke somewhere, the two maps should always contain the same pages
if ( memcmp( &oldIt->second.raw[0], &newIt->second.raw[0], PageSize ) == 0 ) {
m_cache.erase( newIt );
}
}
m_oldDataCache.clear();
It can fail in edge cases that don't actually seem too unlikely. Imagine a save being deleted, and then a new save from the same game but in a different slot being created quickly afterwards. It seems quite possible that the new save's file data then occupies the exact same pages as the old save's, and since it's from the same game it might be close enough to where a page sized section (juse 0x200 bytes!) matches the data from the old save that previously resided in that location -- which would cause this code to throw away and not flush this data! It's a shame too, since this variant would be a few ms faster as well, but I feel it's better to be safe than sorry here.
This mainly means that the superblock is now no longer written every single time the memory card is closed, but only when it's changed (which should be exactly once, when the memory card is formatted). It also means that you can format a memory card and then have the emulator crash later without having to reformat the card next time.
We're not actually deleting files though, we just rename them to prepend _pcsx2_deleted_, in case something breaks or whatever, so the user can in an emergency just restore the save by removing that part of the filename.
This eliminates prompts at the start of a game complaining about no
memory card being inserted.
I'm honestly not entirely sure if this is safe (is there some memory
card driver that could cache results between different executables?) but
if it isn't we'll see it soon enough!
* Reduce the amount of times path strings are constructed.
* Move file metadata writing to the file helper, which means it will only be written once per consecutive file access instead of on every file chunk.
This allows us to skip a bunch of accesses trying to find a matching file or memory location, presumably without actual consequences. This isn't really gonna change much in actual game use, but does speed up conversions of FileMemoryCards.
It was possible for an invalid (because never written to, so filled with 0xFF) file entry to be recognized as valid in GetFileEntryPointer(), which cascaded up to it flushing file data as fileEntryDict data and thus losing the relevant file data page.
Not sure if the other two entry accesses changed here are affected as well but better be safe than sorry, I suppose.
If you inserted a PSX memory card into a slot, then swapped that with a
PS2 one, the memory card manager still displayed that card as a PSX one
with "MBit" instead of "MiB" as the size unit. Fixed.
This reduces memory card initialization time.
Without this, it always indexes all files when the emulator boots, which
can take a few seconds if you have lots of files.
With this, the only file indexed is the PS2 "your system configuration"
file.
This has the side-effect of not being able to see save files in the PS2
BIOS unless you insert a game disc matching the files you want to see. I
don't think this is a big problem, but there should probably be a "don't
filter" option somewhere in case you want to manage files in the BIOS.
This informs PCSX2 which games want to access more than just their own save files so it can load them into the virtual folder memory card.
This includes:
- Multi-disc games which obviously need to access saves from the other disc(s).
- Games that allow importing data from prequels.
- Games that unlock bonuses if they find data from other games in the series, by the same developer, etc.
This is almost certainly not all games that would want to access other saves, but it should cover a lot them.
Essentially, I'm telling the memory card to re-index itself with a
filter based on the game's disc serial every time a new executable boots
in the emulator.
This currently works for a lot of games, but fails in edge cases where
the game disc's serial does not match the game serial that is written to
the memory card as part of the save file's directory name. This affects
mostly (only?) games that have multiple discs. We could circumvent this
by adding a "save game serial" or something into the GameDatabase which
tells us what we should filter by for those cases.
Apart from this edge case, this appears to work surprisingly well. Try
it and see if you can find other issues!
Jonathan Li