* add keyboard recording support to bsv
BSV movies recorded in older RA *WILL NOT* replay properly after this
patch. While looking to see if the core actually uses a keyboard
device could mitigate this, it is an unavoidable consequence of using
BSV, a format which carries no metadata whatsoever.
* Fix for loop declarations and some whitespace
---------
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>
* Add bsv to emscripten builds
BSV has no external dependencies so this addition should be fine.
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>
* Don't start video recording when BSV recording starts
* Don't double-record inputs in BSV recording
- Will this work properly with the part of input handling outside of
input_state_wrap? Who knows?
Co-authored-by: Joseph C. Osborn <jcoa2018@pomona.edu>
When running on Android, RetroArch considers most devices that emit dpad events as gamepads, even if they also emit other keyboard events; this is usually the right thing to do, but it has the side effect of not letting some actual keyboards (e.g.: Logitech K480) act as such inside RetroArch. This configuration option allows users to manually select a specific input device to act as a physical keyboard instead of a gamepad, which is handy when emulating computers as opposed to consoles.
- Fix analog drift blocking touch input (could occur on overlay_next if physical inputs shown on overlay)
- Fix overlay_next buttons lighting up in unison
- Skip meta keys in input_overlay_add_inputs (not supported by input_state_internal)
