-
Notifications
You must be signed in to change notification settings - Fork 381
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
Store hard drive diffs in some way #3951
Comments
Based on some offline discussions with @vadosnaprimer, I'm marking this as waterbox because that's the only place we see any immediate need for this. Suppose we have a waterbox core that uses a writable disk image. During initial load (before seal), it calls
with a many-megabyte file. That file then stays around for the entire life of the guest core, and the guest uses IO syscalls to write some data to the file, but probably doesn't overwrite every byte in the file. The requirements on waterbox are then:
|
Keep in mind the current wbx_mount_file with writable is bugged, possibly causing crashes with savestate usage. It hasn't been an actual issue since the use case it was intended for (DSi NAND) doesn't use it, instead just putting it all in memory and has some abstract file i/o core apis handling it instead of C file i/o apis (also particularly important since state size grows drastically). Also, the issue I had with this originally was less with waterbox details, but more with the idea that you want to create SaveRAM but without actually storing it in movies. This should not be done, SaveRAM should always be stored in movies. If something SaveRAM like is wanted without actually being SaveRAM per se, the core has the option to use the "User folder" (well, this is more a hack for Encore since it dumps NAND and shit there, perhaps this would be a good approach here). It could also possibly be some file sent as a "ROM" with multidisk bundler. |
Documenting a test case for Amiga.
This operation calls |
In cases when the game has to be installed onto a hard drive image, it may be legally iffy to allow freely sharing the movie file containing the diff as a SaveRAM anchor.
And it may be too huge to even upload to tasvideos (up to hundreds of MBs if we only take Amiga, but also some MAME games need installation, and if we ever emulate IBM PC then we're talking gigs).
My initial thought was to keep SaveRAM for those movies that depend on prior installation separately from the movie, and pull from disk as needed. There's some issue with it that I'd like CPP to explain.
But if diff is actually written to the file it applies to (as libTAS does it), that also sounds like a great solution, even tho ideally it'd be kept separately and applied on the fly in memory.
Also ideally there'd be a libTAS like option to not touch the file and to only keep the diff in memory, and to kill it once the game is closed, instead of flushing.
The text was updated successfully, but these errors were encountered: