Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync savegames with SAF #552

Closed

Conversation

newhinton
Copy link

@newhinton newhinton commented Sep 14, 2022

This allows the user to use arbitrary locations for savegames. It uses the internal folder as a "working directory", copying files from and to selected external storage if choosen. The file with the last modification timestamp ALWAYS wins this sync.

This can replace the custom google-drive implementation. It is always called when SRAM is saved. It only copies the current game.

Todo:

  • Add all cores
  • Find out what a .dsv file is
  • Find out which cores use the sram-function
  • Make the sram-function with above cores

@newhinton
Copy link
Author

I would also like to add a folder inside the savegame folder, so that we seperate consoles. Is this a feature you'd like?

@Swordfish90
Copy link
Owner

If I'm not mistaken, this implementation only works with save files which are directly generated by Lemuroid, and not for ones which are generated by cores (such as PPSSPP, MelonDS, Citra and more).

There, we basically have no control on how/when the files are accessed, that's why I still believe that a full double-sync between the two folder (or completing the work for Libretro VFS) is the only option in these cores.

@newhinton
Copy link
Author

Ah now i see what you mean.

This is only partially an issue, albeit this code needs adapting.

While cores that use sram are fine, the others currently do not get updated as you stated. Though, they still get written to internal storage and can therefore be copied to saf. I just need to adapt the copy functions so that they can be called without the sram sync.

This should lead to every core behaving roughly the same, saves are written to SAF when lemuroid calls either the 'exit'-game callback or onPause. I think this is the best possible without the callback-function i linked to in the other thread

I will give it a try tomorrow

@Swordfish90
Copy link
Owner

I'd not put the full duplex sync in the onPause. The best option would be to have it in a WorkManager job so that it's not interrupted and the user would not be able to launch games while the save sync to external directory is in progress (we can potentially trigger this job whenever a game is closed like we do with the cache cleanup job).

I'm available to discuss ideas if you want a quick check before diving into code in order to avoid implementations which can't be merged.

@newhinton
Copy link
Author

full duplex sync

It's not full duplex sync. Basically the internal storage is 'just' a temporary folder that doesn't get cleaned. Everytime a game is started, the corresponding savefile is copied from SAF to internal storage (if available), then the game can use it. When the game is closed, it gets copied from internal storage to SAF, overwriting what's there. (Except when the SAF-version is newer). It only 'syncs' on demand, only the game that is started, everything else is ignored

This way we dont have to change the 'core'-mechanisms at all, they work the same as before.

onPause

I am not sure why onPause should not be used. Everything that happens there should not be visible to the user anyway, and saving is asynchronous anyway, isnt it?

@newhinton
Copy link
Author

I have now separated the copy process from the sram usage. It can now copy arbitrary savegames before the game starts & after a game exits or pauses.

It is currently only configured for gba&nds games, because i dont know which fileendings the other cores would use. This is however very easily added

@newhinton newhinton mentioned this pull request Apr 9, 2023
8 tasks
@newhinton
Copy link
Author

Closing in favor of #632

@newhinton newhinton closed this Apr 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants