* 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
* (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
Joe Osborn