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.
assignments for strings longer than 2 chars
- Use strlcpy concatenation instead of strlcat
- Make sure that what remains of iteration of the '_len' variable
for manual char assignment
is done in a safer way so mistakes are less possible
* 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?
* change bsv file suffix to replay, update strings
* add trivial RPLY block to save states
* WIP rerecording support, doesn't load states properly yet--issue with checking identifiers?
* Fixed a type error to get time identifiers working right, ready for testing
* handle case where state without replay data is loaded during replay
* cleanups
* whitespace cleanup
* Cleanups, change replay file format magic, fix logic around future states
* Remove failed future message
* Add play-replay-from-slot command, fix load-state-from-slot to use given slot
* build fixes
* Fix race conditions in emscripten build and incorrect replay state incrementing
* Style fix for single line if
---------
Co-authored-by: Joseph C. Osborn <jcoa2018@pomona.edu>
* 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>
if condition variable is signaled, the loop is ran another
last time so we can do a final check/save before stopping the thread.
Old commit courtesy of tobiasjakobi
(snprintf) Try to reduce or simplify snprintf calls, only tend to
use it for processing integers/numbers and avoid it for regular
string concatenation (NOTE: we try to be a bit safer about it to
address earlier cited criticism, although we don't consider concatenating
3 or 4 characters at the end to be insecure)
(msg_hash_to_str) Try to avoid duplicate calls to the same localized
string when we can just cache the results once instead locally
Daniel Byon
David G. F
Joe Osborn
sonninnos
libretroadmin
warmenhoven
Joe Osborn
LibretroAdmin