Topic by amaurea

Posted: 3/8/2014 10:45 PM

Quote

amaurea

Former player

Joined: 2/19/2007
Posts: 424
Location: UK

Tub: The game operates at the highest level in one of several modes, which usually transition into each other. I think this happens by having a top-most driver function which just loops and calls the game-mode function corresponding to the current value of 998. When a game mode is done and wants to switch to the next one, it can simply write a new value to 998. Sometimes I think this simply takes the form of incrementing 998, since some modes follow each other sequentially. See the death stuff here, for example:

00   0: Hang - black screen
01   1: Hang - black screen
02   2: Hang - black screen
03   3: Hang
04   4: Load game screen
05   5: Select map screen - glitched
06   6: Starts from last save
07   7: ?
08   8: Normal
09   9: Door transition
0a  10: Door transition
0b  11: ?
0c  12: Fade to map screen
0d  13: Map screen
0e  14: Glitched map screen
0f  15: Glitched map screen
10  16: Fade to normal play
11  17: Temporary hang, then normal
12  18: ?
13  19: Death
14  20: Death
15  21: Death anim
16  22: Death no anim
17  23: Death no anim
18  24: Death no anim
19  25: Game over
1a  26: Game over
1b  27: ?
1c  28: Hang
1d  29: Game quit menu (weird)
1e  30: Hang
1f  31: Samus load from save
20  32: Space colony explodes
21  33: Space colony explodes
22  34: Hang
23  35: Space colony explodes, game over
24  36: Space colony explodes, game over
25  37: Hang
26  38: Zebes explodes, ending
27  39: Hang
28  40: Demo
29  41: Demo-related
30  42: Demo-related
31  43: Demo
32  44: Hang
33  45: Hang
34  46: Hang
35  47: Hang
36  48: Hang

That makes most sense if the death and game over stuff is a series of modes which are meant to follow one after another. Many of them result in the same thing because they quickly increment the game mode. The point is that if you suddenly call the wrong game mode, control will probably revert to the mode indicated by 998 the next frame (probably messing stuff up) unless that mode quickly writes something to 998. But this is very speculative - I haven't tested this. While I'm at it, I should mention that if we shoot up-right, A will contain 9f27 when we get here, which just needs a single DEA instruction to make the lower byte 26. That gives us several alternatives for getting 26 in 998. LDA #$XX26 or DEA or something more complicated followed by STA 998. Or one could put 998 in a direct page address and then use STA (foo). Or similar. The hard thing is getting the byte sequence "09 98". It might be easier to instead use the OAM to perform a JMP to somewhere better, for example somewhere with controller input stored. I think this should be quite doable.

Posted: 3/8/2014 11:06 PM

Quote

Garrison

Joined: 3/8/2014
Posts: 36

Cpadolf wrote:

Anyone know if there's a way to do the lava lake before LN without high jump or gravity suit?

courtesy of cardweaver: https://www.youtube.com/watch?v=SY2x09oWRP0

Posted: 3/8/2014 11:30 PM

Quote

Reeve

Joined: 5/12/2009
Posts: 748
Location: Brazil

Cool! That was clever!

Posted: 3/8/2014 11:50 PM

Quote

Cpadolf

Skilled player (1431)

Joined: 7/15/2007
Posts: 1468
Location: Sweden

Thanks Garrison! Also, amaurea, I don't understand half of it but it sounds very interesting! Would be pretty awesome if it was possible to warp to the ending from GT.

Agare Bagare Kopparslagare

Posted: 3/9/2014 12:56 AM

Quote

total

Player (38)

Joined: 1/22/2014
Posts: 38
Location: Sweden

amaurea: Would it be possible perhaps to jump to something like this, assuming we can setup A and then control a jump?

$82/E767 8D 98 09    STA $0998  [$88:0998]   A:0420 X:0003 Y:0080 P:envmxDIzC
$82/E76A 60          RTS                     A:0420 X:0003 Y:0080 P:envmxDIzC

Posted: 3/10/2014 10:54 AM

Quote

amaurea

Former player

Joined: 2/19/2007
Posts: 424
Location: UK

I'll elaborate on this later today, but I can now jump to the ending (in fact, before jumping to the ending I have total control). This is using snes9x, so it should be ported to lsnes or similar. I'll describe what happens in details later.

Posted: 3/10/2014 11:19 AM

Quote

Patashu

He/Him

Joined: 10/2/2005
Posts: 4016

SMB3 and SM total control on the same day. Pinch me, I'm dreaming :)

My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu

Posted: 3/10/2014 12:13 PM

Quote

Cpadolf

Skilled player (1431)

Joined: 7/15/2007
Posts: 1468
Location: Sweden

Damn that is pretty far out, never though something like this would be found for Super Metroid! I assume that the Super count has to be 32 and the PB count has to be 4, right? Also, will it be possible to do in any room because if it's restricted by that it might still be faster to end the game by triggering the escape sequence to the right of the ship. Anyway, I just reached GT in the run I've been working on. It went pretty quickly because so many parts of the run could be lifted with only minor adjustments (mostly realtime optimizations and some drop manipulations) from other runs, and the only really difficult part was Kraid because of the drop requirements. It's about 40 seconds faster in realtime (~13 ingame) compared to Saturn's GT code run despite Bizhawk losing probably a few hundred frames of realtime thanks both to skipping Hi-jump and optimizing lag/doors. Guess I'll hold off here to see how the total control stuff pans out.

Agare Bagare Kopparslagare

Posted: 3/10/2014 4:40 PM

Quote

mutroidtas

Joined: 3/10/2014
Posts: 1

Since there is a lot of out-of-room stuff going on lately, I just wanted to post this little glitch, where it is possible to go out of room without x-ray scope or space time beam in Maridia. I don't know, if it can be used in any other room or if it's useful at all. It also seems to be pixel perfect. Sorry, if this was an already known glitch and posted before.

Posted: 3/10/2014 5:11 PM

Quote

Cpadolf

Skilled player (1431)

Joined: 7/15/2007
Posts: 1468
Location: Sweden

I've seen similar things happen on some slopes in some hacks of Super Metroid (not going straight through the floor but sinking down and getting stuck), I guess it happens when slopes aren't designed perfectly because how samus is pushed down constantly while running to keep her on the ground. Never seen anything like it happen in the main game before so I guess the programers where aware of it and managed to mostly avoid it. Probably of no real use but it's a pretty funny glitch. @amaurea: I noticed that controller 1, 2, 4 and 5 were used in the smv to trigger the ending, is the numbering of the controllers important (as 3 was not used) and would this prove problematic for Bizhawk which doesn't seem to support a 5th controller?

Agare Bagare Kopparslagare

Posted: 3/10/2014 6:29 PM

Quote

P.JBoy

Any

Editor

Joined: 3/25/2006
Posts: 850
Location: stuck in Pandora's box HELLPP!!!

Oh wow, that's nice; that might be the only place in the game where that's possible too. Normally slopes have a special solid block underneath them to prevent that sort of thing, but in that room the slopes are of the very bottom row of the room, so that's not an option

Posted: 3/10/2014 8:13 PM

Quote

amaurea

Former player

Joined: 2/19/2007
Posts: 424
Location: UK

Cpadolf wrote:

@amaurea: I noticed that controller 1, 2, 4 and 5 were used in the smv to trigger the ending, is the numbering of the controllers important (as 3 was not used) and would this prove problematic for Bizhawk which doesn't seem to support a 5th controller?

No, I don't think that should be a problem. This is just an issue of Snes9x using a weird numbering scheme for its controllers. What matters is that the emulator can provide inputs for the four controllers that are read by the auto joypad read function, and while I'm not familiar with Bizhawk, there's no reason why it shouldn't be able to do that.

Posted: 3/11/2014 12:02 AM

Quote

hero_of_the_day

Player (88)

Joined: 11/14/2005
Posts: 1057
Location: United States

Seeing how the space/time beam can enter Tourian from behind, is it totally out of the realm of possibility to enter Tourian backwards somehow using the xray climb?

They're off to find the hero of the day...

Posted: 3/11/2014 1:40 AM

Quote

P.JBoy

Any

Editor

Joined: 3/25/2006
Posts: 850
Location: stuck in Pandora's box HELLPP!!!

In short, yes

Posted: 3/11/2014 2:52 AM

Post subject: Super Metroid page updated

Quote

amaurea

Former player

Joined: 2/19/2007
Posts: 424
Location: UK

I've updated the Super Metroid page with technical details for the glitched beams and arbitrary code execution now.

Posted: 3/11/2014 3:25 AM

Quote

Patashu

He/Him

Joined: 10/2/2005
Posts: 4016

Amaurea: Looks good! I think that the section immediately above what you added (the section's old description of the glitched beams) could be cleaned up and merged. For example, Kejardon's quote is meaningless now that you've described in detail what every glitched beam does ;) Also, tile beam is a damn cool name ^^

My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu

Posted: 3/11/2014 9:39 AM

Quote

Cpadolf

Skilled player (1431)

Joined: 7/15/2007
Posts: 1468
Location: Sweden

From what I can understand it seems like the room conditions have to be pretty specific in order to achieve total control, what are the chances that these conditions can be met in a reasonable time in a room somewhat close to GT?

Agare Bagare Kopparslagare

Posted: 3/11/2014 11:23 AM

Quote

amaurea

Former player

Joined: 2/19/2007
Posts: 424
Location: UK

Cpadolf: Total^ has looked into this. He has found a way by glitching out of bounds in the room next to GT, and running for about 20 seconds. One also needs to collect the GT's super missiles repeatedly. But right now, the uncharged (or should I say partially charged) murder beam looks like it is even easier to use. It's still under investigation, though.

Posted: 3/11/2014 11:47 AM

Quote

total

Player (38)

Joined: 1/22/2014
Posts: 38
Location: Sweden

amaurea wrote:

Cpadolf: Total^ has looked into this. He has found a way by glitching out of bounds in the room next to GT, and running for about 20 seconds. One also needs to collect the GT's super missiles repeatedly.

I refined it a bit more and the best I got while still being quite unoptimized was 1334 frames counted from Samus standing at the GT super missile pack, until being at the right position OOB. But hopefully the murder beam stuff will speed it up a bit since you wouldn't have to get the supers 3 times over and spend 9 power bombs as well.

Posted: 3/11/2014 11:55 AM

Quote

Tub

Joined: 6/25/2005
Posts: 1377

Cpadolf wrote:

From what I can understand it seems like the room conditions have to be pretty specific in order to achieve total control, what are the chances that these conditions can be met in a reasonable time in a room somewhat close to GT?

The way I understand the awesome writeup, the OAM method hinges on finding a sprite with the third byte 0x42 or 0x3e. You can run around with a memory watch and look for either of those values to appear at $402 in different rooms. http://patpend.net/technical/snes/snes.txt explains those bytes:

|   0     Byte   0             xxxxxxxx           x: X-location.             |
|         Byte   1             yyyyyyyy           y: Y-location.             |
|         Byte   2             abcdeeeC           a: Vertical flip.          |
|                                                 b: Horizontal flip.        |
|                                                 c: Playfield priority.     |
|                                                 d: Playfield priority.     |
|                                                 e: Pallete #.              |
|         Byte   3             CCCCCCCC           C: Character data.         |

Palette, Playfield priority and Character data are probably hardcoded per sprite. So 6 bits of "random" data with 2 valid values, if you want to talk about chances then I'd say only 1 in 32 sprites qualifies as a candidate. Once you found a usable sprite, you need to get it at the correct screen position with the correct flip bits set. Vertical flip must be 0 for both values, which is good. Horizontal flip must be 1 for 0x42, 0 for 0x3e. Depending on the sprite, if it cannot be flipped, move on. Now you have to move it into the correct screen position. If the sprite doesn't move and/or the room doesn't scroll, that may be difficult. Last, the sprite has to be at the correct index in the sprite list, so it appears at $400. I couldn't find any reference to that address, so I'm not sure how far down the list that is. But in a room with few sprites, if you cannot add enough sprites via beams and/or bombs, that may be a problem. And we don't know if the order of the sprites can be manipulated in a meaningful way - are they ordered by screen position, by playfield priority, by something entirely different? Understanding the OAM algorithms would probably make this way easier. /edit: apparently, I'm too slow.

m00

Posted: 3/11/2014 4:09 PM

Post subject: Re: Super Metroid page updated

Quote

Derakon

Joined: 7/2/2007
Posts: 3960

amaurea wrote:

I've updated the Super Metroid page with technical details for the glitched beams and arbitrary code execution now.

This was pretty fascinating to read. Even if a run using these techniques doesn't end up being faster than existing runs, I'd still love to see it. Good luck, everyone!

Pyrel - an open-source rewrite of the Angband roguelike game in Python.

Posted: 3/12/2014 1:05 AM

Quote

Cpadolf

Skilled player (1431)

Joined: 7/15/2007
Posts: 1468
Location: Sweden

Well I definitely hope that Murder Beam can speed things up, there's about 23 seconds to go to get to 00:06! Also I improved the run up to GT slightly. I found a way to improve the lava dive before LN just enough to manage to get a walljump on the right side earlier, which in itself gave me enough extra health to be able to take damage from the blue enemies in the gold pirate room to save some time falling down This left me with 1 health and 0/0/0 ammo, which is kind of satisfying.

Agare Bagare Kopparslagare

Posted: 3/12/2014 1:12 AM
(Edited: 3/12/2014 11:18 AM)

Quote

amaurea

Former player

Joined: 2/19/2007
Posts: 424
Location: UK

Here are some notes on what I've found for the uncharged murder beam (together with PJBoy). It jumps to 0dc2, where we have

0dc2  Beam charge counter   00-3c
0dc3  00
0dc4  Last processed block index low
0dc5  Last processed block index high

I have confirmed that the charge counter still hasn't been reset to zero by the time we get here, so this will work. By itself, 0dc2 lets us choose between the same non-fatal instructions as super missiles (the slightly higher range does not help us here): ORA, TSB, BPL, TRB, JSR, BIT, AND, BMI Coupled with the 00 in the following byte, this puts us in much the same situation as with super missiles, but with the possibility of jumping even higher in memory, and being able to avoid the ammo requirements. Both dc4 and dc5 are quite easy to manipulate, since collision detection is done in the air too. The 16 bit number at 0dc4 is roughly given by (x>>4)*w+(y>>4) where x and y are Samus coordinates, and w is the width of the room in blocks. This method can be a drop-in replacement of sorts for the charged space-time beam (though the position requirements might be incompatible with the 0b00 appraoch total developed. But I think the flexibility of 0dc4 and 0dc5 can be used to do something more interesting too, by executing 0dc4 as a conditional jump, with 0dc5 as the argument. In theory this would let us jump ±80 bytes, but due to the limited range of 0dc6 (which is due to the size of rooms - the bigger the rooms the larger the range, but even the biggest rooms are < 30). This won't be a very long jump, and only forwards. This lets us jump as far as about 0df6, which is almost but not quite far enough to get to 0dfe-0e01, which are controller inputs for the previous frame. Of course, going out of bounds will fix this, and going downwards OOB is a very effective way of increasing that byte.

Posted: 3/12/2014 2:54 AM

Quote

hero_of_the_day

Player (88)

Joined: 11/14/2005
Posts: 1057
Location: United States

CP, Loving your latest WIP. Did you ever consider using the pause screen trick to avoid death instead of going all the way through kraid's area to obtain the varia? It would look horrible, but might be faster overall.

They're off to find the hero of the day...

Posted: 3/12/2014 10:09 AM

Quote

Cpadolf

Skilled player (1431)

Joined: 7/15/2007
Posts: 1468
Location: Sweden

I guess it might be worth trying out, the problem would be that an R-tank would be needed to survive the elevator and the PB in the gold pirate room (need 1 hp while going on the elevator and you can't pause during a PB explosion). I think only 40 energy would be necessary for the R-tank though, which could be collected somewhat quickly if the E-tank before Hi-jump is also grabbed (which is probably faster in that case as it would remove several pauses). You're doing amazing work amaurea! EDIT: On second thought it probably wouldn't be faster to take the second E-tank anyway because it would need to remove about 10-12 pauses to make back the time lost. It looks like it would cut it quite close to skip Kraid, which is about a 6000 frame detour. I'd imagine it would take about 1500 frames or so for grabbing the R-tank and getting all the extra refills/avoiding damage before norfair, and it looks like all the pauses would be pushing at least 4000 frames of extra delay.

Agare Bagare Kopparslagare