Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
I should also note that
Eye of the Beholder wrote:
Moozooh: It's just the trick described above by sniq where, if you have a spark to activate and you activate it in the same frame the hurt timer will end you get a free spark.
Isn't the full story. I don't think the situations that cause the glitch to occur are fully understood yet, but also relevant here is 7E0B36. This address keeps track of whether Samus is on the ground (0), rising (1), or falling (2). Normally, activating a shinespark sets it to 1, but everything that has caused this glitch to occur keeps that address at 2 for the duration of the shinespark wind-up. It just so happens that the address is forced to be 2 after the hurt timer (7E188A) reaches 0, but that's not all there is to it; if it were, it would be possible to damage boost back for a frame or two and then activate the spark while still in the air. Landing first is a requirement here, for some reason. The normal way of performing the glitch - unmorphing after taking damage from a spike - kind of imitates landing, hence why that works.
There may be other unknown variables involved, though, as I've been told that using the cheats to keep 7E0B36 on 2 and shinesparking normally doesn't cause the glitch to work; it too could just be a result of the real cause. Then again, that's with cheats, so I wouldn't call it reliable information at all.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Eye Of The Beholder wrote:
I suggested exactly something like that to Taco yesterday
And I mentioned it to Sniq. :) I have to admit, though, that I didn't actually expect it to work at all. We're trying out a ton of different ideas right now.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
The secret is out to some people on Twitch so I guess we should post about it. Sniq recently discovered an absolutely absurd new application of an old glitch that speeds up any movement along slopes in this game. It is possible to run through the purple diagonal room in Crateria, for example, in 258 frames.
If Samus, while falling, unmorphs on the right frame and at a near-perfect y position, it is possible to maintain falling speed while running on the ground. The only known application up until now (that I'm aware of) is in the 100% TAS to negate the effect of Wrecked Ship treadmills, but apparently it also massively changes the way Samus interacts with slopes. It completely negates the seemingly random nature of slopes and what they do to Samus's horizontal position, and allows Samus to run along them at the same speed that she would on normal solid blocks. As a result, they also don't mess with Samus's subpixel anymore, which is a fantastic bonus by itself.
Here it is. To ensure the comparison is fair, I created a test that runs through the room without the glitch that also does not collect any refills; it took 280 frames. Unfortunately, it means refilling strategies for this room may need to be completely redone... that'll be fun. I expect they'll cost a lot more time to collect now, though, so the actual gain in this case might fall down to single digits, especially since the previous room takes longer to set up the glitch (although the setup in that smv is most certainly improvable). Regardless, it could be useful in many rooms throughout the game, especially if less time-consuming ways of performing the glitch are discovered; all known methods right now either involve unmorphing, or some weird clipping and turnarounds that will probably never be useful.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
lxx4xNx6xxl wrote:
Any progress on the possible Moonwalk application/integration?
Nothing except beginning a suitless underwater run with moonwalk gives Samus running momentum that usually takes over 30 frames to get, so running is immediately faster than jumping. I've known about that for a week or so but completely forgot to mention it in this thread.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Eye Of The Beholder wrote:
Sniq wrote:
It's apparently possible to just switch directions from moonwalk and speed is kept.
Just switch directions? No damage boost needed?
I think the trouble is that it isn't possible to moonwalk with speed in the first place unless damage is taken from a spike. :) Any other way that anyone can find to moonwalk with speed, especially without the use of specific enemies or room layouts, would be absolutely insane.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
hero of the day wrote:
Seems like this will save quite a bit of time over the course of a run. Very much looking forward to seeing this implemented!
Well, there is a downside: the most commonly used pattern is to run for two frames. release for one, and then continue running. I compared to the four frame run in that post since it was the best known pattern distance-wise, but this moonwalk pattern takes one extra frame to set up compared to the two frame run. That makes it not as incredibly ridiculously insane as it may sound :) But it will certainly have its uses.
I really believe moonwalk may be worth taking...
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Moonwalk can be used as an improved form of acceleration storage.
When Samus begins moonwalking, her momentum is immediately set to 32768 and remains there until moonwalking is canceled. If Samus begins running forward to cancel moonwalk, her momentum then builds up starting at 32768 instead of 0.
These two smvs will show what I mean:
Normal acceleration storage -- Starting at x = 37.0, Samus runs forward for four frames, releases forward for one frame, and then continues running. Max speed (2.0) is reached at x = 137.36864.
Moonwalk acceleration storage -- Starting at x = 38.32768, Samus moonwalks backward for one frame, runs forward for two frames, releases forward for one frame, then continues running. Max speed is reached at x = 135.53248. Samus must begin at 38.32768 to avoid colliding with the door and losing momentum. The same is true if this trick is performed on a platform of some sort; Samus must begin a pixel and a half ahead of the edge to avoid falling off*.
Maybe this could be used to reduce short charge distance even further, too?
EDIT: * -- Apparently, this is not true.
[6:21:47 PM] Sniq: it works!!!
[6:21:51 PM] Sniq: as long as subpixel is 0
[6:21:55 PM] Sniq: samus can start 1 pixel from air
[6:22:00 PM] Sniq: lets say
[6:22:04 PM] Sniq: samus normally falls at 59 65535
[6:22:12 PM] Sniq: you can start running from 59 00000
[6:22:13 PM] Sniq: with moonwalk
[6:22:14 PM] Sniq: lol
[6:22:20 PM] Taco: I was wrong then!
[6:22:23 PM] Sniq: previously 60 00000
[6:22:26 PM] Sniq: was the minimum
[6:22:29 PM] Sniq: now you can start from 59 00000
So it's even better than I thought!
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Eye Of The Beholder wrote:
That's not that much if you can find at least a few good aplications. Also, you have to see how much you'll have to delay the intro to get perfect Ceres, if not any frame, you're already saving a few frames, if more, than the moonwalk option may cost a few more frames.
Well, in a realtime-oriented Ceres, that new staircase steam boost would be used unless near-perfect luck is obtained. The steam in that room is much easier to manipulate than the second to last room and I can't imagine more than 2-3 extra frames being lost on it. Either way, if just one or two good room strategies with the moonwalk glitch are discovered, it's probably worth it.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
To provide an exact number, moonwalk takes 64 frames to activate. That is significantly less than some estimates I've seen (in fact, I'm pretty sure that number has never been mentioned anywhere since nobody has taken the possibility seriously, including me). Very minor frame saves throughout the game could be enough to make up for that, nevermind any moonwalk-specific glitches that are discovered.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Sniq wrote:
We finally have an use for moonwalk!
Hey, don't forget that one frame it saves in Ceres!
It wouldn't be too surprising if moonwalk can be abused in other ways. I don't think many people have ever really taken the idea seriously.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Boct,
I don't have much to say in this post, and it's probably best to learn by doing anyway, but if you ever have questions or would like a review on one of your TAS attempts, feel free to PM me. I'd be happy to provide as much help as you want. :)
As for your questions,
boct1584 wrote:
1. Is there any particular method I should use to familiarize myself with how Super Metroid plays under tool-assisted conditions? Or just do test runs and see what happens?
Jumping into TASing and getting familiar with the game is the way to go, in my opinion. There's a lot of little quirks in the way this game works that you'll learn about mostly by TASing and comparing your work to existing runs to figure out how/why they're faster (just don't get discouraged by this!).
I recommend not starting out with Ceres or early Crateria, or if you do, don't worry too much about your performance; they are both deceptively difficult areas to optimize. (Then again, I started out by spending like 3 months in Ceres >_>)
boct1584 wrote:
2. I would guess that having the resources page for Super Metroid open in the background, or on a second screen, is ideal for quick references. Agree or disagree?
Sure, why not?
boct1584 wrote:
3. Is there a repository of Lua scripts and memory addresses I can use?
Not sure about lua scripts (I've only ever used one that displayed the hitboxes on everything), but as moozooh said, most useful memory addresses can be found on the tricks page. The rest can be found in Kej's RAM map. There's a few useful things in there, such as camera y position to help optimize doors for realtime.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Cpadolf wrote:
Damn, haven't been able to check up close on emulator yet, where did all the 20 frames in Ceres come from? As far as I remember I did sort of aim for realtime there and only added som door lag in one room to get a better steam patter which I thought saved as much ingame time as I lost realtime. Might be misremembering something.
11 (I think) from the title screen and save selection, and a few more (2-4ish if I remember correctly?) from running into Ridley's room instead of jumping. I just assumed those title screen frames were intentionally missed for steam manipulation since you seem to have gotten them after the reset. The remaining frames must be because of the lag you added.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Eye Of The Beholder wrote:
Amazing work Taco! Can't believe you found a way to make something different in Ceres, even if it is just equally fast, having watched that part of the game for years without significant changes (at least not ones that our eyes can notice) and see something different is really nice.
This is mostly because of bad steam RNG, to be honest. The same damage boost used in every other Ceres escape is surely still the best, but I wasn't able to get that pattern without losing most/all of the realtime frames that I'd gained up to that point, so I was forced to search for alternatives. This is actually something that I vaguely remember trying back in 2008 or whenever I was trying to crack Saturn's Ceres time, but unfortunately I didn't consider at the time that it might be useful for a realtime-oriented Ceres. :P The main benefit is that it reduces scrolling during the room transition.
One of the other options that I mentioned in the submission text is actually equally fast in realtime, but gets an escape timer of 49'13 instead of 49'09. Still, I chose to go with this one because it is - in my opinion - by far the most entertaining option, and realtime is my primary goal anyway.
hero of the day wrote:
I would love to see you take on one of the other Super Metroid categories. I think the any% non-glitched run is in need of some updating :P
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Hmm, strange that it says the movie begins from dirty sram. We're guessing something may have went wrong during the conversion from .bk2 to .lsmv a few days ago. Regardless of the reason, Total has provided a new file that has hopefully fixed the issue, but is otherwise exactly the same, and I've contacted a judge for replacement. Sorry about that.
EDIT: Looks like it's been replaced. Thanks Mothrayas!
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
SMILE gives some clues on how the grapple glitch works. In SMILE, scroll blocks are depicted by red circles containing the letter S and arrow blocks can be used to extend the reach of scroll blocks. Normally, when Samus steps on a scroll block or any of the arrows connected to it, it's programmed to lock or unlock a section of a room and allow the camera to scroll into that section.
For some reason, when vertical arrows connected to scroll blocks don't keep going until they reach a solid block, it causes problems with grapple.
The first image is from a clean rom. Samus must be touching the column that the circled scroll blocks are in, even if it's only by one pixel. If you remove those scroll blocks, it completely stops the glitch from working.
The glitch normally doesn't work while Samus is standing in the other two columns of scroll blocks, but removing the top two arrows on the rightmost one so that it looks like the second image causes the glitch to work in that column too.
One of the programmers probably puked on the room inside Kraid's lair. I have very limited knowledge of how SMILE works, but I think I see the problem. This image doesn't show it, but SMILE shows certain blocks in the area as horizontal / vertical blocks. I think these can be used for the same purpose as the red arrows from the first two images. If the arrows had been used instead, it would've looked like this:
This is consistent with what I found in the other room. The glitch works here because the chain of scroll blocks depicted by the blue arrow doesn't keep going until it reaches a solid block; it just collides with the green arrow instead. Removing the vertical/horizontal blocks also stops the glitch from working here.
Experienced Forum User, Published Author, Former player
Joined: 6/28/2007
Posts: 67
Derakon wrote:
If you feel that we need to not have a fifth Super Metroid video on the site, I'd suggest replacing one of the less-glitched any% runs (here or here). They're the least well-distinguished from each other of the currently published runs.
Seconded. I'm not sure if I should bring up this argument here, but if it has some relevance to whether or not this can be published... IMO, it was a mistake to bring back the in game category.
As I understand it, the decision to publish an in game category was made largely because, at the time, the difference between the two routes and strategies used was enormous. That's no longer true, at least not to the extent it once was.
Here's a list of route differences between the two published any%s (hopefully I didn't forget anything...):
- Saturn kills Kraid after Ridley. However, I'm pretty sure we should've done this in the real time any% too.
- Saturn collects the Plasma Beam.
- Saturn collects the Hi Jump.
Saturn has the Plasma Beam for less than six realtime minutes before it's replaced by Hyper, so it makes very little difference overall. That just leaves the Hi Jump.
The first image is from a clean rom. Samus must be touching the column that the circled scroll blocks are in, even if it's only by one pixel. If you remove those scroll blocks, it completely stops the glitch from working.
The glitch normally doesn't work while Samus is standing in the other two columns of scroll blocks, but removing the top two arrows on the rightmost one so that it looks like the second image causes the glitch to work in that column too.
One of the programmers probably puked on the room inside Kraid's lair. I have very limited knowledge of how SMILE works, but I think I see the problem. This image doesn't show it, but SMILE shows certain blocks in the area as horizontal / vertical blocks. I think these can be used for the same purpose as the red arrows from the first two images. If the arrows had been used instead, it would've looked like this:
This is consistent with what I found in the other room. The glitch works here because the chain of scroll blocks depicted by the blue arrow doesn't keep going until it reaches a solid block; it just collides with the green arrow instead. Removing the vertical/horizontal blocks also stops the glitch from working here.