During the making of a TAS, a large tree of possible inputs is explored, but in the end only one path through that tree is retained as the input movie. The other inputs are currently irrevocably lost, with the only trace of them being the rerecord count. While the final TAS is definitely the most interesting branch of that tree a-priori, I still think it is a bit tragical that all the rest is discarded. Here are some examples of what could be done if the full set of inputs were available:
"Many Worlds"-type videos like this one:
Link to video
Showing the rerecord density as a function of time, identifying which regions are the most challenging/optimized
Finding the average length of each rerecord
Documenting what other approaches where tried, not just the number of things tried
Recover lost input in the case of a mistaken loadstate during recording mode
I've discussed this previously with Ilari, but we always ended up with rather complicated setups. This time I have a suggestion which I hope is simple enough that it will be trivial to include it in rerecording emulators: The full history movie is simply a normal movie file which is never truncated. Instead, every time a loadstate happens, a token indicating the frame the loadstate jumped to is inserted. That's it. A simple way of implementing this is:
Every time a new movie "a.lsmv" is created, also create another file, "a.lsmv.hist" say, for the full history, and initialize it the same way as normal.
When an existing movie is loaded, look for a corresponding history file, and open it for appending too.
Every time input would be added the normal movie, also add it to the full history file.
Every time the normal movie would be truncated, add a loadstate token to the history file, but do not truncate it.
I added this to my own copy of snes9x, and it only required a few lines of code spread over 3 functions in a single file, so pretty simple. Hopefully it will be as simple for other emulators. For the loadstate token, I used a frame with FEFF as input for player one, follwed by a 4 byte number indicating the frame of the state that was loaded, but this will change from format to format. The resulting file will be a few times larger than a normal movie, but will still be a small file.
Of course, for this to be useful for more than just the TASer himself, it should be possible (dare I say encouraged) to submit the history files together with the normal movie file when submitting a TAS to tasvideos.
Joined: 10/12/2011
Posts: 6435
Location: The land down under.
I know you do this, but just asking Like this topic? Also if someone actually does this on tasvideos PLEASE MAKE A TUTORIAL the written one makes me stuck...
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
This isn't the same as the TAS comparison stuff. That one compares one TAS against another. With the full history stuff, you would be able to compare one TAS against all the stuff that was recorded over in the same TAS. I think the video above shows that quite nicely, but imagine that when TASing Sonic or something, you're not sure if jumping on an enemy or rolling through it will be fastest, so you try both. In the normal movie file, you will only be able to see the alternative that turned out to be fastest, but with a full history movie, you would be able to see both. It would be a bit like a "making of" movie or a "bloopers" movie.
Are you trying to make a comparison video, but find the instructions too difficult? Where are you getting stuck?
This is an amazing idea and I hope it makes it into mainline BizHawk ASAP.
One thing I don't quite understand is if playback works out of the box: if I take the .hist you describe and run it in snes9x, do I get to watch the full TAS process? It seems unlikely - I don't really know what the "FEFF as input for player one" thing is doing, but it doesn't sound like something that snes9x would play back in the desired manner. So while all the input could be recovered by a dedicated researcher, it seems like there would be some more dev work needed to make it truly awesome for the everyday-TASer/viewer, no?
One really great thing that I can see coming from this is behind-the-scenes reels - edited encodes of the history file showing highlights of particularly frustrating sections that tried many times, or neat strats that almost worked, or humorous accidents/glitches that didn't make it into the final run. That sort of thing could add a lot of value to a TAS.
A warb degombs the brangy. Your gitch zanks and leils the warb.
This is an amazing idea and I hope it makes it into mainline BizHawk ASAP.
Thanks, I'm glad you like it!
Personman wrote:
One thing I don't quite understand is if playback works out of the box: if I take the .hist you describe and run it in snes9x, do I get to watch the full TAS process? It seems unlikely - I don't really know what the "FEFF as input for player one" thing is doing, but it doesn't sound like something that snes9x would play back in the desired manner. So while all the input could be recovered by a dedicated researcher, it seems like there would be some more dev work needed to make it truly awesome for the everyday-TASer/viewer, no?
You're right that the proposal above only includes recording, not playback.
That doesn't mean that playback needs to be hard, though. The simplest way of adding playback support is simply to scan through the .hist file once, looking for loadstate markers, and making a list of which frames need to be loadstate-able. Then run through it again, making savestates when reaching those states, which can then be loadstated when a loadstate marker is encountered.
This implementation is not the most efficient, though, as it stores more concurrent savestates on disk at the same time than needed, and savestates are relatively large. A more intelligent approach would delete savestates after they are no longer needed.
But the main point of this proposal was to make something super-simple to implement that still contains all the necessary information. Once that is in place, it can be expanded on to make it into some awesome multi-track non-linear editing system or something, but requiring that from the beginning would reduce the chances of having it implemented in emulators, I think.
jlun2 wrote:
How would this work for runs that might get heavily botted, causing it to have hundreds of thousands of rerecords?
For 100000 rerecords of average length 1000 frames, such a file would contain 100,000,000 input records, and be about 200-500 MB large uncompressed. That is starting to be relatively large, but still manageable.
But there should probably be an option for avoiding this. One simple way would be a checkbox to disable full history recording when starting a movie. Another, more flexible option would be to make use of the emulua savestate option for indicating that a loadstate should not count towards the rerecord count. It would be easy to make the full-history behave like a normal movie (i.e. truncate on loadstate) when that flag is set.
