Lime-3DS-Emulator
Lime-3DS-Emulator copied to clipboard
Add quick save functionality
This adds a hotkey for quicksaving and quickloading. Each item will show a toast after invoking. They use a saveslot 11.
I also refactored the saves-popup-menu a bit. Loading also closes the drawer now. Saving&Loading from the drawer will also show a toast.
There is one thing not working:
While i can save&load just fine, the 11. state does not show up in the menu. Does this require a change to the core?
It is possible to reuse one of the existing slots as quicksave&load, but that might be bad for users that have existing saves in those slots.
If this feature is to be added, it must exist in both the desktop and android versions of the emulator.
I will convert this PR to a draft. If you wish to continue to develop this feature, implement it for the desktop version and mark it ready for review. If you don't, feel free to close it.
If this feature is to be added, it must exist in both the desktop and android versions of the emulator.
That is reasonable. I will take a look if i can implement it there too.
However, how should we deal with the slot-allocation? At the moment slots 1 - 10 are used for normal saves. Usually i'd allocate the first to be the "special" quicksave, and start with the normal slots after that. However, since that wasn't done from the start, now i have to append that quicksave slot in the 11th. slot. This makes allocating more slots rather hard.
The two (reasonable) options i see:
- make slot 11 the quicksave slot
- make slot 1 the quicksave slot, and warn the user about it.
How would you deal with that? Is it maybe possible to create a quicksave slot in the core, outside the "normal" slots?
My recommended course of action would be to put the quicksave in slot 0 and simply change the save state code to allow this to happen. I have looked at the code and this doesn't seem that difficult
@OpenSauce04 I have now fixed the technical problems with this feature.
However, i looked at the code and i am not confident that i will be able to implement this feature on the desktop client. I have no experience with qt ui files, and my c++ is also not that great. I am also not familiar with the core itself.
Could you take a look at the desktop-side?
I currently have other priorities, so this will take a while to get to.
Sure, no pressure.
Though, since the frontends aren't equal feature wise, wouldn't it make sense to just merge this anyway to prevent long term merge issues?
I would prefer to avoid increasing feature parity.
I played around with this for a while this morning, checking out the branch and trying to add to desktop. Pretty sure I have it working, using save slot 0 for quick save. However, before I PR my changes into newhinton branch so they can merged into this PR, some questions.
(1) Desktop already has "save to oldest slot" and "load from newest slot" hotkeys. Obviously these work differently from quick save / quick load in that they reuse existing slots rather than having a special one for themselves, and so could theoretically overwrite intentionally created save states from earlier in the game, but I expect that most people are using these similarly. Do we actually want both options? Will that be confusing? Instead of (or in addition to) quick save, should we implement those hotkeys on the android side?
The current system works kind of like the "auto increment save states" feature in RetroArch, while the quick save feature would work more like the auto-save/auto-load feature in RetroArch (except not automatic, at least currently).
(2) Assuming we go forward with both, Should we set default hotkeys for quick save and quick load? Right now, ctrl+c is mapped to save to oldest slot and ctrl+v is mapped to load from newest slot. My instinct is that maybe we should not map anything to quick save / quick load by default, just have them in the menu and available for mapping.
I put a PR into newhinton's branch that implements this feature on desktop, if you decide to go forward with that. This is what the menus look like in the current iterations (after assigning a couple of hot keys for testing purposes)
Since this PR also got stale and the feature is mostly done, i decided to move your changes to my own PR
I am doing this because i don't have write access to Lime3DS/Lime3DS branches
If you still wish to contribute, open a PR on my fork
Thanks for your contributions, i hope you don't take this the wrong way