Instead of providing only the final rerecords counter of a TAS, I think it'd be interesting to display it for each frame (or a larger time frame, e.g. using the data of the last 2 seconds). This would allow the viewer to identify which sections were more difficult to create.
As for the file size cost: for a binary-based TAS file structure, it'd be easy to just use 4 bytes per frame so the size increase would be ~14 KB per minute for a 60fps game.
Assuming a text-based format, it might be better to store only the rerecord counter changes. This would reduce the data to a single "0" for most of the frames, i.e. there would essentially be a 1 byte per frame cost for file formats where the counter can be simply appended to the existing data (e.g. BizHawk's *.BKM) or 2 bytes per frame for file formats that require a separator (e.g. | or Tab). File size cost would be ~3.5 KB or ~7 KB per minute.
I think this would be an interesting idea. You could do all other kinds of interesting stuff, like create graphs or compare various iterations of a TAS in terms of rerecord intensitivity that way.
I'd be all for it.
Current:
Rayman 3 maybe? idk xD
Paused:
N64 Rayman 2 (with Funnyhair)
GBA SMA 4 : E Reader (With TehSeven)
TASVideos is like a quicksand, you get in, but you cannot quit the sand
What would happen if one would do several thousand rerecords on one frame and then realize that you can improve something before by like 200 frames.
Now the question is if all the data is:
lost, or
at the wrong place.
Both options don't sound too nice to me.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
I don't know if I would enjoy watching a graph of rerecord per frame statistics when I know that there can be lost data everywhere.
And then I look at the total rerecords and see 246089 and say, ok.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
I like this idea. It is basically a scaled back version of my previous suggestion for saving the full input history. Simpler to implement, but a bit harder to interpret.
I don't know if I would enjoy watching a graph of rerecord per frame statistics when I know that there can be lost data everywhere.
And then I look at the total rerecords and see 246089 and say, ok.
There is lost data every time a rerecord happens.
It's just to get a feel where much work was spent optimizing/exploring. If you want to see the full data something like amaurea's idea would be better, though I don't know if a visualization would be easy / actually interesting in practise. The end result, when viewed linearly, would look like this, so I'd guess you would need an annotated tree whose branches you could play back. But remember that authors can already describe these failed branches in the submission or in the game thread.
I like it. Here, have a quick implementation for dolphin. http://pastie.org/private/ejwbgptvaiqqmgyo7svl1w
edit: i guess loading from the file is probably a good idea. There's probably still bugs too, so you probably shouldn't use this.
I don't know if I would enjoy watching a graph of rerecord per frame statistics when I know that there can be lost data everywhere.
And then I look at the total rerecords and see 246089 and say, ok.
There is lost data every time a rerecord happens.
By data I don't mean input, but the rerecord data that was saved. When losing this data you can also screw the optimizing/exploring aspect.
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
As usual, it's greatly depends on the game. If you bruteforce 1 scene for 64721378 times and find a trick that obsoletes the previous strategy, all those rerecords for that small frame range gets "wasted", and viewer will see "lol 482194128k rerecords for going right".
edit: didn't even mentioned entertainment hex edits.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
What data is that? The savestates?
MESHUGGAH wrote:
As usual, it's greatly depends on the game. If you bruteforce 1 scene for 64721378 times and find a trick that obsoletes the previous strategy, all those rerecords for that small frame range gets "wasted", and viewer will see "lol 482194128k rerecords for going right".
No rerecords are wasted. Obviously they were required for the author to arrive at the final solution.
Yes, there will be sudden spikes. They're the whole point of this addition: a spike is interesting because they indicate more work done "behind the scenes".
Masterjun wrote:
edit: didn't even mentioned entertainment hex edits.
The additional rerecords are of course exactly as trustworthy as the current rerecord counter in the movie file. Maybe more because it's more work to change lots of values instead of just one.
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.
Well if you can view the different branches of your input, then surely all the rerecord counts can also be viewed separately, and thus paired off with the appropriate sections? As such, it'll never say it took you 2000 rerecords for this particular frame, when actually that was just for your previous strategy at that particular point. See crude diagram:
http://s29.postimg.org/nx5zwxe87/Rerecord_Count.png
Naturally we would want the rerecord count to be at the appropriate section, but how exactly would you view that information? A complete graph for your run would have literally hundreds of thousands of branching pathways, each of which representing a different savestate. Most of which would only last a few additional frames, but is this really what we want to see? If we do that what would the final rerecord count, IE the total along the bottom, actually be? Basically the amount of different places you chose to create a savestate in I guess.
Flip: The rerecords would be displayed where you indicate. That is the price one pays for such a simple implementation. The full branching tree of input and rerecords is what my previous suggestion was about. That can be visualized for example like this:
Link to video
But getting the full history requires much more work than simply getting the rerecord count per frame, and there was not enough interest in implementing it.
creaothceann's suggestion is so simple to implement that it is worth it to do so even though some care must be taken when interpreting the result. And most branches are short, so the results won't be that misleading in most cases.
Flip: The rerecords would be displayed where you indicate. That is the price one pays for such a simple implementation. The full branching tree of input and rerecords is what my previous suggestion was about. That can be visualized for example like this:
Link to video
But getting the full history requires much more work than simply getting the rerecord count per frame, and there was not enough interest in implementing it.
Well if you can view the different branches of your input, then surely all the rerecord counts can also be viewed separately, and thus paired off with the appropriate sections? As such, it'll never say it took you 2000 rerecords for this particular frame, when actually that was just for your previous strategy at that particular point. See crude diagram:
http://s29.postimg.org/nx5zwxe87/Rerecord_Count.png
Naturally we would want the rerecord count to be at the appropriate section, but how exactly would you view that information? A complete graph for your run would have literally hundreds of thousands of branching pathways, each of which representing a different savestate. Most of which would only last a few additional frames, but is this really what we want to see? If we do that what would the final rerecord count, IE the total along the bottom, actually be? Basically the amount of different places you chose to create a savestate in I guess.
Just for the record, my idea in a diagram: http://i.imgur.com/GpNEfUZ.png
(Branches start from the bottom; each savestate loading goes back and adds 1 to the rerecord counter. The final movie file will show the rerecord sequence "0 0 1 3 3 3 3 3", which means it took one discarded branch to get to frame #2 [counting from zero] and two discarded branches to get from frame #2 to #3. The last frame will have the same rerecord number as the rerecord counter currently stored in movie files.)
It would say that "it took 2000 rerecords for that frame" because all previous strategies contribute to the final frames.
For every input frame, PerFrameRerecordCounter[frame] = NormalRerecordCounter
That's nice and simple. I like it. I had misunderstood your idea, and thought it was
For every loadstate, PerFrameRerecordCounter[frame]++
The two differ in how the rerecords in the discarded branches are treated. With your idea, they are all condensed into the frame where they branch off from the trunk. With what I first thought your idea was, they would be flattened down to the corresponding frame in the trunk. I think the latter is what RachelB implemented, though I only skimmed through that. Both versions would work, but I think I prefer your real suggestion. And they are both really simple to implement.
...bruteforce 1 scene for 64721378 times and find a trick that obsoletes the previous strategy, all those rerecords for that small frame range gets "wasted", and viewer will see "lol 482194128k rerecords for going right".
No rerecords are wasted. Obviously they were required for the author to arrive at the final solution.
I think you don't see the difference between rerecords counter (that changes everytime I draw something in TASEditor) and number of tests done that requires changing the locations and numbers of different buttons. Probably for really, REALLY basic games it's considered to be "small wastes" but in a more complex game where you have subpixels and you need to be fast and RNG changes (==> jumps changes, enemies changes, route changes ==> strategy changes ==> starting all over from RNG changes, jumps changes, enemy....), it's a huge waste. And I didn't even mentioned lag frames. edit: and 3D games, randomly generated levels, "unremanipulatable" situations (specific conditions required can't be reimplemented because of substantial changes beforehand).
Few examples with huge wastes (emphasis on RNG change because of delay or improvements): NES Trojan, NES Streemerz, NES Rygar, NES Widget, NES Metroid, NES Rod Land, NES Kirby's Adventures...
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
If you're using an editor then of course the results would be different. I guess the editor could be changed so that the rerecord counter is only increased when the TAS file is saved. But of course that's up to the author.
Changing a frame would write the current rerecord counter to that frame. Upon saving, the program goes through each frame and adjusts the rerecords. Pseudocode:
current_RerecordCounter = 0;
for i = 0 to (Frames.Count - 1)
current_RerecordCounter = max(current_RerecordCounter, Frames[i].RerecordCounter);
WriteToFile(InputToString(Frames[i].InputData) + "|" + IntToString(current_RerecordCounter));
If you're using an editor then of course the results would be different. I guess the editor could be changed so that the rerecord counter is only increased when the TAS file is saved. But of course that's up to the author.
I'm glad that you didn't take my comment as something negative, I can't express myself correctly. Well while I know my TAS style isn't the common one (even in TASEditor, since I don't use branches, patterns etc), I was referring to the "evolution" of a TAS from a simple test run that goes into a crazy short TAS.
Like platformer games, where you can skip walls, push movement speed over the limit, many different objects to abuse... the huge number of factors greatly increases the number of tests "should be" done (to understand game engine). So I guess using the TASEditor branches (something like feos did #3773: feos's NES James Bond Jr. in 18:29.84) could be used in a way that you literally make a new branch everytime you start a new rerecord since this way all of your progress will be saved.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
