Latest revision as of 02:57, 15 May 2026

Introduction

This page is for TAS (Tool-Assisted Speedrun) tricks. Check out the introduction page on TASVideos.org or this Youtube video for more information on what a TAS is.

If you want to start TASing, you'll want to download this .wch file and open it with RAM watch in your emulator. This will allow you to see a bunch of important values like velocity and position, which will be used a lot while TASing.

Also check out the TAS guide and the YI page on TASVideos for more info. specific to Yoshi!

For the sake of clarity:

Let < and > denote left and right directional input.
Let ^ and v denote up and down directional input.
Let _ denote no directional input.

One pixel contains 256 sub-pixels (0-255). This number is used within the RAM to achieve more precise positioning. One frame means 1/60th of a second or one click on frame advance. Keep in mind every input has a delay of 3-4 frames before Yoshi responds to it.

Movement

Speed

Yoshi's speed (x-velocity) when running varies between 3 different values. Without slope oscillation these values should be either "736, 752 and 768" or... "744, 760 and 776". These numbers are sub-pixels per frame. Yoshi's speed cuts off once you travel faster than 3 pixels per frame, which is 768 sub-pixels.

Keep in mind that velocity doesn't guarantee that you travel that particular distance, it's only there for calculations in the RAM.

Most of the times you want to see the number 760-767, to achieve the 760 speed when you are at 752 just throw in one < somewhere among the inputs(this should be done as early as possible).

To maintain your speed while facing backwards use the following input:

< > > <

This will reduce your speed by 56 for one frame and then add 56 speed two frames later for one frame. If you want to tounge backwards the Y button should be pressed after the last directional input to avoid speed-loss.

Slope Speed Oscillation

Running on slopes aren't always a disadvantage, as slopes can reduce your speed so it doesn't multiply by 8. This means speeds above 760 are achievable by running on slopes for a brief amount of time. Running at an average speed of 767 compared to 760 saves about 1 frame every 100 frames.

1/1 Running

The TASers at TASvideos decided to ban this trick for some TAS projects, keeping entertainment value in mind. This trick involves pressing < > every 2 frames after reaching the optimal speed oscillation, varying the speed between 2 numbers rather than 3, going 56 sub-pixels faster every 2 frames compared to just holding >...

Doing this trick at 767 x-velocity would save about 3.5 frames every 100 frames.

Here are the comments regarding this trick in the 100% TAS:

"The final restriction we made is on the 1/1 running trick, named after 1/1 swimming in SMW. This trick basically makes Yoshi run slightly faster than normal at the cost of alternating between pressing < and > every frame. The problem with this is that whenever you lick eggs you must release < and > on the dpad or you will lose speed. Only licks that occur for 1 frame are possible without any speed loss. This severely limits the entertainment possibilities, as modern Yoshi’s Island has become all about cool egg shots and juggling things. The constant wobbling may also be irksome for some. Rather than arbitrarily losing time on cool egg shots, we decided to simply ban this trick outright. Note that this also applies to other input sequences that can be repeated constantly to obtain a higher average speed than 767 sub-pixels per frame (1/1'ing is just the prime example). As before, we disallowed this with entertainment in mind, and the frames lost from not using this trick are hardly visible anyway. This is the only time speed was sacrificed for entertainment."

Acceleration

The optimal acceleration input when Yoshi is at a complete stop, also with jumping arrows is: < > > > > < > > > < > > > < > > > < > > < > ...

After the last > continue holding > until Yoshi's speed is at max. This acceleration method gets to 760 velocity speed in 29 frames. While regular acceleration (just holding >) gets to 752 velocity in 49 frames.

Coming out of a flutter the optimal acceleration method is the following input 8 frames before ascending sprite appears: < > > < > > > < > > > < > > > < > >

After the last > continue holding > until Yoshi's speed is at max. This acceleration method gets 8.064 pixels further than just holding > in a lap of 40 frames.

Or use this macro for multiple flutters:

+B..................................................<>><>>><>>><>>><-B>

However you have to adjust the flutter x-velocity yourself since it cannot loop, do this by adding more > after -B, using the overwrite option (for Snes9x).

Stopping/Turning Around

Tonguing a wall or roof is the fastest method for turning around and stopping. The x-velocity instantly drops to 0 and you can start the acceleration inputs 3 frames before you see the 0 value.

When running at full speed and you want to turn around, use the following input: v v v > > > > ... and start the acceleration method.

When falling off a ledge and you want to turn around, use the following input 7 frames before the falling sprite appears: _ v v v+> > ...

After the last > continue holding > until Yoshi's speed is at max. This will show a ducking sprite while falling and it is recommended to jump 4 frames before landing to prevent slowdown from the ducking. However you cannot ground pound while performing this trick.

When landing and you want to turn around, use the following input 4 frames before landing sprite appears: v v v > > > > > > ... and start the acceleration method.

Wall-Jumping

Basically you have to go at least 768 sub-pixels or 3 pixels into a wall on a tile boundary(every 16 y-pixels).

To do this you have to make sure the frame before you hit the wall you are at for example .213 pixels travelling at 808 sub-pixels per frame by using the < > > input, that example will get you 3.001 pixels into the wall, and if you are at a tile boundary Yoshi will show a standing sprite for 1 frame, press B 3 or 4 frames before that to get the jump.

To get the right Y-position just vary releasing B from the flutter or jump for different frames.

In this there is a demonstration of a wall-jump. Take a close look at the numbers and it should be clearer, the wall is at 1984 x-position. I know that because I tested it by bumping into the wall and stopped at 1984.255. Keep in mind this guy did the < > > input 1 frame earlier than he's supposed to, that means he doesn't benefit from the greatest velocity. However he still made it 3 pixels into the wall. Let's do the math! Already at frame 6716 we can do the math to find out we will go 3 pixels into the wall. Look at "X Position 2" and "X Sub-Pos 2", it means the next frame you will be at 1984.247 which is right before the wall. Look at the "next speed" which is 791. How far is 3 pixels? 768 sub-pixels right? So we subtract 791 by 768... 23! And how far away were we from the wall at that frame? We subtract 256 by 247 to find out.. Which is 9!

So now we just subtract 23 by 9 to find out just how far into the 3rd pixel of the wall we will go. And that is 14 sub-pixels. So if we just press frame advance once we can see now that the "X Position 2" and "X Sub-Pos 2" becomes... 1987.014! Just like we predicted!

Getting the right sub-pixels can be tricky sometimes, and you will have to try different combinations of <, _ and > to get the right number. Always make sure you're doing the < > > input at the right frame while testing this. If you don't have enough space on the re-record to fully accelerate before the wall when doing the inputs to slow down then you have to go back further in the movie and do the inputs there. It is also recommended to release all directional inputs, freezing at a good velocity a lot of frames before the wall, leaving space for slowdown inputs.

Good input sequence loop for multiple wall-jumps in one wall, basically replace the ">" in the "Strike Through" part to adjust 16 pixels or carefully edit the "9 _'s".

(<+B) > <<< > <<< > <<< > <<< > <<< > <<<<< _ _ _ >>(>-B)>(>+B)>>>>>>>>>>>> (its 17 >'s) < >>> < >> < _ _ _ _ _ _ _ _ _ (9 _'s) < >> ~~_ _ _ _ > _ _ _~~ < >> < >>> < >>>> < >>(>-B) (<+B the beginning again)

Note that this might not always be the optimal way, its just a consistent way to save rerecords.

Practical wall jump guide

Note:

“speed” refers to horizontal speed, measured in sub-pixels per frame and presented here in decimal. Sorry for those who prefer hexademical, but I learnt how to TAS before I knew what a hexadecimal was.
Most of the numbers here assume that Yoshi is moving to the right with an average speed of 760. The principles all apply to other speeds though (e.g. 767).
If Yoshi is moving to the left, then just mirror everything.

To perform a wall jump (WJ), Yoshi must move 3 pixels (256*3 = 768 sub-pixels) into a wall. This causes Yoshi to enter a “standing on the ground” state for one frame, during which it is possible to jump. Yoshi therefore needs to attain a high speed (>768) on a frame where he is very close to the wall. More precisely, if Yoshi has speed V while at a distance D away from the wall, then we need V > 768 + D. Wall jumps can also only be performed at vertical tile boundaries, which occur every 16 pixels. The conditions on Yoshi’s vertical position, however, are much more relaxed. As long as Yoshi is reasonably close to a tile boundary, he will “snap” to the correct position, provided that the horizontal condition is met.

Achieving a large speed for a single frame is easy. If Yoshi is running at 760, then the input sequence <>>> produces a frame with a speed of 816, which is more than enough for a wall jump. More generally, this large speed will be 56 higher than Yoshi’s average running speed. The challenge is making D small enough, which requires precise control of Yoshi’s speed as he approaches the wall.

The simplest and most common scenario is when Yoshi approaches a wall at full running speed from far away. This case is the easiest as there is a lot of time to adjust Yoshi’s speed before he hits the wall in order to minimize D.

First, run into the wall and note what horizontal position (pixel, not sub-pixel) Yoshi is at when he stops. We will call this X. Whatever it is, we need Yoshi to reach X+3. For example, if Yoshi stops at 1430, then our goal is to get to 1433.

Now approach the wall for real. I recommend jumping early and releasing > so that Yoshi’s speed is fixed at 760. If you’re aiming to wall jump high on the wall, time the jump so that Yoshi hits the wall at roughly the apex of the jump. The exact height of the jump can always be altered later.

Find the last possible frame (we will call this frame N) on which the sequence <>>> achieves the speed of 816 (we will refer to 816 as V now). N is correct if doing <>>> on frame N+1 doesn’t attain V. If you are very lucky, executing <>>> on frame N will reach X+3. In this case you already have a WJ and don’t need to do anything else. You should see Yoshi enter the standing animation for one frame. If you don’t see this, it means your vertical positioning is off and you should adjust your jump. The simplest way to do this is just to try releasing B on different frames.

In the majority of cases, doing <>>> on frame N will not reach X+3. Instead, it will usually reach X+1 or X+2. In any case, it means that D was too large. Since you can’t move any faster (if you could have, why didn’t you already?) the only option is to slow down. The goal now is to slow Yoshi down by as little as possible so that the sequence <>>> achieves V when executed on frame N+1.

Go back to the start of the jumping approach with > released and Yoshi’s speed locked at 760. The goal now is to try slowing Yoshi down by different amounts and checking if executing <>>> on frame N+1 achieves V. Note that achieving V doesn’t guarantee the WJ, as it is possible to slow down too much so that D is now too large again. You'll know if this is the case or not by monitoring Yoshi's position: remember we're aiming for X+3. It is required that we slow down by as little as possible, so that achieving V from <>>> on N+1 only JUST occurs and would not have occurred if Yoshi had slowed down even a little bit less. In reality there is a bit of leeway, but this is the mindset you should have.

There are two simple ways to slow Yoshi down. For very fine adjustments, press > for a single frame during Yoshi’s approach. After a few frames, his speed will settle on the lower of the 3 usual oscillating values (744 if his average speed is 760). You can then coast at 744 for as long as needed, effectively losing 16 sub-pixels each frame relative to coasting at 760. To get back to full speed, simply press > again.

If you need to slow down by a larger amount, you can instead use any of the following input sequences (the number of the right shows how many sub-pixels they lose relative to coasting at 760):

<> = -56
<_> = -112
<_ _> = -168
<<>> = -224
<<_>> = -336
<<<>>> = -504

An underscore _ denotes a frame with no directional input. These sequences have the property of bringing Yoshi back to speed 760 at the end. Other similar sequences probably exist, but I find these to be sufficient. They can be inserted during Yoshi’s jumping approach to the wall at any time and in any combination. You don't necessarily need to remember the numbers. Just remember the order of the list.

A simple trial and error strategy might look like this: do sequence (6) enough times so that once more would slow Yoshi down too much. Then move to (5) and do that enough times so that once more would slow Yoshi down too much… and so on, working up the list, gradually getting closer and closer to the WJ condition. In practice it’s rare that you’ll need to use all of these. If you find that even (1) slows Yoshi down by too much, then you should instead use the 744 coasting strategy.

Consider the following example in 2-2. I would like to WJ on the pole to the right.

I first ran into the pole and found that X = 2256. My aim is thus 2259. I found from simple trial and error that executing <>>> on frame 158 in my movie was the last frame that achieved a speed of 816. My goal is thus to execute <>>> on frame 159 and slow down so that I can still achieve 816. My final set of inputs looked like this

Frame 125 is where I began my jump and released >, locking my speed at 760. Frames 159-162 is the <>>> that achieves 816 to get the WJ. Note that I release B on frame 161. This is so that Yoshi actually jumps! Frames 134-143 are the inputs I added to slow Yoshi down. While they may look random at first, they are nothing more than instances of the fixed sequences discussed earlier. In particular, frames 134-139 are (6) from the earlier list, i.e. <<<>>>, and frames 140-143 are (5) from the list, i.e. <<>>. I found this particular combination of inputs as follows:

First I tried using (6) once and found that this did not slow Yoshi down enough (I did not get 816). Then I tried using (6) twice and found that it slowed Yoshi down too much (I got 816, but I did not get a position of 2259) Then I tried adding (5) after one (6) and found that it worked.

If this set of inputs did not slow Yoshi down enough, I would have tried adding a (2) after the (6)(5). Note that there’s no point adding a (4) or (3), as this would end up being at least as much slowdown as (6)(6), which I already know is too much.

If (6)(5) slowed Yoshi down too much, I would have tried (6)(4), and then maybe (6)(3) etc.

Ceiling Clip Walljumps

Speed Altering Inputs

Using these while accelerating will not work.

Adding _ will freeze your velocity in most cases, but not always.

This table is meant to make it easier for TAS'ers to perform a wall-jump, by doing the math's instead of guessing different inputs all the time.

Input	Pixels
< > > < > (< to end)	+.056(+.056 per < >'s (1/1 running method))
> _ _ >	-.016(-.016 per _'s )
> < > _ _ >	-.040(-.016 per _'s )
< >	-.056
< < > >	-.244
< < < > > >	-1.248

Object Physics

Pixel Porting/Auto Correction Of Movement

This game has something called pixel porting and movement auto correction like many other games, for example Perfect Flutter abuses this mechanic.

This is the reason you don't really have to care so much about Y-positioning when it comes to wall-jumping (its only frame perfect when to release B, not Y-sub-pixel/pixel perfect).

When trying to bonk your head into the roof with 0 or opposite velocity, you can auto correct you up to 5 pixels by 1 pixel per frame(to the nearest wall), this means you can jump earlier when doing a U-turn upwards.

You can fall off a ledge 3 pixels before the wall ends. Getting 0 or opposite X-velocity will push you out of the wall by 1 pixel per frame. Ledges can increase chances of clipping into walls or wall-jumping by delaying the auto correction and collision by 1 frame.

Having 0 or positive(falling) Y-velocity while traveling towards ledges can pixel port you up to 8 pixels. Releasing B earlier can make you land faster.

Slopes are basically stairs with less than 8 pixel high ledges (that's why your Y Sub-Pos is always 255 when running up slopes). Slopes pixel ports you as long as you have negative y-velocity (moving upwards).

Generally walls will try to push you out of them to the left, when more than 3 pixels inside a wall you can stand every 16 pixels. To clip through a wall with the push mechanic from right to left you have to find a way to travel at least 10 pixels into the wall to avoid auto correction to the right.

Certain objects can pixel port you even further, enemies can also pixel port you.

Eggs

Shooting Through Walls

It is possible to shoot eggs through one block thick walls when standing more than 3 pixels inside it. Only works to the left, however in the 100% TAS they managed to do it to the right on a flower in 3-7 because the flower hitbox was inside the wall.

This basically uses the same method as Wall-jumping except that you don't need to jump.

Egg physics

TO-DO

Huffin' Puffins

TO-DO

Egg RNG(?)

Eggs even with the same color can act differently with the same positioning/conditions. This can make movie editing unsynchronized. This definitely needs some research.

A theory is that it depends on the velocity of the eggs when you pick them up.

Flatbed Ferry's (Platforms)

These handles Yoshi as if he was standing on the ground when standing on them, so Yoshi's velocity will be 0. When jumping off them Yoshi's speed will instantly increase with the platforms velocity. So jumping multiple times on them can be abused to achieve 2048 X-velocity.

Run on these for as long as possible whenever you see one moving horizontally the way you're heading, this will move you further forward, however your velocity wont increase. Of course the opposite for platforms moving the opposite direction.

Sometimes it's possible to gain a boost off them in Y-velocity by doing a Perfect Jump, this is due to them moving upwards for a very small amount of time before going down, an example would be the 3 platforms in 2-8.

Performing a Perfect Jump on a Flatbed Ferry will not eat your flutter.

Stairs

Stairs kills Yoshi's momentum upon landing on them, sets Yoshi's x/y velocity to +/-256(1 pixel per frame) when pressing left or right and pixelports.

It's possible to clip through stairs by:

Travelling over 10 x-pixels, losing under 8 y-pixels between the steps. (Unconfirmed)
Having negative y-velocity to avoid sticking onto the stair, for example fluttering.
Multiple frame perfect Tounguing while holding forward.
Pixel perfect jumping onto another ledge connected to the stair, like in 2-4.

Koopa Shells

Koopa shell abuse in the 100% TAS to achieve pixelport off Spike Ball.

Koopa shells can be used as portable platforms, because you can bounce on them and tounge them back at the same time (frame perfect).

When bouncing on the shell of a Koopa, you become invulnerable for a short amount of time.

Arrow Lifts

See arrow_teleporting for an important glitch.

Arrow Lifts spins in a pattern of 4-4-4-6-4-4-4-6 and repeats from 512 to 0 (512 is 0). They do not appear to affect yoshi's velocity in any way. Performing a [Tricks#Perfect_Jump|Perfect Jump] on an Arrow Lift will not eat your flutter.

Balloons

You can manipulate where they go depending on where you jump on them. Scrolling your screen upwards will also spawn them higher. They don't appear to affect Yoshi's movement except just carrying you upwards.

Seesaw Bridges

TO-DO

Chomp Rocks

TO-DO

Snow Balls

TO-DO

Dr. Freezegoods

TO-DO

Spring Balls

TO-DO

Spinning Platforms

TO-DO

Falling Rocks

TO-DO

Crates

TO-DO

Clouds

TO-DO

Bullet Bills

TO-DO

Bubbles

TO-DO

Buckets

TO-DO

Fuzzies

TO-DO

Penguins

Colliding with a penguin instantly sets your X-velocity to 768. Colliding with it from underneath bounces you down to 1151 Y-velocity. Penguins also cancels your ground pound.

Spray Fish

TO-DO

Big Egg Aiming

TO-DO

Melon Bugs

When colliding with a melon bug while having 0 or the same negative/positive side of velocity(possible with opposite velocity in the air with some angles), it carries over its momentum to Yoshi. This is can be abused to achieve incredibly high speeds by spitting it out and ricocheting it over and over. This was used in the 100% TAS to clip through walls at 4-5.

If you collide with it with opposite velocity in the air you can freeze in X-position but still keep your velocity, so upon eating the Melon Bug or fluttering to get it out of your way, you will carry on travelling at that velocity.

Tapping < for 1 frame when trying to push a Melon Bug to the left will instantly set your velocity to -576.

Terrain

Mud

Yoshi's speed varies between 248-260 when running at full speed on mud. It goes in loops like this 248-254-260-252-258-250-256, giving an average of 254 sub-pixels per frame.

Since it doesn't multiply by 8 this means it's possible to get ~766 speed from this while accelerating without the use of slope oscillation. But generally you wanna keep yourself off mud to avoid speed loss.

Fun fact: Holding the opposite direction to turn around on mud slows you down by 6 velocity per frame while not holding any direction slows you down by 8 velocity per frame. So it's kind of counter-intuitive that holding the opposite direction actually makes you turn around slower.

Perfect Jumping can be used to avoid slowdown.

Snow

Snow makes Yoshi accelerate 8 velocity per frame (2 times slower than normally).

The max speed goes in loops of 608-656 making the average max velocity 640 sub-pixels per frame.

Another fun fact: Same here, holding the opposite direction to turn around slows you down by 8 velocity per frame rather than 48 velocity per frame.

Perfect Jumping will slow you down by 48 velocity, however if you combine it with certain inputs you can avoid loosing speed: "< > > <+B" "< > > B" "<+B >"

Ice

Ice physics causes Yoshi to accelerate 4 velocity per frame (4 times slower than normally) and stopping takes 8 times longer, holding the other direction doesn't make stopping faster, however ducking does.

The max speed varies between 764 and 768 every frame, granting an average of 766 sub-pixels per frame, which is faster than regular running without slope oscillation.

It should be pretty obvious now that you shouldn't be on ice unless you're travelling at full speed without access of slope oscillation to achieve ~767.

To face backwards without loosing speed just tap < once between the >'s.

Water

Water acceleration is 6 velocity per frame (3 times slower than normally).

Landing in water kills all your momentum.

The max speed goes in loops of 381-387 or 382-388 if you jumped into shallow water and started accelerating before it, making the average velocity 384/385. This can be abused to achieve ~766 velocity without slope oscillation.

Holding the other direction to turn around slows you down by 10 velocity per frame while not holding any direction slows you down by 3 velocity per frame.

Usually it's fastest to just flutter over big water pools.

Waterfalls

TO-DO

Transformations

Baby Mario

TO-DO

Helicopter

TO-DO

Car

TO-DO

Submarine

TO-DO

Mole Tank

TO-DO

Train

TO-DO

Ski

TO-DO

Snowball

TO-DO

RNG

TO-DO

Lag

Lag appears when there are too many calculations for the console to handle, the SNES handles this by slowing down the game (producing lag frames) to let the CPU catch up. Notice how the music doesn't slow down during lag, this is due to it running on a separate core.

If you're noticing lag but the lag counter doesn't increase, it's your own computer lagging and not the game. This does not affect recording uncompressed .avis because it captures frame per frame.

There's a lot of lag in this game however due to the differences between emulator and console, this may be hard to research about.

Reducing amount of sprites on the screen or the movement of them can reduce lag.

Stars are a major creator of lag. Any action that creates them (Red egg collision, star cloud, POW block) can result in a couple frames of lag, depending on total sprites on screen. As with manipulating star spawns by doing different button combinations on the frame of star creation, the lag frames can be minimized as well using the same method. Letting go of all inputs on that frame is one way to reduce lag. NOTE: Not all lag frames can be removed. If you still have one or two after a long time spent trying to remove them, it might be worth moving on. Keep in mind that stars doesn't despawn when scrolling them off-screen, so they can still cause lag.