TAS Tricks

Introduction

This is a page for TAS (Tool-Assisted Speedrun) tricks. Check out the TASVideos introduction page for more info or this video.

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

Also check out the Yoshi's Island TAS guide!

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.

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

Pixelporting on a slope in 1-3

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

Egg Clip in 4-5

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.