Always be recording a movie

No more will you say "Wish I got that on tape!" (or more likely "Wish I could reproduce that!")

Blocked by:

• #2522 and other general sloppiness in the frontend
• #2976 (need to put non-inputlog things in movie files somewhere)
• special cases everywhere for NullHawk, probably

Doing this would also enable what I'm calling a "time-tree" model for SaveRAM and savestates, where casual play essentially behaves like TAStudio w.r.t. rewinding, but with the possibility of also autosaving every "leaf" in the "time tree" i.e. true un-loadstate. Such a model would necessarily give each tree and branch some sort of identifier, resolving #2175, #2437, and #2484. (TAS Editor appears to have a similar model for its branches? #568 Why was that not copied in TAStudio to begin with?)

Always recording would mean current behaviour of some cores w.r.t. mandating BIOS for recording would need to change. See #3763.

An open question is what to do about DeterministicEmulation (which I'd like to rename) when EmuHawk is always recording. Maybe it could be a frontend setting, but then movies made with it disabled (InaccPerfHacksAllowed = true) may not play back correctly. Maybe always recording could be a frontend setting, and the user has to directly choose between it and performance hacks.

adelikat says:

InputLog class (as compared to Movie class)

The input log object will be a fast and minimal movie implementation. The idea is that underneath the hood, bizhawk could always be recording. This log would be saved into a specific place. It would always be going unless the user is officially recording a movie. The key is that it has to be fast and not be a drain on resources, since a user could be playing literally for days. It must not get in the way of the casual user experience.

backup movie bool - false always
istext = false (always binary movies)
if guid doesn't match - off
checktimelines - off
int maxframes - if exceeds then increment file name, add a savestate to new movie, and start logging
--this will need logic for loading a state before this new movie, it should know how to go back to a previous movie

Start by reading the mentioned InputLog and Movie classes and the EmuHawk frontend behavior; review blockers #2522, #2976, and #3763 first. Done would require a decided design and an implementation that records continuously without harming casual use, including the stated rollover and prior-movie/state behavior.