Performing An "Upwards Corner Clip"

I put quotes around the title is because the trick in which is done that appears to be an upwards corner clip, but is actually in fact a more difficult variant of a very easy trick: a block clip.

So, what is a block clip?  Well, if the player manages to be on yoshi, and be big, there is a "gap" between their hitboxes.  The gap happens to be ~2 pixels large, and although that number may seem small, that means you have 32 possible different ways of clipping a block from its bottom.
To easily perform a block clip, you can enter donut secret 1, where all that is required is swimming into the bottom right hand corner of a block, aligning yoshi's neck with the corner.  It can also be done from the left side, but it is a lot more precise.

The trick on land is more precise, but still quite easy to perform from the right.

From the left is where the "upwards corner clip" gets its name.  When you are at max speed, you can block clip a block from its left side.  The only way to do so is to gain speed in the air while you are clipping the block at max speed.  It does not require a specific speed, just one that is large enough to shove you through the block.

Jumping like this will allow me to hold down B on one of a couple given frames, and gain height to enter the block and pass through it.  Note that a block clip requires you to be at the block's position and have a y position that is 36 or 37 pixels above the theoretical bottom, so now the trick has become a bit more difficult.

My speed is not 49 here, illustrating that a speed of 49 is not needed in this trick.

SMV Used For This Example

Predicting Duplication

From Far Away

Although it may seem complicated, this trick is actually about as simple as a walljump.  Finding the values for it could be a bit tricky though, unless you equip yourself with a lua script to find them for you (as assumed for all other tricks in which you would need to go through a complex calculation for one result).

For a duplication to occur from far away, all you must do is find whether or not the oscillation of an item will allow it to reach a block's theoretical bottom - 6.  It needs to get here without reaching the theoretical position of the block (i.e. it could get to the theoretical bottom - 6 as long as it did not come to that value by being at the pixel position of the theoretical bottom the frame before (because it stops on that frame)).

The theoretical position of the block will be the cut out 16th part of the block's y position (to make its position a multiple of 16) + 13.  Using this value, all we have to do is predict the item's position at a given time, and make sure that that we stop its decreasing (because it is going to be thrown).
To find the item's total pixel position, we must add its low byte position (7e00d8 + slot) to its high byte position multiplied by 256 ((7e14d4 + slot) * 256).  Note that slot is the slot of the item being carried.  To find this in a lua script, just scroll through the sprite status table and see which slot has the carrying flag set.
To find the item's y subpixel position, we must reference just one RAM address (7e14ec + slot).

Now, all we need to do is convert that pixel position and subpixel position to total subpixels.  When we have all of this, we are able to predict the new positions that the item will reach.  As I mentioned before, you want to make sure that for each frame you scroll through, it needs to be checked if the item is passed the block.  Only initially check this at the start of a loop, as you will be increasing the item's position and searching for if it has the capability of reaching the block's theoretical position - 6 from the block's theoretical position + 1 within one frame.
The shell's y speed oscillation starts at -112 when released upwards and this delta increases by 3 every frame.

This picture has the theoretical attributes of the block, in case you were confused when I explained it earlier.  Note the position prediction at the top middle of the screen.

If the condition of reaching 6 pixels into the theoretical bottom from the theoretical bottom + 1 (or more) is true, we need a way to detect which way the duplication will occur.  The way an item is shoved out of a block actually depends on the frame counter of the game.  So, if we take a value f for the frame value before the duplication, and add 1 initial frame that it takes to release the shell, and n frames to when the block will be duplicated, this will be the final frame counter.  If this is an even number, it will duplicate right, and it will duplicate left otherwise.

If I were to release the item on this frame (which means that I would need to go a frame before this and release the shell), the shell would go into the block to 327.90, and 327 is 333 - 6, except it would reach this from 334 on one frame, which means that these are perfect conditions for a duplication.  Using the frame counter, it is figured that the shell will duplicate the block to the right.

Proof that an item oscillates just enough to duplicate the block at sub 20 from 3 tiles away.

Predicting Normal Duplication

While there is a specific pattern to duplication from afar, there are only a few sets of rules for duplication right at the block's position.

(Subpixels are ignored in the following rules.  For this example, I will be using a shell in slot 9.  Note its attributes in each given picture)

If you are duplicating to the right, the game frame counter (7e0013) + 1 must be even, the item you are duplicating with must be in between the theoretical bottom of the block and the theretical bottom - 7, and must have an x position within the range of the theoretical right of the block - 9 and the theoretical right - 3.  If those conditions are achieved, a duplication to the right can occur.

If you are duplicating to the left, the game frame counter must be odd, the item must be in the same y range as when duplicating right, but must be within the x positions of the theoretical left + 2 and the theoretical left + 7.

If you are duplicating upwards, the game frame counter does not matter.  However, the y position of the item must be  exactly 8 or 7 pixels from the theoretical bottom of the block, and in an area constrained by 1 on regular x axis rules for to the left and right.

If the conditions are fulfilled for both left/right and up, a block will be duplicated diagonally.

Base Clipping A Block

We've looked at multiple ways to clip a block--from its left or right with a regular corner clip, and nearly from the top with a corner clip without max speed.  However, what if you wanted to clip a block from its base (bottom of the block)?

Well, there are multiple ways to do the clip through the bottom, and most of them are relatively easy.

Method 1 - Sprite Boost Methods

There are lots of sprites in the game that when you are on top of them, you will not take damage so that you can stand on them, but yet your collision check with ceilings is ignored since you are going downwards, even if that downwards is on a sprite pushing you upwards.  This allows us to, if we stand on a sprite moving upwards, completely bypass the ceiling check.  Many items when manipulated can be used to perform this:
1. When you start jumping, there is a frame that, when you throw a springboard upwards, it will briefly be under mario.  If you hit a ceiling during this, mario will land on the springboard, but the spring will still be going upwards.
2. If you throw an item that you can stand on shortly after jumping off of a springboard, you will be able to stand on it when it is moving upwards.
3. The speed achieved when jumping off of yoshi on the first frame that you land on him is enough to land on an item that you have just thrown into the air.

Method 2 - Yoshi with Collision Interruption

Yoshi is very special when it comes to base clips (and every other clip? :P).  With yoshi, if you manage to get on him, but he is in the ceiling, if you boost off of a sprite on that frame (or frames), you will be enough inside the block in order to jump right through it.  Boosting just by jumping on a p-switch, spring, or key will allow you to do this.  If you mount yoshi in a one-tile vertical space, the boost off of a shell on the same frame you are in the ceiling will achieve the same thing.  However, this trick is a lot more precise with a shell, as it depends on where yoshi is when you mount him, and the invulnerability frames of the shell at the same time.

Method 3 - Getting Boosted from Two Sprites While Big

If you have ever put two items together against a wall, and been in between the wall and the two sprites, you will notice that the two sprites act as a solid block.  The same works in the vertical direction, just a lot more precise.  Throwing two items so that they will just land in the correct position (todo: find that position in relation to the block) on the ceiling of the block, and landing on them on that frame that they are just by the ceiling, will allow you to be far enough up into a block in order to jump through it.  This can be done with two keys, two p-switches, and should not be possible with a spring, since springs take a little time to even boost you.

Method 4 - Boosting Directly Off Of Yoshi

If you are big, and mount yoshi in the ceiling, the frame that you are in the ceiling, if you jump off of yoshi, you can jump through the ceiling.  This can only be done as small mario only if yoshi was originally mounted at a high point in the ceiling, making this trick very conditional.

Corner Clipping Without Max Speed

A corner clip without max speed is not widely known.  Basically, it functions exactly like a regular corner clip, except it requires a strict y location instead of a strict x location.

To initially have some values, we need to have a way of referencing the top of the block.  We'll use what I like to call the "theoretical" top, just meaning that it works perfectly for checks (like the theoretical right and left in corner clip prediction, see below).  To find the theoretical top/left, you must first find the lowest 16th multiple that the block is at (pos - pos % 16), and then subtract 14.  To find the theoretical right/bottom, take the lowest 16th multiple based on the given axis, and add 13.

To corner clip, the player must go into the theoretical right/left of the block by 2 pixels and 1 subpixel (47 subpixels), but his speed must be 49...normally.  If you were to somehow achieve the same values but without max speed, you would get the same results.  Getting the correct x values when without max speed is easy, as you will need to jump towards the upper right (as a demonstration, also works from left) of the block, and doing so will achieve those values.  However, you must also go into the theoretical top position of the block by 418 subpixels.

The values we are looking for must be achieved on the exact frame that the player's speed goes from negative to positive.  The reason for that is that the block only checks collision from the top if the player's speed is positive (he is falling).

Approaching the block should look something like this.  I like to line yoshi's feet up with the top of the block when he is turning, as it is the most accurate representation of yoshi's hitbox.  Make sure that you are not being hit by the side of the block as you just strafe by the top of it.

The frame I am just before the block.  Note my x position and my y position.  Both are important, but the y position is more strict.

This is the frame that I am in the block.  My y speed is going to turn positive on the next frame and I am also going to be more than enough subpixels into the block on the x axis.  Also note that I am not hitting the side of the block.  You want to be as low as possible when clipping, as the y position manipulation causes you to be higher than you would expect in the end.

This is the frame I have clipped the block.  My y position is exactly 418 subpixels into the theoretical top of the block, and my y speed is positive, which means that I will be going more into the block on the next frame.  Also, my x position is more than enough to clip (required is 47 subpixels into it, I have gone 78 subpixels into it).

And, on top of this, if your x position increase is just right, you are able to walk right through the block (from the right or the left), which is what distinguishes this from a yoshi mount or a yoshi drop mount.

Another thing that distinguishes it from those is that you can do it without a ceiling, and without needing a block to be exactly one tile above the ground.  From the ground, you are able to do this with a block 3, 4, or 5 tiles above the ground.  Theoretically, any block that you can reach can be corner clipped without max speed without any specific oscillation pattern, as long as it is correct.

Simulating the Player's Speed

The player's speed has a weird system in general when it comes to things like accelerating and how it works after modifying it.  I decided to look into it because of the confusion it was causing me.

The speed of the player follows a table in the game which, frankly, makes no sense... until now.  Basically, if you are first looking at an acceleration table, you would expect for there to be some sort of speed list of the player to follow, but there's not.  Instead, it happens to be a table to change the value that changes the speed.

Say you wanted to just hold right (and Y) from speed 0 on the ground.  You would come across this strange speed pattern in which looks like it can be derived from a formula:
[0, 1, 3, 4, 6, 7, 9, 10, 12, 13, 15, 16, 18, 19, 21, 22, 24, 25, 27, 28, 30, 31, 33, 34, 36]
I'll stop there because I want to explain how the speed initially accelerates.
This pattern looks like the formula floor(1.5 * frame).  However, if you were to, say, release right for one frame (I'll release right on speed 6) you would get something that clearly did not follow this.
[0, 1, 3, 4, 6, 5, 6, 8, 9, 11, 12, 14, 15, 17, 18, 20, 21, 23, 24, 26, 27, 29, 30, 32, 33, 35, 36]

This means that the speed oscillation cannot be represented by a formula.  What is actually happening here is that the game is remembering the last increase in speeds.  This increase cycles between 2 and 1 whenever you hold left or right.  If you hold right from speed 0, it begins at 2, and if you hold left at speed 0, it begins at 1 (which it would subtract instead of add).  If you release your direction (releasing the direction you are holding causes the speed to decrease by 1), the cycle does not go to its opposite value.  Instead, it remembers it, so that when you hold right (or left again), it will continue the pattern it left off with.
Notice that we went from speed 4 to speed 6.  This increase in speeds (which I'll call 's') is 2.  On the next frame that I hold right, it will increase by 1, and then when I do again, it will increase by 2, etc.  So, if I were to not hold right until the speed reached for example, 3, it would increase by 1, and then 2 (3, 4, 6, following its original speeds again), etc.

If you turn around but your direction is opposite your speed, your speed will decrease by 5 (assuming your speed is positive).  So, turning around at speed 9 would drop my speed to 4.
There are two main exceptions to this oscillation of speed using a last value to remember: speed capping and if your speed went back to 0/went the opposite direction.  If my speed were positive and it became negative or went back to 0, then the pattern would be scrapped and start again (ie waiting with an increase that would be 2 until your speed reaches 0 will make it instead increase by the default 1).

The most complex and tricky pattern to replicate is speed capping.  Capping takes place at a maximum speed (37 if running, 49 if sprinting).  If you view the game's ram, you will notice a very similar pattern.  With 37 speed, this pattern of capping is 37, 36, 35, 36, 35, 37, 36, 35, 36, 35, 37...
A pattern like this does not have a set formula or increase, but instead a set of rules:

--> If your speed is exactly the capped speed, 's' will become 1, and the new speed will always be one before the capped speed on the next frame
--> If your speed is going to be greater than the capped speed in reference to s on the next frame, your speed will instead decrease by the inverse of s, and s will become its inverse
--> If your speed is exactly equal to the capped speed - 1, the next speed you will achieve is the capped speed - 2

With these rules, you can achieve the exact pattern of speeds that the game follows.
Note that these speeds are assumed that you are on land, and either have exactly 0 for a p meter (for running) or exactly 112 (for sprinting).

Predicting Whether Or Not a Corner Clip Will Occur

A corner clip can be very precise to get, especially if you are blindly guessing and hoping you will sometime achieve the trick.  However, this is a way to mathematically predict whether or not the player is going to clip the block or not.
To start, an equation can be arranged comparing the player's speed and position AND time (in frames) to the block's position (all positions in subpixels).  This is not the actual corner clip checking equation, just one that will prove useful to find frame values.

speed * time + position = predicted position

The time is the amount of possible positions which can be achieved in between the player's position and the lateral position you want to clip.  We can rearrange this equation since we already know the other variables to find the time.
time = (predicted position - player position) / speed

Finding the theoretical right side of the block is finding its x location to the lower nearest 16th multiple (xloc - xloc % 16) + 13 (note that these are in pixels instead of the widely used subpixels), and the theoretical left side is the lowest nearest 16th multiple - 14 (relative to the player's position to work the same way).  The theoretical left and right of the block will be different than the actual left and right.  Instead of having different properties now, we can use the same technique to see if we've reached corner clip conditions on either side.  Also note that the theoretical left side will always have a subpixel position of 00, and the theoretical right side will always have one of f0 (i.e., given a block whose theoretical left side is [number].00).

I will go back to why a corner clip even occurs, and relate that to the importance of the equation just written. For a corner clip to occur, the player must enter the block's theoretical position (see the paragraph above) by at least 2 pixels and 15 subpixels.  2 pixels is equivalent to 32 subpixels.  Knowing this, the player must achieve a position in subpixels of at least 47 subpixels into the block on one frame.

Using the equation written before, we can predict the player's position just before he hits the block's position.  If we assume the predicted position is the block's left or right side, we can see how many frames it will take to reach the edge of the block.
Here is an example problem for me to demonstrate:

The player is at a position of 1912.e0 with a speed of -49.  The block he is heading towards has a theoretical right position of 1725.f0.  Is this a successful corner clip?
First, we must convert the positions to subpixels in order to check things more easily.
1912.e0 --> 30606 subpixels
1725.f0 --> 27615 subpixels

time = (27615 - 30606) / -49 = 61.04081632653061
Since time is in frames, it must be a whole number, making our actual time 61 frames.
This means that we have 61 different positions over 61 different frames we will reach before we reach the block.  With this information, we want to focus on the 62nd frame, the one in which the player actually hits the block.
Before, I said that the player needs to go into the theoretical position by 47 subpixels, which means that if this is a successful clip, we want to have the following calculated position (always in subpixels) on the 62nd frame:
27615 - 47 = 27568
And, if we actually calculate where we will be on the 62nd frame...
62 (viewed frame) * -49 (xspeed) + 30606 (position of player in subpixels)
What would this equal, you might ask?
The answer is 27568, the exact position we need, as calculated before, which means that this is a successful corner clip!

All of what we have gone through is actually a demonstration of a modified version of the original equation, which can be used to directly find if a corner clip is achieved (I just walked through it):
If
floor(([theoretical block position] - [player position]) / speed + 1) * speed + [player position] = [theoretical block position] +/- 47 (depending on which side you are coming from)
Then corner clip the block.

So, with this compared equation, we can see whether or not the player will clip a block.

The Collision Box of Blocks

Although the collision of blocks may seem perfectly square, the actual hitbox that all blocks in the game have looks very similar to this:

Color Labels
Black is definite collision, blue is second layer collision ("dermis" collision if you will), light blue is where the middle of the block starts, gray is the definite middle, and green is free, where no collision checks occur

The Upper Section of the Block
Since the game can only check so far into each side for collision, it has to preserve its collision check so that it doesn't go so far that when one definite collision is happening others may happen as well, not representing actual collision.  This leeway for the top of the block is two pixels.  Two pixels from the left and right side of the block, the game will check for collision on the top of the block, and two pixels down, it will check for left and right collision.  There is a two pixel space in which nothing happens.  No collision is going to be checked in this region, and cancelling an air catch in this space will allow one to fly in from the left, corner clip it, and still not lose air.  They will not lose speed from the right because when you are in the middle of the block in which is not the two pixel free space, the game is told to push the player left automatically, but without affecting his speed.

The Bottom Section of the Block
From the bottom of the block, there is a larger region of collision, but no free space, which makes it near impossible to clip (besides if mario is on yoshi, in which there is a space where the two hitboxes make a "do nothing" region as well, where you may perform what is known as a block clip).
There are four pixels of leeway when it comes to the bottom of the block when it comes to the separation of bottom collision from side collision, but the game still pushes you out if you are in the diagonal area, unlike the top.