Auto savestate (and its optional thumbnail) is generated on core unload
(quit, netplay start, etc). This ends up using the task-queue, which in
many cases deadlocks and/or causes a crash due to its asynchronous
nature.
Given that this is a state that must be generated before quiting or
reloading the core, it makes no sense to use the task queue, it should
be a synchronous job like for instance SRAM saving.
This should fix#15248 (tested by @schmurtzm)
* Simplify autosave command function
* Simplify and split save and savestate logic
save.c contains "SRAM" saves and their logic, which uses no task/queue.
* Rewind during recording isn't visibly busted anymore but it doesn't rewind the replay properly during playback or record, inputs get clobbered; check frame pos/ptr stuff.
* Fix rewinding during movie recording and playback?
* Allow for both -e and -R to start a BSV file recording at a state
The key issue is that loading a state takes some time, and the BSV
recording shouldn't start until that's done.
The minimal patch for this would just be a change to runloop.c which
moves movie initialization after entry state loading, throwing in a
task_queue_wait(). This makes for some awkward repeated autoload OSD
messages and doesn't solve the underlying issue.
Most of this change puts BSV recording start/stop into tasks, like
saving and loading are tasks; this was important to centralize BSV
operations a bit more and is the first part of a refactoring towards
more robust input recording. The necessary wait is introduced in the
begin-recording callback.
Co-authored-by: Joseph C. Osborn <jcoa2018@pomona.edu>
* (3DS) Add bottom screen menu
-> User can save/load state on botom screen with thumbnail.
-> Call a save_state_to_file() when RAM state has data to write a disk.
-> If the bottom screen needs updating, swap the bottom framebuffers.
Add: SAVE/LODE STATE TO RAM
-> This is useful for devices with slow I/O
-> 3DS bottom save state use CMD_EVENT_SAVE_STATE_TO_RAM
-> 3DS bottom load state use CMD_EVENT_LOAD_STATE when RAM state has no data
-> 3DS bottom load state use CMD_EVENT_LOAD_STATE_FROM_RAM when RAM sate has data
* Rewrite path_get_state to retroarch_get_current_savestate_path
* Fix unterminated state_path
When failing to load content in the companion ui when HAVE_MENU is not
defined RetroArch will crash in just about every input and video driver.
Even if several sanity checks are added the dummy core will immediately
exit.
Now it will print that it failed to load the core in the companion ui
and reinit the dummy core to match the behavior with the null menu
driver.
are empty, when undoing fails and when undoing is successful.
Aside from some TODO/FIXME areas added by this fork, the features in the
fork are now complete.
