Game objectives

  • Emulator used: lsnes rr2-beta7 (works with rr1)
  • Aims for fastest time
  • Uses game-breaking glitches
  • Heavy luck manipulation
  • Achieves credits early

Comments

More than one year after the discovery of the credits glitch in yi2 this is finished. And here it is, finally, the new glitched Super Mario World TAS. This movie is different from the original run by antaasas in many ways. The only similarities are that we use the same game-breaking glitch and that we both jump to controller data so that we can execute from there.
A big difference between this run and the one by antaasas is that this one works on console, while his run was an emulator bug.
This run uses two multitaps in port 1 and port 2 which allows for 8 controllers (1-1, 1-2 ,1-3, 1-4, 2-1, 2-2, 2-3, 2-4) of which 4 are used (1-1, 1-2, 2-1, 2-2) for the last input.

The new version of the credits glitch

When stunning a flying ? block, it can spawn a sprite with the ID 0xFA. This ID is not an actual sprite and it is never used in SMW but since it spawned, the game has to run a code for that sprite. The game indexes the code location wrong and the code jumps to $0322. This is a place in the OAM table (OAM is a chunk of memory that stores the data about the sprite tiles to draw onto screen). That means that we can change values of the code being executed by changing the position of sprites.

OAM

This picture shows the OAM starting from $0320
The place we are accessing ($0322) is at the start of OAM for the sprites. The first 4 bytes are for sprite #A, the next 4 byte are for sprite #B and then every sprite from #0 - #9 has 5 * 4 bytes. Every block of 4 bytes has a format like this: x positon, y position, tile, property. The tile and properties of a sprite are almost impossible to manipulate so we have the x and y position left to use.

Problem #1 - Y Positions

Every frame, all y positions are reset to 0xF0 and they update from the top to the bottom, which means #9, #8, #7...#1, #0, #B, #A. That means when handling sprite #5, you already have the y position of #6 but not of #4.
"So then why not spawn the 0xFA sprite in slot #0 to have many positions already updated?" Because to spawn that sprite we need a shell which goes into slot #0 when taken to the underground in yi2.
"Then use slot #1!" This is what we do.

The glorious P-Switch

We want to manipulate the values to show the credits, right? So how do we do that? We could manipulate 11 bytes to be perfect, but that is very hard and might not even be possible. So let's just jump to the controller input data and execute from there. The input is at $4218 so we need a JMP $4218 which is 4C 18 42. Only x and y position aren't enough so we need a sprite which uses tile 0x42... P-SWITCH!
So let's just go to the end of the level and get the P-Switch and, oh wait...

Problem #2 - Slots

Every new sprite that spawns will use the highest slot that is free (#A and #B are reserved slots for special sprites like sprites from boxes). Since we want to be as close as possible to our start position ($0322), we have to get a small slot for the p-switch. So we need to fill the higher slots to get a small slot for our P-Switch.
Most sprites despawn when they go offscreen so we need better sprites. When you cancel-eat a berry it will turn into a sprite which won't despawn when going offscreen so that is what we do.
Now that we have the P-Switch in the right spot we just stun a flying ? block, but how do we that actually?

Stunning

To stun a sprite you have to have a sprite that Yoshi won't swallow (like a shell), another sprite which Yoshi can lick and a place to get hit (like a koopa). You also have to get a powerup to do the double-tongue glitch with Yoshi. Grab the first sprite with the first tongue, then lick the second tongue and quickly get hit by the third sprite, so that Yoshi cancel-eats the second sprite.

Problem #3 - We need sprites!

How do we get these sprites into the underground? Ok, we can use a throwblock as the second sprite, but how do we get the other two? We can bring a green shell into the underground when doublegrabbing the P-Switch and the shell while sitting on Yoshi (yes, this is possible). With the green shell we can spawn a naked koopa (stomping on the green shell and licking it at the same time, then quickly spitting it out), which then is our third sprite.
Now we need a powerup. We can use the midpoint to be big but we still need a mushroom for the reserve box. When you eat 10 red berries with Yoshi, he will give you a mushroom. Thanks Yoshi!
We can spawn an 1up by duplicating the vine block to the left. We use that to manipulate the x position and the tile so that we jump a bit forward in the code (to $034F, which is in the middle of #1 OAM, so we are almost at our P-Switch in #2). The code unfortunately jumps away just before we reach the P-Switch bytes, so we have to change the last few bytes of the slot #1 bytes.

Problem #4 - Bigger sprites!

Since most sprites (like the shells) are only 16x16 pixels big they only use one block of 4 bytes for their slot. Koopas are 16x32 pixels big, they use two blocks of 4 bytes, that is still not enough to reach the last blocks. So what are big sprites... Chucks! They use all 5 blocks.
There are not enough berries at the start to spawn the first chuck in slot #1 so it would be better to use the one later in the level, right?

Problem #5 - Pipes change slots

When you go into a pipe with an item, it will turn into slot #0. If you go into a pipe while doublegrabbing an item, the item with the lower slot will go into slot #0 and the higher one keeps its slot. Since we wanted the P-Switch in slot #2 we have to get the green shell into slot #1 or #0. The green shell appears early in the level so it would lose time to run forward filling sprite slots, then run back to get the shell and run forward again to get to the pipe. So we need another way to fill sprites early.
Yoshis won't despawn when they go offscreen so we create 5 Yoshis to fill slots #9 - #5, then we spawn the chuck in slot #1 to get better values, and then we spawn the green shell in slot #1.
Is everything working now? Not yet.

Problem #6 - Too many Yoshis

When there are multiple Yoshis on the screen, the egg with the mushroom will spawn at the Yoshi with the highest slot, which still is way back on the Yoshi block, so we have to... sacrifice 4 Yoshis to give Mario the mushroom he needs. When Mario gets hit while he sits on multiple Yoshis, he will only get off of one of them, so the next one will be moved under him.

Are we done?

Yes, we are done... with the setup:
spawn 5 Yoshis, spawn chuck in slot #1, spawn green shell in slot #1, get midpoint, change values with 1up, spawn pswitch in slot #2, sacrifice Yoshis, get mushroom, go into pipe with Yoshi, P-Switch and shell, stun flying ? block, fill slots so sprite 0xFA will spawn in slot #1 while having the pswitch in x position 0x4C and y position 0x18 (or 0x19).
We got the jump to the controller data, the rest is easy... in Snes9x!

Problem #7 - Too slow

We have 8 bytes controller data. To get to the credits we have to set the game mode($0100) to 0x18 and $13C6 to 0x08 and then return. That would be A9 18 8D 00 01 A9 08 8D C6 13 6B, that are 11 bytes, so we somehow have to make the game wait for the next input. There is this instruction WAI which WAits for an Interrupt. That interrupt will happen at the start of the next frame. The only problem is that this interrupt returns too fast, the SNES has not enough time to update the register for the buttons (in Snes9x there isn't this problem, that makes everything very easy), so when trying to execute them they have partially the values from the previous frame and a few from the current frame shifted wrong.
I managed to somewhat bring a routine into that garbage shifting. I have 3 bytes at the start, then I execute a WAI, after that I execute another WAI so it has enough time to update, then I branch back to the first 3 bytes, which also have new input.
However this is very unstable, I couldn't even do that routine one more time, the shifting was completely different suddenly and everything was failing, so I had luck that it worked.

Input

The last 4 frames of the movie was the input that was executed:
             1-1              1-2              1-3              1-4              2-1              2-2              2-3              2-4 
F. 0 0|B.s.u..r........|.YsSud.r.X.R0..3|................|................|BY..u.lr...R0...|BYsSu...A.......|................|................
F. 0 0|........A...01.3|.YsSud.r.X.R0..3|................|................|BY..u.lr.......3|BYsSu...A.......|................|................
F. 0 0|....u...A.L.0..3|.YsSud.r.X.R0..3|................|................|BY..u.lrAXL.0.2.|BYsSu...A.......|................|................
F. 0 0|BY...dl.A...01.3|.YsSud.r.X.R0..3|................|................|.Ys........R..23|BYsSu...A.......|................|................
B=B, Y=Y, s=select, S=start, u=up, d=down, l=left, r=right, A=A, X=X, L=L, R=R, 0,1,2,3=the 4 extra bits
Every controller has 2 bytes and they are stored in the registers $4218 - $421F.
$4218, $421A, $421C and $421E are the low bytes (AXLR0123) and $4219, $421B, $421D and $421F are the high bytes (BYsSudlr) of the controllers 1-1, 2-1, 1-2, 2-2 (respectively). So that $4218 has for example 0xFF if AXLR0123 are pressed or 0xEA if AXL.0.2. are pressed.
So let's convert the input into hex numbers, that would be for the first frame: 00 A9 18 CB 59 7D 80 F8. This movie jumps to $4219 so the first thing it does is LDA #$18 (A9 18). Then there is the WAI (CB) and the bytes are shifted wrong so that results turning 59 7D into EA CB which is NOP (do nothing) and WAI again. After WAIing twice the game had enough time to update the values so it executes BRA $F8 (80 F8) (from the second frame) which means it branches 8 bytes back to $4218 where the second input frame starts.
More information about why it fails the indexing and what the code executes from the input here.

Suggested Screenshots


feos: Nach didn't pick it yet? Judging!
Nach: A good way to ensure that is to submit when I'm away for ~26 hours, which is at least once a week.
feos: Accept and publish.


ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
Nach wrote:
ALAKTORN wrote:
thanks for the clarification, you don’t sound sure of the fact that the mouse can achieve it though…
The mouse can if operated with extreme precision by a robot, but a human using the mouse can't.
well, difficulty of execution is irrelevant, that’s what TAS is aimed at overcoming I’ll be taking my leave with an almost-belief that the run is legitimate then, almost 3am here… good night
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Perhaps this debate can be resolved with an additional tag for movies like this, e.g. "requires non-standard controller"? This would be similar to "uses memory corruption" and other tags.
Masterjun
He/Him
Site Developer, Skilled player (1986)
Joined: 10/12/2010
Posts: 1185
Location: Germany
Radiant wrote:
Perhaps this debate can be resolved with an additional tag for movies like this, e.g. "requires non-standard controller"?
have fun searching for <+> or ^+v in every movie to add that tag
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Patashu
He/Him
Joined: 10/2/2005
Posts: 4042
Masterjun wrote:
Radiant wrote:
Perhaps this debate can be resolved with an additional tag for movies like this, e.g. "requires non-standard controller"?
have fun searching for <+> or ^+v in every movie to add that tag
Couldn't a script do it?
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
Active player (264)
Joined: 4/15/2010
Posts: 197
Location: England
Relevant, from our resident SMW TASer SkamastaG: Link to video "Uses non-standard controller" is nonsensical. If the hardware recognizes the input there shouldn't be a problem. As Nach has pointed out there are official controllers that use these additional buttons, so. Our only concern should be whether or not the input will play back on a console, not whether there are peripheral restrictions. Edit: The issue of cartridge tilting is irrelevant here. With cartridge tilting it requires (subjectively) a slightly "modification" of hardware, something external from input files, which is all TASers deal with as far as I know (besides CD-swapping, etc).
Retired smw-96, smw any%
Skilled player (1736)
Joined: 9/17/2009
Posts: 4979
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Patashu wrote:
Masterjun wrote:
Radiant wrote:
Perhaps this debate can be resolved with an additional tag for movies like this, e.g. "requires non-standard controller"?
have fun searching for <+> or ^+v in every movie to add that tag
Couldn't a script do it?
Uh....sometimes, in my TAS's, I do that just because it showcases a minor visual glitch. Gl finding out which movie does this for fun and which is required.
Masterjun
He/Him
Site Developer, Skilled player (1986)
Joined: 10/12/2010
Posts: 1185
Location: Germany
jlun2 wrote:
Patashu wrote:
Masterjun wrote:
Radiant wrote:
Perhaps this debate can be resolved with an additional tag for movies like this, e.g. "requires non-standard controller"?
have fun searching for <+> or ^+v in every movie to add that tag
Couldn't a script do it?
Uh....sometimes, in my TAS's, I do that just because it showcases a minor visual glitch. Gl finding out which movie does this for fun and which is required.
if you really want to add that tag then it also has to be for the movies where it isn't required, since that's the rule then
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Site Admin, Skilled player (1250)
Joined: 4/17/2010
Posts: 11468
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
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.
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Masterjun wrote:
Radiant wrote:
Perhaps this debate can be resolved with an additional tag for movies like this, e.g. "requires non-standard controller"?
have fun searching for <+> or ^+v in every movie to add that tag
I thought we already had that? For instance this submission uses it.
Masterjun
He/Him
Site Developer, Skilled player (1986)
Joined: 10/12/2010
Posts: 1185
Location: Germany
Radiant wrote:
Masterjun wrote:
Radiant wrote:
Perhaps this debate can be resolved with an additional tag for movies like this, e.g. "requires non-standard controller"?
have fun searching for <+> or ^+v in every movie to add that tag
I thought we already had that? For instance this submission uses it.
A game objective in the submission text is not a tag
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Emulator Coder, Skilled player (1112)
Joined: 5/1/2010
Posts: 1217
Radiant wrote:
Masterjun wrote:
have fun searching for <+> or ^+v in every movie to add that tag
I thought we already had that? For instance this submission uses it.
Saying that in submission might be from emulators with settings that enable/disable L+R / U+D (either because that emulator has such setting or via copying someone else's submission text layout).
Joined: 7/29/2009
Posts: 55
If the SNES mouse can create that input, I think it's okay.
Player (13)
Joined: 6/17/2006
Posts: 506
Now I want to see somebody beat SMW on real hardware with a mouse. :D
Editor, Player (44)
Joined: 7/11/2010
Posts: 1029
I dislike using nonstandard controllers for TASing for the same reason SDA dislikes controllers with turbo buttons. I am, however, perfectly fine with the use-lots-of-multitaps solution. (Especially because connecting 8 controllers to SMW is an amusing mental image.)
Post subject: Izquierdo - I know that word. Left turn it is!
JXQ
Experienced player (761)
Joined: 5/6/2005
Posts: 3132
I thought I had an old post where I explained this idea, but couldn't find it. Controllers on a system are polled for input 60 times per second in NTSC. This means that for some finite amount of time, say X nanoseconds, button presses will "register" for a given frame. If, during these X nanoseconds, you press only left for X/2 nanoseconds, then press only right for X/2 nanoseconds, then what does the system register as the buttons pressed for that frame? If it's both left and right, then it follows that tool-assisted play could use left+right without the use of any special controller or controller modification. If it's only one of the directions, then there is more to controller input polling that I don't fully understand, which is very possible.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Site Admin, Skilled player (1250)
Joined: 4/17/2010
Posts: 11468
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Thread #14051: Debate: allowed or not?
AnS wrote:
ALAKTORN wrote:
@MrGrunz: that’s a good point, does anyone know if it would work? basically pressing left then right so fast that the game registers them at the same time
No, it would not work. There's common convention to poll joypad input by "strobing", which is reading input port only once per frame and storing the current state in memory. So it doesn't matter if you manage to press/release any buttons between two strobes, the game will only register those buttons that were held at the very moment of making a strobe.
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.
Noxxa
They/Them
Moderator, Expert player (4107)
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
Link to video We've gone over this so many times I've lost count about halfway through. Let's yet again bring up the video proof that shows it is possible to press left+right on console without controller modification.
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
AnS
Emulator Coder, Experienced player (727)
Joined: 2/23/2006
Posts: 682
Mothrayas wrote:
Link to video We've gone over this so many times I've lost count about halfway through. Let's yet again bring up the video proof that shows it is possible to press left+right on console without controller modification.
Wait, does this video claim that L+R was achieved by quickly alternating Left/Right? Because it's really hard to see what's going on there. To me it looks like the guy bends D-Pad by pushing Left + Right with both thumbs at the same time, so both buttons are actually being pressed at the same time (and no "fast alternation" bullshit).
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
^nobody said anything about fast alternation in that vid… he just presses left and right at the same time with 2 thumbs
AnS
Emulator Coder, Experienced player (727)
Joined: 2/23/2006
Posts: 682
ALAKTORN wrote:
^nobody said anything about fast alternation in that vid… he just presses left and right at the same time with 2 thumbs
Yeah, sorry, got a bit annoyed by several people on the forum repeating the same supposition.