Submission Text Full Submission Page
Okay, I was definitely not expecting this.
This movie aims to get to the final credits in the smallest amount of time. It does this, through major glitching in 2 minutes and 39 seconds. It's *almost* short enough to be played with my old movie and still be shorter than Soulrivers' movie. Unfortunately, it's not quite. Maybe next time. (it is now) This time, mario and wario don't even meet, and he still takes back his castle.
Last time, I thanked MUGG right at the start. This time, it's not quite enough. Because he found the glitch itself and helped me enourmously with route planning and other stuff, I'm listing him as a coauthor. Unfortunately, none of his input is in the final movie, but he still put in enough effort to be listed as an author.

General comments

I'm not really sure whether or not this movie should obsolete the old one. Allthough they are technically both any%, they are sufficiently different enough to warrant separate publications until a 100% run comes along (Also, the old any% is pretty similar to a 100% anyway).
So here's how it's done. You need to manipulate the byte at address 0xA2D5 to 0x60 from 0x00 in order to set the credits as the next level. Then, the next time you go into a level, the credits will roll. The end!
In Super Mario Land 2, every block represents a byte in memory. Normally, the level is stored in the 0xC000 - 0xDFFF range, but if we go out of bounds we can see other parts of memory as if they were a level, albeit a very glitchy looking one. Basically, I have to bury mario deep enough into the garbage up until the point where I can jump and crush the block that represents 0xA2D5. Once that's done, I quit, and restart the level, and hey! credits roll!

Detailed comments

introductory stage

Should be prety straightforward huh? Not really. I use a speed trick which requires mario to repeatedly hop through the whole level. Mario gets 1 pixel boost every time. I mention this trick in the comments for my last run, so I'll just copy it here:
The "new" pixel trick
This idea came about when I was trying to prove that the maximum time possibly saved using the pixel trick would be 1 pixel every 8 frames. The problem boiled down to whether or not you could change the number at A200 from D0 to CC in exactly four "moves" using only +4, -4 and -C, OR +8, -8 and +0. This is quite obviously impossible, as no matter how many times you apply +8, -8 and +0, you will never change D0 to CC, and if using +4, -4 and -C, you can only reach CC from D0 in odd moves. This seemed like case closed to me until I realise that if I could use all of +4, -4, -C +8, -8 and +0, the problem was gone.
Although the above paragraph makes little sense, let me try to explain. D0 and CC represent different 8 frame oscillations. If I were to be able to change between D0 and CC in exactly 4 frames, then I could save 2 pixels per 8 frames. On land, I can add or subtract 4, or subtract C from D0 once per frame. In the air, I can add or subtract 8, or keep the value the same once per frame depending on what buttons I had pressed. Normally, It would be a fair assumption that it would be impossible to be on land and in the air at the same time, so it would be fair to say that I couldn't use +4, -4, or -C along with any of +8, -8 or +0. This is of course false. If I decide to jump during the period of time where I am changing between D0 and CC, then I have the opportunity to use all of +-4, +-8, -C, and +0 within that window of time. Similarly, landing on the ground presents a similar opportunity. This would mean that I could save an entire pixel every time I jumped, much like the moonwalking technique described above
This would logically mean that I would necessarily be jumping around as much as possible all the time. Perhaps in the future a run with this technique can be used, but for now, I enjoy the relative freedom of using a slightly outmoded version.
I must admit, I use this trick ONCE in the run: in pumpkin zone 1 near the end, it allows me to land on an odd numbered frame. However, this was just luck, and I had no real idea what had happened. I actually discovered that it could save time much later on.
twice I abstain from doing this trick in this level because it caused more lag than time saved.

Pumpkin Zone 1

Getting the mushroom without slowing down is pretty cool.
Not a particularly long level, but I have to complete it so that I get the ability to exit that level at any time. which is required for the pipe glitch. I get a turnip, because flying with turbo A induces significantly less lag than jumping and doing the pixel trick. Getting the turnip and losing it wastes no time at all.

Pumkin Zone 1 pipe glitch setup

Very simple and short, I get the fireflower for some maneuvering in the garbage, and then I exit the level using start/select.

Pumkin Zone 1 garbage

Route planning is the major difficulty here. I have an accurate map for the first 64 rows, but for the next 100, I'm on my own. The route for the first 64 rows is designed to stay as close as possible to the left, Because it's faster to go left, and let the game's horizontal position overflow than it is to go right and get to 0xA2D5 directly like in mugg's testrun. The game has a tendency to make mario move right, because that's the way mario is ejected once inside a block.
The first 64 rows were pretty simple. I had a map, so I could just make some theories and test them. The number of routes is pretty limited so it was easy to test. There is also no weird camera movement, and the blocks shown are actually what they look like, unlike the next 64 rows. There are also very little programming errors to abuse here, apart from a weird behaviour that if you fireball a fire block, you can't fall downwards unless mario jumps. I use this once so that I don't have to duck while going down a pipe.
The next 64 rows represent ROM that is bank-switchable. That means that if I perform certain behaviours, I can completely change the level layout. One behaviour frequently used is B + ^, which changes the bank number, which can be used to fall through some floors or insert solid objects in the way of marios path while in the "pipe" animation, so that he will continue to be ejected. It means mario can fall through floors because I switch to a level layout where there is no floor, and then switch back to the original layout.
The basic strategy here is to go to the left until Mario is over 0xA2D5 using pipes, because going left in a pipe is faster than running (2 pixels per frame compared to 1.625 which is the speed of running with the pixel trick), and then falling to the end. The last pipe I found was excellent for this purpose. It goes left for as long as you want it to, (it is so long it can almost take Mario back to where he started!) and has many places Mario can exit using B + ^. it is also situated directly above a large recess, so Mario can fall almost straight to 0xA2D5, with a few stops along the way. I think I found a good route for these rows. Too far to the right, and you have to go even further to the right to get to 0xA2D5, Otherwise, you would have to go as far left as I did anyway in order to get down to 0xA2D5. Overall, even though I didn't have a map for this part, I think there is the possibility of 1 or 2 potential improvements, and minor ones at that (I don't know of any improvements, I'm just saying, they could be there).
The last few rows of garbage are pretty simple This part of RAM represents graphics of blocks. Break a few blocks and you're at 0xA2D5
Well, hope you enjoyed the run!

mmarks: Ajusted resolution

Nach: Judging.

sgrunt: Replaced the submission file with a 121 frame faster version.

Flygon: Added YouTube module.


Editor, Experienced player (570)
Joined: 11/8/2010
Posts: 4038
Amazing! Voting Yes for sure!
Skilled player (1742)
Joined: 9/17/2009
Posts: 4986
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
If the 100% run will be very similiar to the any% run, then I agree with obesoleting the current any%. Yes vote for such a discovery. andymac and MUGG, you guys are amazing glitchers! =D
Personman
Other
Joined: 4/20/2008
Posts: 465
This is glorious.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Patashu
He/Him
Joined: 10/2/2005
Posts: 4045
Excellent.
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
Joined: 6/4/2009
Posts: 570
Location: 33°07'41"S, 160°42'04"W
I'm afraid I have to bring up a question, after looking at a pic posted by MUGG: It appears you navigate through the ROM. That's fair and understandable. However, do you break any block while in the ROM area? Because, that would be equivalent to writing to ROM, thus making it an emulator quirk and unreplicable on real hardware.
Joined: 12/10/2004
Posts: 82
Location: Ruotsi
Was not this submission rejected because of the glitch this movie is using?
Editor, Player (44)
Joined: 7/11/2010
Posts: 1029
Tafatt wrote:
Was not this submission rejected because of the glitch this movie is using?
It was rejected because the emulator didn't emulate the glitch correctly, which obviously makes the run impossible on a real console. The emulator has been fixed since, so it now emulates the glitch correctly; it turns out it's still possible, but slightly different. So runs using this glitch with a recent version of the emulator are allowable, and runs using the old broken emulation aren't.
Emulator Coder, Skilled player (1114)
Joined: 5/1/2010
Posts: 1217
Noob Irdoh wrote:
It appears you navigate through the ROM. That's fair and understandable. However, do you break any block while in the ROM area? Because, that would be equivalent to writing to ROM, thus making it an emulator quirk and unreplicable on real hardware.
At least on emulator (don't know about real hardware) the game reportedly instantly locks up if you break any block on ROM area.
Tafatt wrote:
Was not this submission rejected because of the glitch this movie is using?
No, there are two glitches. One is real, one is emulation problem (since fixed). The pipe glitch itself is real and lets one access out of bounds areas. The emulation problem was that GB can map the same memory in multiple parts of its memory space. On real GB, writes to one area are immediately visible in others. On older versions of VBA, only the copy that was written changed, the others didn't. This caused the game to behave differently, letting one to end the level early in a way that is not possible in real hardware.
Dwedit
He/Him
Joined: 3/24/2006
Posts: 692
Location: Chicago
D000-DFFF is normal RAM, E000-FDFF is "Echo Ram", a mirror of RAM (this is what the old VBA screwed up emulating), and then... FE00-FE9F Sprite Attribute Table (OAM) FEA0-FEFF "Not Usable", not sure what you'd get when accessing this, maybe open bus? FF00-FF7F I/O Ports, some are readable and writable, other are read or write only FF80-FFFE High RAM (HRAM) Works just like normal RAM. With the exception of High Ram and maybe certain IO ports, this stuff may not behave consistently. For example, reading OAM during rendering is highly unreliable, and you'll probably get different results every read, and not just from the different frame-by-frame contents of the sprite tables. The real question is which bytes are Mario coming into contact with, or checking collisions with, and at what timing? Just saying, because this might not be 100% replicable on other emulators like BGB. But we don't scrap runs that require the timing of a a specific version of FCEU to run correctly or they desync. The emulator here's not doing anything flagrantly wrong, like providing extra RAM for the echo ram, this is just up to emulating timing and render-time video memory/io reads correctly, which is tricky because games just don't do these things during render time unless they've glitched.
Experienced player (642)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I'll describe the garbage in more detail. The first two rows are the last parts of adressable data (FE00-FFFF) The first row that I pass is OAM. You will notice that I throw two fireballs before going into the garbage data. This is necessary to manipulate the blocks in the first row (the OAM) to be solid or empty when necessary. In my previous movie I manipulate on screen fireball positions and mario's position to be 4A or 4B, which corresponds to an exit. So yes, the first two rows constantly change. However, their graphics on screen don't change unless they go off screen. In the next 64 rows (0000-3FFF) if you break a block, it crashed the emulator. I'm not sure what happens on a read GB, but I'm sure it will either reset or crash the game. So I dont do it. However you can shoot a fireball at a fire block, and it will go through the destroying block animation, but it will still be there afterwards, and you can shoot it as many times as you like. I mention this in the submission comments. in the bank switchable ROM (4000-7FFF) I don't break any blocks, but I do use B + ^ a lot to go through some floors (pressing B + ^ changes the layout of the level instantaneously, so some blocks which were solid were then empty, and mario could fall through them). You can hit blocks in this area, and they will break, but they will still be there afterwards. I wasn't sure if this was the same as a real GB, so I made sure not to break blocks in this area just to be sure. The final part of ROM that I go through I break as many blocks as I like. This is the WRAM (8000-9FFF) and stores all of the tile data and graphics. By breaking some blocks, you can get really weird looking graphics. For example I broke one block which put a large dark pixel in the corner of mario's sprite. However, none of these constitute an illegal write (because they are in RAM). Then A2D5 is just three blocks underneath the floor. This changes some save data, and an empty part of A100 and then the block which triggers the credits. Again, no illegal writes because it's RAM, and this RAM is usually general purpose anyway.
Measure once. Cut twice.
Editor
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
A Mario run that is more buggy then a Sonic run? Yes vote due to breaking the boundaries of the game and making the game throw up the ending in despair.
When TAS does Quake 1, SDA will declare war. The Prince doth arrive he doth please.
TASVideosGrue
They/Them
Joined: 10/1/2008
Posts: 2791
Location: The dark corners of the TASVideos server
om, nom, nom... crunchy!
Dwedit
He/Him
Joined: 3/24/2006
Posts: 692
Location: Chicago
In theory, what's supposed to happen is that when you read from OAM or PPU during render time, you instead get what the PPU would be fetching, and I don't think that's being emulated. Not sure what writes would do. Writes to the ROM area are mapper writes, so they perform bankswitching or enable/disable cartridge RAM, so naturally they crash the game.
Joined: 11/14/2010
Posts: 9
nice theory! great run!
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
TASVideos Grue wrote:
om, nom, nom... crunchy!
why?
Editor, Expert player (2331)
Joined: 5/15/2007
Posts: 3940
Location: Germany
Improvement is coming up...
Patashu
He/Him
Joined: 10/2/2005
Posts: 4045
If you can change the graphics, could you make a playaround run that edits mario/enemies/scenery into funny things? How much can be done with just breaking blocks?
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
Dwedit
He/Him
Joined: 3/24/2006
Posts: 692
Location: Chicago
Graphics changes would expire when you change areas.
Player (118)
Joined: 5/13/2009
Posts: 700
Location: suffern, ny
I really liked what I saw, very entertaining. YES VOTE
[19:16] <scrimpy> silly portuguese [19:16] <scrimpy> it's like spanish, only less cool
GabCM
He/Him
Joined: 5/5/2009
Posts: 901
Location: QC, Canada
Can't wait for the improvement to be submitted!