Why doesn't anyone tell me about these things? >_< Debugging this now.
X-ray has specific poses assigned to it, and the first thing it does is transition Samus into this pose. However, this isn't happening in your movie because a higher-priority pose transition takes place - namely, there is a persistency-transition that occurs when Samus is pushed back, trying to force Samus to remain in the pose she's currently in (although I can see no good reason for this transition - it looks like it's just mimicking the release-Samus-from-kickback-pose code, but since Samus is already out of kickback just uses Samus's current pose).
The key is the push back, in 7E0A52 (and indirectly 7E18AA - this is the timer for 7E0A52). I'm willing to bet it is at least technically possible to use other sources of damage, it's just that spikes give you 10 frames till the persistency transition occurs, while enemies give you only 5. If I understand this code correctly, you have to time the start of the x-ray scope to occur the frame before the persistency transition.
That's not enough time to demorph though, so it seems you have to do something like get hurt, damage boost, land, and x-ray scope in the span of 4 frames.
I did a quick test with an extended timer - that plan seems to mostly work except Samus can't accumulate speed for some reason. I'll look into that in a bit, going to eat right now.
::edit:: Samus can't accumulate speed because she is never set as running - that's done during the motion code which isn't run when the x-ray scope is running. BUT, if you are running BEFORE you use the x-ray scope, Samus will be able to reach blue suit just fine. So: Get hurt, damage boost, land, run, x-ray scope. In 4 frames.
I guess that might be impossible.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
I love this game and I play it at least twice a year. I've never thought of it as Nintendo-hard though... I save that for something obscene like Ikari Warriors. I mean in this game you can literally teleport through enemies and attacks and everything to avoid damage AND convert enemy attacks into health AND can often OHKO *bosses*. There's also no way to die instantly that I can think of. I'll admit the game is overall pretty hard until you have a decent strategy against each boss though.
I've been waiting eagerly to watch a finished run of this, for a year or two now I think. I'm lazy and don't have the setup to watch the submission, so I downloaded the encoding right now.
5) I never knew you could stand in that position :O How much extra space was there?
7) I always liked running in place on the corner too
9) Nice display of the lancer re-aiming... I've noticed that when playing but it was more a nuisance than useful to me.
13) Pfffft I more often lose by running out of time against this stupid boss than anything else. I never knew you could lose by winning too fast.
15) Hahaha avalanche at the top. Why did you not get hit there?
20) There's a fun fact you don't mention here. I'm not sure if it's different on Japanese version, but on the European one you start out facing left but shooting right - through yourself. Not at all important but still pretty amusing.
Overall it was a very impressive and satisfying TAS, my only complaint is the same as Derokan's:
It's a shame the bosses couldn't show themselves off a bit more before dying, but that's TASing for you.
Yes
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
Probably shortly after I find a combination that works. This last week has been an annoying series of 'this should work' followed by 'nope, there's this tangential problem'. Seriously, I should probably be keeping track of a list of failed ideas, this is getting ridiculous.
Powersuit alone can certainly blow up Zebes... but then I don't think Samus can get out before the timebomb's up (though there's a few possibilities I haven't checked yet). I might need to use Varia or Gravity instead. >_<
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
To be fair, it's still heavily in progress and not even ready to reveal yet. It's just that while discussing it with my accomplice, I noticed that quote in our conversation that was just DYING to be mentioned on the board.
Incidentally, while trying to figure this out, the idea of a 0% run DID come up... but it got shot down by a quirk in the game loading. So no, it's not a 0% run but it's definitely a shocker. :) I'm avoiding spoiling it for full shock value when it's finally (hopefully) finished. Don't worry, it's nothing anyone else is going to have a use for in the mean time. This is me we're talking about after all.
If you think I'm being rude still though... meh. My apologies, but I thought it was worth sharing that gem from the conversation.
also Tub, you only guessed the second word correctly.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
<Kejardon> I'm confident power suit alone would be usable to make Zebes explode
If I don't own MacGuyver's job in the next 24 hours there is no justice in the world.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
The more I look at it and think about it, the more impossible it seems. And the movie isn't suggesting anything that makes sense.
The super missile is passing below the gate, and assumably disappearing as it goes off screen and leaving the explosion behind. I did some tests, and if I counted right, the gate is triggered the frame the super missile passes through the gate (1121, the frame the screen shakes). The front super missile can't be hitting it because it goes farther. The back super missile must be hitting it that frame because later frames it will be an exploded super missile (projectile type 8, and the gate requires super missile (projectile type 2) to open) so it can't open the gate anytime later.
The collision for the back-half works by moving forward A pixels (10 if you like decimal) from where the front half (the main part) was last frame (it only happens if the front-half is moving at least B pixels a frame if you're curious). Because of this the only block it should be hitting is the top gate block, which the front-half just passes through.
None of that adds up to opening the gate. I can't even think of any convulated reasons for it to hit the trigger.
I'm done with this unless anyone can come up with something significant. I just see no reason for the gate to be opening.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
Yes, incase you missed it, I was able to manipulate where the explosion happens past the gate by abusing screen scrolling. Would love an explanation on that :D
Hmm.
edit3: The super missile is composed of two parts, one which lags behind the other to try to fix collision detection when the super missile goes too fast. The front half will drag the back half behind it still though, causing the explosion to follow the super missile even though it's supposed to stop. The front half also goes out of bounds before the back half, and so disappears and leaves the back half barely in-bounds.
I thought the code in the game would delete all the super missiles immediately if one went off screen, thus deleting the explosions too. But I was slightly mistaken: when a super missile explodes, it changes projectile type and isn't recognized as a super missile anymore.
I poked around a bit in other stuff too, I don't see anything that would allow a super missile to pass that far. The fact the explosion isn't even on the gate suggests that the front half of the super missile did not even hit the gate, only the slower back half of the super missile hit the gate. The slower back half can NOT pass through a block either, unless it is carried through it entirely by the front half. Even assuming ludicrous speeds, the back half hitting the gate is impossible since the back half is limited to A pixels per frame. Either both halves would pass the gate without hitting it (requiring a speed of 3B00), or the front half would hit the gate and delete the back half before it could do anything (speed of 2100).
also I looked a bit more carefully at the movie and the super missile clearly goes below the block. Why hasn't this been noticed yet?
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
Oh well this is interesting.
My first thought would be to break the movie into frames and reconstruct it exactly with tool-assistance, then compare the results. Someone want to work on this?
My second thought is that off-screen projectiles are somehow failing to hit, and scrolling the screen triggers the hit somehow... but I'm almost sure this isn't the case. The scrolling shouldn't even be able to outspeed the super missile after it's passed half a screen anyways. I guess I can recheck the code.
What's actually bugging me most is the way the explosion stops far past the block though. This isn't a normal case of a super missile going through the wall. The (buggy) collision detection doesn't stop the explosion like that, it does bizarre stuff like in Spoofer's first picture of explosion+missile.
From what I know this shouldn't be possible (my gut is saying the video isn't legit), but I hate to write it off unless there's something particular in the video that I can comfortably label as impossible.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
By your logic, Saturn is the one that should dictate all the rules, just because he has been TASing Super Metroid since before, like, everyone else even thought of it.
:'(
*ahem* anyways. Glitch details.
The 6% run doesn't do any particular glitches that are interesting in and of themselves. It's a combination of several glitches and several normal things happening at the same time. The main glitch in question is probably the warp-past-MotherBrain... I'll go over that.
There's the wall-jump-off-of-door to land inside the door in the next room. Then x-ray wall climbing to get outside of the room. When Samus is outside of the room the block lookup routines continue to try to function with Samus's current position to see what she's running into, even though the data they're looking at has NOTHING to do with the actual room. It's just a table index overflow, which overflows into RAM that hasn't been cleared since it was last used by the title screen for decompressing graphics. Then a bit of garbage data is read as a door, which again works with an unusual position to find what room to go to. Again, table index overflow into uncleared RAM that was last used by the background tilemap in the Brinstar room Samus died in.
No RAM or SRAM is actually corrupted, and the SRAM does not directly do anything interesting (it's only necessary as a passageway to get from one spot in the game to another). The closest thing to corruption is actually the mis-aligned scroll routine which starts writing tiles to the wrong spots in VRAM, and VRAM is only graphical.
What's particularly strange about the run is that what happens makes no sense unless you understand the game's engine, and it is basically a warp instead of a normal room transition. If you want some kind of established difference between this run and the 6% run, the best difference would be 'Uses warps'. Personally I think there should be a separate attribute of 'Breaks game logic' or something - stuff not like buggy collision detection or broken algorithms or tables, but stuff like spawning items or instantly ending levels/battles/the game or warping in a game without warps (such as in the 6% run). Stuff that if an unexpecting viewer sees they don't just go 'Oh, that was a glitch', but 'Wait what just happened'.
As for which movies to put up on this site, that's a silly argument that I'm not up for taking part in.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
Never thought a Dr. Mario TAS would be THAT interesting...
Is the glitch fully understood and controllable yet? If not, I might take a look at it sometime. :)
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
What I am worried about is when the trashing goes outside the boundaries of the console CPU, in this case the hardware which performs the saving of the data in the cartridge. I don't know how this happens in the real console, but I assume that it's not synced with the CPU (as most hardware I/O isn't). If two pieces of hardware are not perfectly synced to each other with the same clock signal, their mutual behavior becomes nondeterministic.
As far as I know, on the SNES the saving actually is synced with the CPU. SRAM is nearly identical in usage as RAM while the power is on. I'm not a hardware expert though, I'm only guessing this based on what I know from how the software and address mapping work.
If anything, resetting on the console should allow far more interesting results than resetting in emulator. You should be able to reset in the middle of a particular bit of code while the game is saving to save certain values but not others, or reset mid-instruction to get a completely different value.
Since the SNES is based on the NES, I'd assume it's the same with that too, and possibly all older systems. It's pretty simple so I don't see any problems emulation might run into; essentially, everything that happens in emulation should be a subset of what can happen on console (since on console strange things like electrical quirks with accessing memory the same time power is lost or resetting in a particular section of code can give different results within a single frame). Until we get to newer systems that *do* have more advanced memory management.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
Pretty sure that's well-known by TASers. Due to a number of quirks of turning, it's possible to 'hover' above the ground indefinitely and build up speed even though Samus isn't moving. Only really useful when you're waiting for the ground below you to break, since you can't manage any significant motion to the side while hovering.
Despite that though, I don't see it often in TASes. I'm guessing it's because you can get a better vertical position by falling normally and timing it perfectly - I've never measured it but I would guess the game engine would cause this to be true.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
Nope, Samus is damaged by a Rinka in the opening-credits. GG.
ACTUALLY, that's a script action, not an enemy collision. Samus is not damaged in the cutscene.
... it's just dawned on me that I know way too much about this game.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
I meant to post this here a week ago and completely forgot! D:
In Super Metroid, I have a tendency to forgot that something is impossible and do it anyways. :D
Also no it's not real
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
And hey, if we really wanted to be batshit crazy, we could program a highly advanced AI to examine the code for the level layout, find the quickest way through, then do it. Again, we can have multiple copies of it working different levels to increase speed; and since no humanity is involved, we can do all the levels period. Considering the AIs don't become self-aware and rebel against humanity, we could just sit back and let them do their thing!
I am so for this, whether the AIs rebel or not. :D
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
... I'm so addicted to hacking -_-
7E0004 = current P1 buttons
7E0008 = Newly pressed P1 buttons
7E082A = currently selected category column (0-5)
7E082B = currently selected dollar row (0-4)
7E0871,X = Bitmask: Already selected dollar rows for this category (100 = bit 0, 200 = bit 1, etc) (The game handles this mask REALLY strangely)
7E086B = Round number? Daily double count?
7E088F,X = DD Category
7E0891,X = DD Row
7FFFFE = RNG seed
RNG routine is at 008593:
$00/8593 08 PHP
$00/8594 C2 20 REP #$20
$00/8596 AF FE FF 7F LDA $7FFFFE
$00/859A F0 03 BEQ $03
$00/859C 0A ASL A
$00/859D 90 03 BCC $03
$00/859F 49 87 1D EOR #$1D87
$00/85A2 8F FE FF 7F STA $7FFFFE
$00/85A6 85 02 STA $02
$00/85A8 28 PLP
$00/85A9 48 PHA
$00/85AA 68 PLA
$00/85AB 6B RTL
So let's see... it runs the RNG and ANDs it with 7 until it gets a number less than 5, then puts that in for the first DD row. It then runs the RNG again, AND #$03, adds that with the other row's position +1, and if the result is over 4 it subtracts 5.
To parse the results of the logic, the two Daily Doubles cannot be in the same dollar row. So no, you can't get both on $200, but you could get one on $200 and one on $400. You'll want to watch 7E0891 and 7E0892 and retry till one is 00 and the other is 01, I guess.
Resetting the categories will change daily double location, but so will simply delaying a single frame sometime.
And while I'm at it!
7E08A6,X = Correct answer (unless you have ASCII memorized this is probably kinda useless... but values over 60 are unnecessary characters - you can drop them without penalty. 5C is \ which means alternative answers)
00AF7A contains the answer-check routine. This may take a while to disassemble....
Values over 60 in 08A6 look like they are COMPLETELY ignored...? They still modify a few bits I don't know the purpose of though.
Spaces in the answer are also completely ignored I think.
It will ignore any bad matches in the text if you have extra letters the correct solution doesn't have, so you can add as many letters as you like.
I think, to be considered correct, you have to have ALL of the characters of the answer (except spaces and lowercase(values above 60 hex or 96 decimal)) (or an alternative answer) in your answer sequentially, but again you can add whatever you like in between characters.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
SNES era games were notorious about relying on hardware glitches and other Things You Should Not Do, since lots of game developers were more electrical engineers than programmers, and Nintendo's manuals weren't that great.
Really? The most I've heard of is reading results from multiplication/division operations early.
evilchen wrote:
that happend to me on a console speedrun :)
Heh. In that case it's fastest to wait for the cutscene to play out. If you leave the room with the Metroid latched onto Samus, your horizontal speed is drastically reduced and the rest of the game takes longer.
If you can get out of the room without the Metroid catching you though, it's definitely a good timesaver.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
You know, I never understood why the space/time beam was termed a "Hardware Glitch." What does it actually is it doing?
Does it throw invalid opcodes to the processor which then proceeds to actually still do work in an undefined way rather than triple faulting?
Does it try to dereference memory that isn't actually there and so it pulls in white noise?
Does it attempt to write to ROM locations and fails with undefined results?
Does it attempt to pull items off of an empty stack and pulls off random noise instead?
Something else?
It attempts to perform a DMA transfer that the hardware should not be able to do, I think. Which might end up meaning dereferencing invalid memory addresses and getting 'white noise' (though it's called open bus instead of white noise). I've never gotten a chance to look into the details.
There are no invalid opcodes on the SNES, all of them are defined and work in a specific way. Writing to ROM simply does nothing - some cartridges can support writing to what would normally be ROM addresses (the prototype of Super Metroid was almost certainly one, there are some demo recording routines that write to an empty bank in the ROM).
Pulling items off of an empty stack has a tendency to crash ZSNES horribly bad (at least, the older versions of it I generally use). I have no idea what hardware actually will do when something like that happens.
When I hear "hardware glitch," I think, "commands issued to the hardware are undefined by specification," which translates to "very difficult to impossible to accurately emulate," which leads me to believe that it's more than simple RAM corruption.
Exactly the right idea. From what I hear, emulation authors generally don't spend a lot of time on trying to properly emulate hardware glitches to begin with.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
The recommended approach is to maintain agent positions in PathEngine coordinates and then convert to floating point representation whenever this is required to render the agent.
I agree entirely with your source's reasoning. :)
Also, the argument is getting stupid here. The real question is at this point: 'Is there a game this is applicable and significant for?' I can't think of a game that it might be worthwhile for, except maybe Wolfenstein or some other early FPSes, but FPSes are not something I know a lot about. Anyone else?
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
yes, but what happens if I want to TAS a popular but badly programmed game? your losing sight of the point.
You have a point but still I'm having a hard time believing this is actually common practice. :/
DaTeL237 wrote:
that's a property of float calculations... and integer (exact) numbers usually won't suffice
Having programmed a good bit myself and understanding various ways to store numbers, this is a really silly statement. Integers are far more appropriate for basically all position variables. I can't think of a case where I'd prefer a float instead.
However, if some values overflow, it becomes fatal to the game's operation. Programmers probably don't nitpick around to find the best type of integer length and format for every value. A "One size fits all" approach would be the most used. If the exponential format proves to be a loss to some values but is generally suited to the rest, it will most likely be used.
That makes sense, I guess. Kinda disappointing though. :/
DaTeL237 wrote:
anyway, in general, I was wondering if the tiny speed increase would weigh out to the increased traveling distance when using such a non-direct route. Or do you think that by abusing the erroneous rounding you'll end up in the exact same locations?
Here's a graphical representation of how this idea might speed up a run:
Overhead view of a (probably 3D) game
Say you start at A and need to get to B. You have to go around a wall first though. Your maximum speed is, say, 15.
Intuitively, the fastest path should be the path that juuust barely clears the wall, passing through point 1. Following that path, your X speed might be 13.9 while your Y speed is 5.8. The game rounds all numbers down though and so you actually only move at 13,5.
Say instead you went to point 2. This angle gives a X-speed of 13.2 and y-speed 7.1, rounding down to 13,7. Like this you could get to the same x-position at the same time but start from a better Y position to reach point B, and possibly reach it in less time.
This can be abused in further detail (you can remove the wall and make line 1 straight, the idea works the same), but the real advantage it can give boils down to how imprecise the position / speed is recorded. If a game is well-programmed you'd be really lucky to get even a single frame from an alternative path. If it's not well-programmed you might be able to save a lot of time.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
Overhead view of a (probably 3D) game
Say you start at A and need to get to B. You have to go around a wall first though. Your maximum speed is, say, 15.
Intuitively, the fastest path should be the path that juuust barely clears the wall, passing through point 1. Following that path, your X speed might be 13.9 while your Y speed is 5.8. The game rounds all numbers down though and so you actually only move at 13,5.
Say instead you went to point 2. This angle gives a X-speed of 13.2 and y-speed 7.1, rounding down to 13,7. Like this you could get to the same x-position at the same time but start from a better Y position to reach point B, and possibly reach it in less time.
This can be abused in further detail (you can remove the wall and make line 1 straight, the idea works the same), but the real advantage it can give boils down to how imprecise the position / speed is recorded. If a game is well-programmed you'd be really lucky to get even a single frame from an alternative path. If it's not well-programmed you might be able to save a lot of time.