Here's a strange query.
Looking at a MP Echoes 100% run, but it's not 100% scan. 100% scan would be SLOW. Even with 100% scan, you can scan things without leaving room to actually read ... isn't it possible to pull off an actual scan with zero frames of displayed scan text, much less the multi-pages of text some scans give, and the information in the pause screen.
While all that might be a bit much--even in concept ahead--there are some interesting possibilities, like finding what's down a corridor or in a chest that's normally skipped, or showing off items not collected.
What about taking a TAS--any TAS, even existing TAS--and amending the video with inserted (muted) picture-in-picture (scaled down, composite--small frame but with the text expanded below/elsewhere--or side-by-side or the like, momentarily scaling the main TAS too) videos showing out-takes. Play-arounds, humorous failed attempts, or just filling in information.
Yes, that's a lot of work, recording extra video, chopping it up, and editing it all together without altering the continuous playback of the original. Everybody knows that. TAS are hard to begin with--it takes months to make a 20 minute video.
As to the actual end result, thoughts? Interesting? Boring? Ripe for abuse? (Oh yeah we could show one or two funny things... or constantly litter the video with loads of crap, which is probably what'll happen from time to time, mostly by other people messing with TAS runs they didn't do inserting junk that took very little effort).
I'm still waiting for emulator developers to create "meta-movies" that preserve savestate use. That way you could show an outtake reel in a TAS.
They wouldn't be submittable for publication, for obvious reasons, but they'd be a nice and efficient way to show off a series of tricks or glitches, if a movie file itself had the power to save and load savestates.
If a savestate takes some kilobytes of space, and in a typical TAS the author makes thousands of savestates, that would make a rather big file. Several tens of megabytes at least, I'd estimate.
Of course the vast majority of those savestates will consist mostly of repeated data (because the data probably doesn't change much between savestates.) The file would either have to be compressed, or the emulator would have to store only the changes between savestates (which could become complicated as the author jumps back and forth in the run...)
Compression of input sequences was only a problem when we needed to edit them. We never edit savestates, so there's no problem in storing them as tightly packed as feasible.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Compressing an individual savestate may lead to some space advantage, but my point was that since each savestate probably contains a lot of the same data as most other savestates (especially the ones close in time), the maximum compression would be achieved by compressing all the savestates as one single block.
If the entire movie file can be compressed, then this isn't a problem (eg. this is very easy to achieve with zlib), but if the keypresses ought to be uncompressed for easy editability, then it might become more problematic.
Joined: 4/17/2010
Posts: 11473
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
CtrlAltDestroy wrote:
I'm still waiting for emulator developers to create "meta-movies" that preserve savestate use. That way you could show an outtake reel in a TAS.
They wouldn't be submittable for publication, for obvious reasons, but they'd be a nice and efficient way to show off a series of tricks or glitches, if a movie file itself had the power to save and load savestates.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
If a savestate takes some kilobytes of space, and in a typical TAS the author makes thousands of savestates, that would make a rather big file. Several tens of megabytes at least, I'd estimate.
Of course the vast majority of those savestates will consist mostly of repeated data (because the data probably doesn't change much between savestates.) The file would either have to be compressed, or the emulator would have to store only the changes between savestates (which could become complicated as the author jumps back and forth in the run...)
A meta-movie would not necessarily have to contain any savestates by itself, unless the desired state is not already encountered in the movie. The meta-movie could command the emulator to take a savestate, then later command the emulator to rewind to that savestate.
Also, it would not have to show every savestate the TASer uses, but only those they wish to show. For instance, if the TASer wishes to showcase 3 possible strategies to beat a level, they might load states hundreds of times in playing through the level, but they would only have to command the meta-movie to rewind 2 times. So the final viewer will only see 2 rewinds, as the movie restarts the level twice to show all 3 different strategies.
You could just store the tree of input, rather than the tree of savestates. The savestates can all be reconstructed from that. (This is how the "undo loadstate" command in nethack-tas-tools is implemented.)
I do very much like the idea of a sort of side-commentary next to a TAS; it'd be similar in nature to an audio commentary, but allow you to show more details. It'd be a lot of work, but the end result would probably add to the entertainment.
Compressing an individual savestate may lead to some space advantage, but my point was that since each savestate probably contains a lot of the same data as most other savestates (especially the ones close in time), the maximum compression would be achieved by compressing all the savestates as one single block.
Actually, a bit faster (and a bit smaller file size) method would be to use delta compression followed by normal compression.
Random access is loads faster that way.
I compressed current Nethack WIP transcription savestates: 854,835,900 bytes in 87 files.
Git Delta compression: 14,189,052 bytes.
Concatenate and xz -9: 14,352,304 bytes.
Joined: 4/17/2010
Posts: 11473
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I love how people completely ignore the post where they're pointed to a movie that does contain input branches inside. And comments to frames the author chooses. And is quite small in size overall. It only lacks support for arbitrary slot amounts.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I think seeing this is interesting, but once in a lifetime is enough.
I don't understand, are these people actually using button presses?
Why is nobody writing a script with second/mS/frame timings (with second/mS converted to frames by absolute divisor, of course)? Plus auto-savestate, or savestate and then insert the savestate frame # into the file at a given point so it's aware of how it lines up and can auto-load the savestate to make amendments.
Isn't that a thing?
I love how people completely ignore the post where they're pointed to a movie that does contain input branches inside. And comments to frames the author chooses. And is quite small in size overall. It only lacks support for arbitrary slot amounts.
What I am suggesting is a replay file format that has the ability to save and load savestates while you are watching the movie. It is very different than what the fm3 files do.
Joined: 4/17/2010
Posts: 11473
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
CtrlAltDestroy wrote:
feos wrote:
I love how people completely ignore the post where they're pointed to a movie that does contain input branches inside. And comments to frames the author chooses. And is quite small in size overall. It only lacks support for arbitrary slot amounts.
What I am suggesting is a replay file format that has the ability to save and load savestates while you are watching the movie. It is very different than what the fm3 files do.
And it is very strange logically. In FM3 you can watch a movie, reach some savestate point, load an existing savestate, which contains different input branch, and watch the alternate route. You see how you reach savepoint by the Branch tree look. Or you can just JUMP to that point from later or earlier point and watch again.
I guess what you talk about is kinda prerecorded automation of actions, which are applied to the project itself. Like it can be done in Notepad++. But I can't see how this weird feature is critical in any situation. The only disadvantages in FM3 are the amount of slots and that you load them manually.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I understand the capabilities of a fm3 file. But I do not think you understand what the topic creator was asking.
The topic creator was discussing the idea of a "showcase run", something like advanced video commentary that shows you alternate routes or outtakes while you are watching the run, similar to how special features on a blu - ray movie work. The purpose is for entertainment and insight.
If you want to load outtakes manually you can already do that by creating a folder full of save state - based fm2 files, which would remove the branch limitation anyway. So I do not see how fm3 files are relevant to this conversation.
Yes, FM3 files are meant for TASer's own convenience, while the OP speaks about viewer's entertainment.
I guess feos only saw the 2nd post of this topic, about showing tricks and glitches by storing alternative branches of the movie inside the movie file.
On topic: IMO, for maximum entertainment it's better to just use normal video containers for this. As in, use non-linear video editing software to stitch outtakes, add audio commentary and some special effects like arrow pointing at important details or "picture-in-picture" (e.g. the big screen displays normal playthrough, while the small screen in the corner displays suboptimal playthrough).
