First off, I've looked into this glitch pretty extensively now and join the crowd in congratulating HappyLee on apparently perfect execution of a new SMB glitch.
Second, I'll build a bit on KirkQ's work and try to give a nice explanation of how this glitch works, as exemplified by this
simple demonstration.
1st, a few memory addresses:
86 - x location, pixels
400 - x location, sub-pixels
57 - x speed, pixels/16
705 - x speed, subpixels
73f - camera x location, pixels
As most will know, getting the pipe in 8-4 to take Mario to the water world requires the screen to be advanced to a certain point, after which Mario can go back to the left and enter the pipe.
SMB screen scrolling behavior when Mario moves right changes depending on where Mario is on screen (x location - camera location):
0-79: no change in camera
80-112: camera advances 1 pixel each time Mario's x pixel changes by 1 or more
112: camera advances the same number of pixels that Mario advances
The result of the behavior in the 80-112 range is that if Mario is moving more than 1 pixel/frame (i.e. speed>16), he will slowly advance on the screen until he is 112 pixels ahead of the camera, i.e. 112 pixels from the left edge.
Further, if Mario is >80 pixels ahead of the camera, he can scroll the screen without net movement by simply walking back and forth by 1 pixel over and over again; this works until Mario gets back down to 80 pixels ahead.
The problem, TAS wise, is that walking back and forth like this is quite slow. One can get a bit faster by carefully setting Mario's x subpixel wiggle back and forth a minimal distance, for example for x location from 103.240 to 104.0; even so, each pixel scrolled takes a minimum of 3-4 frames; very slow since at max walking speed Mario advances 1.5 pixels/frame.
Why is it so slow? Because Mario's normal acceleration is fairly pitiful: less than 1 pixel/frame squared. Thus, the following is what happens with x speed when Mario tries to wiggle w/ x location starting at 104.0:
frame 1: 255.104 (moves 0.16 pixels left) --> 103.240
frame 2: 0.152 (no movement) --> 103.240
frame 3: 1.48 (moves 0.16 pixels right) --> 104.0 (scroll 1 pixel)
frame 4: 255.104 (moves 0.16 pixels left) --> 103.240
Enter the moon-walk. If Mario is walking and holds left+right, rightward acceleration is increased. In a narrow range of x speed sub-pixels, this results in Mario being unable to stop himself despite being on the ground with no input!
frame 1: x speed = 2.48
frame 2: x speed = 1.0 --> 0.16 pixels right
frame 3: x speed = 255.208 --> 0.16 pixels left
frame 4: x speed = 1.0
frame 5: x speed = 255.208
frame 6: x speed = 1.0
...etc
Since Mario's acceleration is 1.48 pixels/frame squared, it is possible to set up such a loop where x speed is never set to 0.xxx, which would stop Mario's movement.
However, such a loop only scrolls the screen in the following conditions:
1. Mario must be >80 pixels ahead of the camera
2. Mario's movement must take him across a pixel boundary
Number 1 sets a limit on how much scrolling is possible without Mario moving: about 32 pixels.
Number 2 makes it so that the behavior is very sensitive to Mario's x subpixel location: essentially, it must alternate between n.240 and n+1.0.
As shown in my demo, no jumping is required for this trick, though it does make it easier to set up the right pixel location since speed remains constant in the air with no input. As KirkQ and my demo's also show, it is possible to scroll the screen either standing on the ground with no input or jumping in the air and alternating left-right-left-right.
A couple final things:
1. Getting Mario's x speed subpixel correct to perform the trick requires him to max out his speed for a while (or possibly press against a wall) and let the x speed subpixel overflow into abnormal values. Simply starting from a stand still, moon-walking, and then stopping will result in normal deceleration back to 0. The target x speed is between 24.192 to 24.232.
2. Intentionally walking at speed 16 (slower than max walking speed of 24) keeps Mario only 80 pixels ahead of the camera and prevents the need to scroll the screen back. Alas, for the distance that needs to be covered in 8-4, too many frames are lost staying slow for it to be worth it (but it's pretty close!)
I hope this clarifies things for ppl in a way that was interesting; it was fun figuring all this out, even though I didn't find a way to get in the pipe any faster.
[/url]
