Hmm, looking back at that bc1 wip, and applying my 2 second shorter idea which I suggested beforehand...
Why not do that same thing for all laps?
Is lakitu way too slow to put you back on track?
Or you could do it on the last 4 laps, and do the first lap like normal?
Maybe I overestimate the time it takes for lakitu to put you back on track?
Would it be faster, in Bowser Castle, to use the last feather for a shortcut, and then get an item box (shroom) past the finish line, turn around, and get another item box (feather), and super boost (the things you did in GV) you along the way with a feather in your bank, to take the last shortcut?
There will be some backtracking, but with the fourth lap shortcutted, you should save some time. Ok, to reiterate:
On the 4rd lap: get a feather, take the normal shortcut, go past the finish line (final lap will display), get a shroom, u-turn, and boost yourself over another item box (feather), and take the final shortcut that would have normally done with a feather on the fourth lap.
It could also be faster to eliminate the mushroom, and just go for a feather on the fourth lap.
Michael, you keep on saying that it's unoptimized. Please tell us where. Don't pull an AKA on us.
Is it to do with the mini-turboing? Should he be doing them on curves constantly? Should he space them out between 2-3 second intervals? Should he rely on the speedometer?
In ComicalFlop's M64 file, he tries to keep the speedometer at 80 as much as possible. Will miniturboing it more frequently raise the speed above 80?
I take it that in that world record video, you are at 100cc, so you can't go above 75 while driving without mini-turboing.
Please offer some input, or comicalflop is not going to fix what he may or may not have erred.
The AVI appeared fine to me.
The run itself; good run and all that, but certainly improveable. I think that whoever runs this next should really go for perfection so that it isn't beaten by three seconds two weeks after submission.
You see, without a "perfect" benchmark, I believe that each runner believes his or her previous run was close to frame perfect. If you have a better benchmark, or a more perfect run to start off with, you have a reference to go from. Using this reference, it's often a lot easier to spot improvements, especially if the person tasing it is not the same person.
A big point of improvement in this run, however, was the pole glitch, which was discovered after AKA had submitted his run to the workbench, which was delayed, and then subsequently cancelled.
However, with this movie, I'm sure another movie will arise, and another, and then two more. As I said, perfection begets perfection.
I'm using VLC, and the video is playing pretty bad... It lags, speeds up, and looks choppy, overall. I haven't really had any trouble playing previous movies (except that arkanoid game, and that was only a volume issue).
This is borderline SDA quality ;).
You didn't say that, but you seem bitter that this run was published so fast, in comparison to AKA's. Then you realize that AKA's run was delayed, and then start talking about some hex-editing stuff, seemingly related to your previous post, hence your using the term "But, then."
Or I could be reading too much into this.
Oh, okay. But then that means Rikku would have had to hex-edit in the improvement in Bowser 2 as well because he submitted this not long after it was discovered.
There were a lot of other minor improvements other than the warping up the pole glitch. I can't see Rikku hex editing them all in. And what does hex-editing have to do with anything? You think Rikku took AKA's run, hex editted the pole glitch, and submitted?
Where did all the camera angle changes come from, then?
comicalflop, unfortunately we'd also need to find a very fast scrolling autoscroller, like the one in SCW. That might be a problem.
that it would. It still is a great TAS tactic for SCW.
My post was kind of a jib at SMW/SDW, where running underwater is impossible (or if it is, please contradict me)...
The game forces you to run because the screen rolls at over 123 speed (where-as mario's max running/flying speed is around 49-51(not so sure about this)).
So basically, you are pinned against the left-most wall, and all you can do is swim up and down. The game forces you into a running state for reasons unbeknownst (there's your word of the day bitches!) to me.
That level was quite refreshing to play. It was so uncontrollable, that I had to slow the game down to 25% speed, and even then it was like you were at running speed. It will look very impressive in real-time, if TASed properly (or at all).
I made a little demo of the high speed:
http://dehacked.2y.net/microstorage.php/info/3761/runspeed.smv
During this state of high speed, it is fun to shoot fireballs, because you can shoot 1 every 3 or 4 frames, and it will look like mario is frozen, and riding a trail of fire.
Although it's tough to spot the improvements from the latest run, other than the zipping up the pole glitch, I vote yes. I particularly enjoyed the consistency of the camera angles in this run.
Great job Acryte. How many bombs are needed?
Damn mupen. I wonder how much time could be saved if mupen was able to emulate OOT perfectly? No 5 second pause glitch, bombchus should work... I'd say around a minute.
I never thought a scrolling level would be so entertaining!