* Less string copies
* Some general cleanups
* Add extra param to runloop_message_queue_push so we can pass size_t
of the message
* Consistent conventions for local variable usage for certain things
- replays now start each frame with the number of key events (8 bit
unsigned int, then key events) and the number of input events (16 bit
unsigned int, then the input events)
- this makes it possible to parse replay files without any core
loaded, and makes replays more portable if cores change their polling
strategies
- external tools can now parse replay files
- old (vsn 0) replays will still play back, but new (vsn 1) replays
will not play on old RA
- replay files grow faster now, with each input poll now taking 8
bytes instead of 2
* Enqueue replay record/playback until next frame
This fixes a bug where stdin commands activated via polling would
trigger replay record/playback in the middle of a frame, then input
checking would pull from them before the next frame came around---it
only makes sense to change the active replay in between frames, not
during them.
* fix comment syntax
* 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>
* Add bsv replay controls (not yet fully implemented), remove toggle
see notes in task_movie.c, make sure command.c calls the right
functions, check retroarch.c and other todos.
bsv files are also now stored with states, not saves.
* Compilation fixes
* Added command impls for play and record replay, and some code in load state to do the right thing there
* Guard some parts of the new code with HAVE_BSV_MOVIE
* wip, menu fixes
* more menu fixes, osd for movie errors, halt recording properly
* Menu and label fixes
* move bsvs to own file suffix series under savestates, fix recording and playback command validity checks
* Fix replay autoincrement
* fix endif placement, whoops
---------
Co-authored-by: Joseph C. Osborn <jcoa2018@pomona.edu>
This relaxes a warning about save state sizes for cores like
dosbox-pure that don't report accurate save state sizes.
Before, the warning would be issued and the state would not be loaded;
now, the warning is issued and the state is loaded anyway.
Co-authored-by: Joseph C. Osborn <jcoa2018@pomona.edu>
* BSV ergonomics improvements
- Date stamp toggled recordings instead of overwriting or using save
slot number
- Properly stop movie on playback EOF; also pause emulation
- Add recording flag to match playback flag in bsv state enum
- Rename bsv "movie path" to "movie auto path" to clarify role
- Allow stopping movie playback before EOF using record toggle hotkey
---------
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>
