TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #2971: andymac & MUGG's GB Super Mario Land 2 "glitched" in 02:38.93

Console: Game Boy
Game name: Super Mario Land 2
Game version: USA/Europe v1.0
ROM filename: Super Mario Land 2 - 6 Golden Coins (UE) (V1.0) [!].gb
Branch: glitched
Emulator: (unknown)
Movie length: 02:38.93
FrameCount: 9536
Re-record count: 5816
Author's real name: A. Pritchard & MUGG
Author's nickname: andymac & MUGG
Submitter: andymac
Submitted at: 2011-01-06 14:58:38
Text last edited at: 2011-12-07 13:56:01
Text last edited by: Ilari
Download: Download (1184 bytes)
Status: decision: cancelled
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
Author's comments and explanations:

(Link to video)
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.

Similar submissions (by title and categories where applicable):