Open Spegs21 opened 1 year ago
I don't think 2GB is asking a lot
That's if it's only 2GB though. Think having several save states for the same game and/or multiple games (having just one would be pretty limiting after all). In such cases you would run out of storage pretty quickly.
Sure, multiple 2GB save states will add-up but the burden of managing storage is on the user. Compression could further reduce the storage requirements. It won't be fast but it'll be faster than repeating something multiple times because of a poor save system. TP: HD is a good example of this. Sure they have Ooccoo but it's doesn't really put you right back where you were.
My use case of save states is to work around issues like this so I'd only need one per game, if it was problematic. I wouldn't be saving an additional state every few minutes, I'd use the same one occasionally. I'm sure other people have other uses cases. I just don't think this should be precluded because we don't trust the user to manage storage. Is that really our concern?
The reason we don't have save states yet isn't so much the size and loading times but just the sheer quantity of busy work it is to implement them. Also, any change to any system in Cemu that holds some kind of dynamic runtime information (and there are a lot, it's an HLE emulator after all) would invalidate previous save states if no backwards compatibility code is added. So save states would put a substantial maintainability burden on the whole codebase. That said, the code is pretty stable and doesn't change often anymore.
It's one of the most common feature requests after all. If you decided to spearhead it, it would be appreciated by many :)
Last year someone already started work on it but dropped it pretty quickly. Their repo is here if you want to check it out as a reference.
Off the top of my head what needs to be stored:
OSThread_t
struct)It would also make sense to have pause&resume emulation feature implemented first since it is necessary to bring the machine into a well known paused state before creating a save state.
Thanks for the detailed explanation and reference @Exzap. I figured there was more too it. I don't have a lot of experience with C++ in OSes but if it's something you'd consider busy work I can probably figure it out.
If you get a few minutes can you look at what he's done and comment on what he might be missing? It seems like he has a partial implementation working.
Also, any change to any system in Cemu that holds some kind of dynamic runtime information (and there are a lot, it's an HLE emulator after all) would invalidate previous save states if no backwards compatibility code is added. So save states would put a substantial maintainability burden on the whole codebase.
Regarding this, personally I think it's fine to keep save state incompatible between different versions considering the temporary nature of save state.
You can just add a warning popup message saying this (toggled by checking the save state directory). PCSX2 already does this:
https://github.com/PCSX2/pcsx2/blob/7fd82fffabfb3eb6479f1d11cec9fa0081fee805/pcsx2/GS/GSState.cpp#L2634-L2638 https://github.com/PCSX2/pcsx2/blob/7fd82fffabfb3eb6479f1d11cec9fa0081fee805/pcsx2-qt/AutoUpdaterDialog.cpp#L408-L415
Example UI:
any news on this? save states would be an awesome addition to this wonderful emulator, while it may require some work I hope we can achieve this (I wish I knew how to code, It seems very hard, so I understand the delay in this feature, Lets just hope we can get save states in the future!
This has been asked about before here and it was mentioned that it wasn't feasible due to the storage space required but with some modern games taking well over 150GB on the same systems people run this emulator, I don't think 2GB is asking a lot. There is already an option to dump the RAM in the debug menu, laying some of the ground work for this.
I'm willing to work on this personally but had a question about the implementation.
Is it as easy as saving the memory contents, register values, and next instruction address to be loaded back in or is there more to the machine state that is needed?