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
TAS Editor appears to have a similar model for its branches? https://github.com/TASEmulators/BizHawk/issues/568 Why was that not copied in TAStudio to begin with?
- branch notes and reordering make them easy to organize in a comprehensive manner, which taseditor doesn't allow (to have branch text you have to have a marker with that text on the branch frame)
- tastudio allows more than 10 branches, so they would look super clobbered in a tree view
- it's hard to implement it to look nice (taseditor even has smooth animation)
- the ratio of usefulness to implementation effort made me close the issue
#4035 points out that after the end of a movie, inputs are not currently saved.
Overall, I would really appreciate a more robust input history, but it seems very ambitious. I guess a lot could be done incrementally as individual features, but for overhauling the basic functionality, a lot of care and testing would be needed to ensure reliability.
For me personally, I've learned to generally be very careful and I'm almost always recording a movie anyway, but 1) recording movies could be more convenient casually if you want to record a distinct movie every session, and 2) Visualizing every change made during a TAS could be cool.