Super Mario World is a game which needs no introduction. Many people have tried and studied this game, and their skill and knowledge are still growing although almost twenty years have passed since it got released. Now
the currently published run is beaten by 4.5 seconds, which I never believed when submitting it.
Game objectives
- Aims for fastest time
- Takes damage to save time
- Abuses programming errors
- Emulator used: Snes9X v1.43+ v16
This run gives an improvement of 269 frames, and consists of two of big improvements and many of minor improvements. One of the two is a dragon coin glitch idea in yi3, which has been dreamed for at least one and a half year and had not been available until May of 2009, because we had no way to duplicate turning blocks fast enough without hitting the message box.
We want to thank all the members of #TASers; this run would not be completed without their cheer.
Tricks used in this run
In this section, I'm going to explain dragon coin glitch, “double hit” trick, “cancel rise” trick, subvelocity, “passing through corner” trick, “pressure of solid objects” and block duplication away from blocks. In addition, I will mention what we know about lag (both in-level and fadeout).
Dragon coin glitch
A dragon coin can be cut by duplicated blocks, and we can get its upper-half (sometimes lower-half) piece. Then an invisible block is produced. This block is indeed a “wing-balloon-shell-key” block. This glitch is very powerful because it leaves us possibility to short-cut a long level such as an auto-scrolling one.
Block duplication
When we duplicate a block using an item, the item needs to be with x velocity 0 and go into the block by at least 7 pixels from its bottom, and the position of the duplicated block is determined by the direction to which the item is pushed. If the item goes into the block by 15-16 pixels from the bottom, the block is duplicated to the above, and if the item goes into the block by 7-10 pixels from its side, then the block is duplicated to its side; if both are satisfied, the new block will be generated above-diagonally. But note that oscillation of items in a solid object affects whether we succeed block duplication to the side or not.
A variant: duplication away from blocks. Block duplication can be done with an item thrown up away from blocks. As explained above, an item needs at least y speed 97 in order to duplicate a block. After throwing up an item, its y velocity moves in the sequence: -112 -109 -106 -103 -100 -97 -94, so there remain only 7 frames in which it can go into the block by 7 pixels after it gets thrown. The following table shows when you should throw up an item to get block duplication; distance means “how far an item is from the block”, and subpixel “subpixel of the item”.
| distance | 0 | 7 | 13 | 14 | 20 | 26 | 27 | 33 |
|---|
| subpixel | 00-F0 | 00-C0 | D0-F0 | 00-60 | 70-D0 | E0-F0 | 00-10 | 20 |
|---|
A variant: duplicate a turning block by dropping an item. In the case where a turning block is on the ground (or a block),
we can duplicate it by dropping an item in such a way that it bounces off the ground just before the block stops turning.
Get two items from one block
If mario and a shell make a hit at a block at the same time, we can get two items. There are many other ways in which we can get multiple items from one block. See also
ISM's demo.
A variant: Get two yoshis. Producing two yoshis at the same time shortens yoshi's growth motion by 32 frames (each of them decreases the growth timer 7E18E8 by one per frame, and the timer starts from 64). Using a triple hit we can shave off 10 more frames, but many yoshis might produce much lag, so we will get less advantage in many cases.
A variant: Rapid duplication of turning blocks. When we want to duplicate turning blocks many times, we must wait for the duplicated blocks to stop turning. To avoid this, by hitting four other turning blocks, the duplicated one stops turning. This however takes many frames, for example when without caped. We can shorten this routine by using double hits; each double hit produces two turning blocks, so we have only to hit them two times in order for the duplicated block to stop turning. This is useful when combined with a dragon coin glitch.
Pass through a corner
We can go into a block by passing through its corner in an appropriate way. This glitch has already been explained in
my post in the forum. Keep trying again and again, and you'll be able to get it with little pains!
(horizontal) pressure of solid objects
When mario is in a solid object, it pushes him to the left (or to the right sometimes). We can abuse this pressure to get a boost:
- The well-known corner-boost is one of variants of pressure abuse.
- By passing through a corner, we can get a boost. Moreover, if we are going to the left, we can pass through two blocks or more as in the second room of dsh.
- If mario jumps toward a ceiling (or a block) with ducking and the takeoff meter is still positive, mario's head sticks into the ceiling, which pushes mario to the left or right. So we can sometimes get a boost. This is used in the dark room of Front Door for example.
How to cancel a rise
Although this is partially explained in
my reply, I would give a self-contained explanation here for the sake of no ambiguity. Assume mario is flying to the right. When he starts going up after an air-catch, mario needs to be facing to the right (even while cape-spinning; watch mario's facing direction
7E0076), so we can cancel his rise by manipulating cape-spin timing in such a way that he ends up facing to the left, and then he can still go up soon again unless his y speed exceeds a particular value (depending on which the air catch is normal or higher). This trick can also be done by making mario's x velocity nonpositive after an air-catch. In this run, this trick is used here and there, especially in bowser fight, where we try to stay at a fixed position for example.
A variant: continuous air-catch. After putting mario into the diving animation, we can cancel a higher air-catch by making his velocity nonpositive. But as explained above, he can still catch air soon, so by making his velocity positive again he restarts going up. Iterating this process, he gets “continuous air-catch”. This is useful in such cases that we want to go up soon after entering a door (e.g., after entering the first door of dgh). This trick also eables us to get a
“fly stuck to the ceiling” trick from a lower position.
Subvelocity
Subvelocity 7E007A (of x direction) is the fractional part of x velocity, which is used only for calculation of acceleration (and deceleration). For example, both of going with velocity 48 and going with 48.5 give the same result. This explains mario's irregular acceleration and deceleration, and is useful when we want to optimize 6/5 in slippery levels where the 6/5 is no longer optimal (it is better to use something like 6/5/26/13 (average speed 48.68627...) rather than 6/5, which is however in such ideal cases as there are no slopes, no enemies, no pits, and so on, so it should be done case by case).
A variant: －1 trick (a.k.a. turnaround trick)
I had to explain this in the previous run, but
Chef Stef has given it; I should like to thank him. :) Similarly, we can optimize mario's acceleration when turning actually (e.g, before grabbing the feather in dp1). For example, a sequence “－14 －9 －4 1 3 4 6 7 9 10” gets into “－14 －9 －4 －1 4 5 7 8 10 11”, and so on.
How to reduce lag
We have to reconsider lag occurrence, and the
current description of lag seems to be neigher sufficient nor essential. Anyway, I'm going to write down what we know about lag, although we are still away from complete understanding.
First of all, there is no doubt that lag (both in-level and fedeout) depends on any processings such as sprites' actions, moving layers, fadeout, etc. So if we want to reduce lag, we have to manipulate any of them. But we historically know lag should depend also on score. Why? The game must do sorta many processings around scores; the score is kept in memory addresses as a hexadecimal value, while the score drawn on the screen is decimal, so the game converts a hexadecimal score into a decimal score every frame. I think this conversion makes dozens of processings and thus a large score amounts to increase lag. For the same reason, mario's lives and coins could also increase lag. In order to manipulate lag, it seems enough to hold down the sum of the digits of the score, and the second digits of coins and lives (or also their first digits, but I'm not sure).
Because heavy control of scores, lives and coins often keeps smw runs away from being entertaining, it should be traded off for entertainment. The smw any% run is not the case, though.
The number in each heading (except for yi2 and yi3) indicates how many frames are saved compared to the previous run, without counting the change of fadeout lag. The numbers in the headings of yi2 and yi3 are those of frames saved between entrance into the current level and into the next.
This spreadsheet may also help you.
Yoshi's Island 2 (－158)
We get yoshi in this level in order to use the dragon coin glitch in the next level. Producing two yoshis at the same time shortens yoshi's growth motion by 32 frames (each of them decreases the growth timer 7E18E8 by one per frame, and the timer starts from 64). Moreover, we try to get less coins to reduce fadeout lag of iggy fight. We lose 158 frames before entering yi3.
Yoshi's Island 3 (359)
The main part of our improvement; it took over 30,000 rerecords to optimize this level. It was a revolutionary idea to use double hits to dulplicate many turning blocks, and the discovery of block duplication away from blocks enables us to avoid hitting a message box and getting a dragon coin even when they are near blocks we want to duplicate. In order to keep p-meter until getting yoshi off, we use 6/5 and platform-boost. We get 359 frames (and totally 199 frames) before entering yi4.
Yoshi's Island 4 (0)
No change.
#1 Iggy's Castle (0)
No change. But in this level, we found that the number of coins we get has to do with lag. It was after almost completing movie that we noticed this fact, so we redo yi2 through C1 to regulate the number of coins. After we changed it from 66 to 35, 4 frames of fadeout lag were shaved off.
Donut Plains 1 (1)
We fly into some blocks and gain 1 frame. When grabbing the feather, we can indeed get two more subpixels than the movie, but we would obtain no frames. This level, sw4, big boo fight and bowser fight demonstrate the "rise cancel" glitch and its variants.
Donut Secret 1 (1)
There is no change except in the extra room, where we get flight speed 51 and swoop after catching the shell.
Donut Secret House (5)
In the first room, we save 1 frame by optimizing the way to get through the stairs. In the second room, we fly in turning blocks and add a corner-boost after getting the P-switch; 4 frames saved. The regulation of score restricts mario's action a lot in big boo fight, where I instead make some tetris pieaces. I believe I did well.
Star World 1 (9)
New smashola route due to ISM. If the number of coins were less than 10, we could shave off 2 more frames of fadeout lag.
Star World 2 (1)
We optimize the x speed oscillation just before grabbing the small yoshi.
Star World 3 (5)
New strategy to hit the key box shaves off 5 frames. By using also a grab block (dark blue one) we can hit the key box 1 frame faster than using only the gray P-switch. I think this phenomenon has to do something with their sprite IDs, but I'm not sure.
Star World 4 (1)
The only special thing we do is to fly into a few blocks.
Front Door (55)
I tested various ideas to destroy room #5, and I managed to squeeze under two spikes farther. To get invincibility and flight at the same time, we snag the spike just before the takeoff meter vanishes. Before entering the door to room #2, if the cape spin would have good timing, the ceiling-boost trick might shave off 1 frame.
Bowser (－7)
I found a way to stomp a mechakoopa 3 frames faster than before, but unfortunately, all of this advantage seems to be thrown away because of some frame rule, except in the third phase. Moreover, because we aim firstly for defeating bowser as soon as possible and next for stopping the input, we lose 7 frames in bowser fight as a result. If we would aim for the fastest way to end input,
the movie could be ended in 37298 frames.
The mechanism of the above method is as follows: when touching a sprite, its hitbox vanishes for some frames (this value is individual for each sprite; the memory addresses 7E154C-7E1557 are the timers). For the bowser case, its hitbox vanishes for 32 frames, so we can stomp a mechakoopa during the while, without damaged.
Suggestive screenshots
5997, 19513, 29725.
Nach: Accepting this lovely Tetris homage, as a nice unexpected improvement to an existing run.
