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.

Predicting the Max Distance From a Jump

(Updated Post)
This post originally had a semi-accurate way of checking the distance from a jump, but this method will work perfectly, even though the calculations take more time.
This post will assume you know how speeds affect positions (explained in below posts).

As a starting point, we need to see what is needed in this calculation.  What we will need is a starting y position, an x speed, and an ending y position.  The starting y position will be the theoretical position of the top of the block you are currently standing on, and the ending y position will be the theoretical top of the section of the blocks you will be landing on.
For an example, I will use the data below:

The theoretical top of the block mario is standing on is located at 370.00.  To find this, take the block's floored multiple of 16 and subtract 11 from that.

The ending theoretical top we will be landing on is 322.00.
Also, I will be jumping at 37 speed in this demonstration.

Using a formula I have come up with earlier, we can find the y speed from a jump with a given x speed.
ceil(-2.5 * floor(abs(xspeed) / 8) - 77)
Since I'm jumping at 37 speed, filling that into the formula will give us -87 as our y speed.

Along with this, we need to know a little bit about how y speeds work over time.  After a jump occurs, a certain y speed is stored (which we just figured out, in this case, is -87).  Now, if the B button is held, this stored value will increase by 3 every frame.  To calculate the max amount of x distance from a jump, we need to know how long the player is in the air, and doing this will just increase our number every frame, adding up the amount of frames that have passed, until the number is greater than the new block's theoretical position.  To do this, we will need a continuous loop to change the player's y speed accordingly.  Even though the player is at a specific position, this jump distance will be true for any given position, as long as the same theoretical y block top positions are the same distance apart.
It is recommended to use a programming language, excel, or something else that allows you to do loops until something specific occurs.  A variable "delta" will be the amount of y speed in which our player's y position (in subpixels) will increase every frame.  Also note that this delta will retain at a constant 67 when falling if B is being held.

delta = -87 (for this example)
loop (until y position (theoretical top(1)) > theoretical top(2) from the highest point of a jump) (add delta to position, and then add 3 to delta)

If you do all of this, you will end up with 49 frames that the jump covers over, and that is 49 frames we are in the air without losing speed.  With this, all you must do is multiply the x speed (in this case 37) by 49 frames, and that will give us a subpixel amount of distance of 1813.  This can be converted to an x distance of 113.50 as an actual game distance, and dividing the amount of subpixels by 256 will let us see that the player jumps over an equivalent distance of ~7.082 tiles with these two given y theoretical positions.

Predicting Mario's X Position

This information is a very basic version of predicting speeds.
For this section, I will be assuming that mario's speed is going to be constant.  Something more advanced (predicting what it would be like with a direction held) would require a more complex formula.

Since mario's speed is in subpixels per frame, all we must do to predict his x position in a given future frame is to convert his position and subpixel to a position in subpixels and a "true" subpixel, add the speed mutiplied by a given amount of frames, and then convert that back to pixels and hex subpixels.

For example, say the player is at an x position of 572.d0 with an x velocity of 23, and we want to find his new position after 13 frames.

572 * 16 + 0xd0 / 16 = 9165
9165 + 23 * 13 = 9464
9464 subpixels --> 591.80 in game positions.

So our predicted position will be 591.80

Corner Clipping

Corner Clipping is a precise trick in which Mario's speed allows him to skip over the first three pixels of a block, and then, with an extra boost, he is able to clip into the entire thing, and pass through the block completely.

This is generally the aimed jump when wanting to do a corner clip, where mario presumably jumps into the corner of the block.  Mario can corner clip on either side of the block, except when he is small, in which he can only clip from the right side.

This bit will have assumed that you have read the logic of the below tutorials, in which subpixels are the magic behind most of these tricks.

A walljump is where mario must have the speed that allows him to go more two pixels into the block (32 subpixels) within one frame, which means he must have 33 speed.  Well, a corner clip actually requires him to enter the block by more than 3 pixels, which is 48 subpixels, meaning he must have a speed of 49.  Coincidentally, 49 is the maximum amount of speed that you can achieve with a run as any form of mario.

The only difficult part is getting your subpixel and position to line up to where you can reach the exact position of the block, allowing you to fully enter the block by 3 pixels on the following frame.

This is why it is recommended to create or use a lua script, as a lua script such as mine or masterjun's will automatically check every frame for the subpixel line ups to a block you are predicting to, and does not require you to manually check every time (which would otherwise make this trick take a very long time).

The reason why it is needed for you to enter the block by its corner is because just entering the side isn't enough.  At the point in which you touch the side of the block, block pressure immediately comes in, and in this situation mario could completely stop before the block.  By entering the block's corner, you can avoid block pressure for the frames needed before dropping into the block by 3 pixels.  The action in turn will push you to the left, since the inner part of the block is automatically set to push the player left if he is in it, and from the right this means that saving frames.  You can also save frames and be pushed right from the left side if you are on yoshi.

When done correctly, you should achieve the x position scrolling to allow you to get 3 pixels into the block...

The red region indicates that the subpixels will line up correctly for a corner clip on that list of blocks to occur.

Normally, on the frame after this, I would be stopped immediately because of block pressure.  However, since I have entered the block through its corner, I will not be stopped.  And, by the time I do get 3 pixels in the block, the game stops collision detection for the right side of the block, and instead registers me in the middle, where I will immediately be pushed out.

The frame that I actually enter the block, although the graphics are one frame behind so it is not completely obvious that I have yet.

The second frame I have entered the block.  At this point I have hit the block below the block I am clipping, so I should start losing x speed on the next frame...

And one last screen shot just because it looks cool :D

Good luck clipping!  And again, if you have any questions about anything above, PM me preferably on SMWC.

Walljumping

Walljumping occurs when the player enters a block by just over 2 pixels.  I am going to explain it fully in this description.
First I'm going to begin about talking about how the player moves.  Have you ever wandered what speeds actually meant?  Basically, the game's smallest unit of measurement in speeds is not in pixels, but subpixels.  There are 16 subpixels in one pixel, meaning that there are 256 in each tile of the game.  The player doesn't move relative to pixels, but in fact subpixels.  When you have a speed of 19, this means that you are moving 19 subpixels per frame.

To make this more comprehensible, you can convert everything into subpixels when it comes to the player.  The player's subpixel is not exactly accurate, as it takes up an entire byte.  To make it take up only 16 values (0-15) we must divide it by 16.  To convert from pixels to subpixels, all that we must do is multiply by 16.  This new position is the "combined position" and allows you to check things in units of subpixels rather than random check values.
Hypothetically, let's say that Mario is at position 255.c0 (according to the game)
255 * 16 + c0 (192) / 16 = 4092

Since mario's speed is measuring in subpixels per frame, all that we must do to find his position on the next frame of the game is to add the speed in which we are at presently.  Now, let's just think for a second, and realize that eventually, the game is going to have the player move so many subpixels per frame that he is going to have the capability to skip over a slight section of the block you are hitting.  If you were to get into a position in which you could move over 2 pixels into the block, you could clip the bottom of the block that you are hitting.  What is intended is for you to hit the block, and then immediately be shoved out.

Remember that we are working with subpixels, so 2 pixels is going to be represented as 32 subpixels.
Since we want to go into the block by more than 2 pixels, we will need to be moving 33 subpixels per frame at least, or, in other words, have an x speed of 33 or more.

Keep in mind that you must be in the position in which you can move passed the position of the block by more than 2 pixels, meaning that just getting 33 speed will not do anything.  You must get to the point in which the subpixels will align just perfectly for you to be able to get passed the block by 33 subpixels within one frame, and be able to hit the block before being shoved out.
In this case, I have found a frame where I can in fact pull this off:

This is the point in time where I will be moving and my positions will fall just right so that I can go into the position of the block by 2 pixels.
Mathematical proof:
Position of block: 2285.00
Position of player: 2293.d0 moving with -35 velocity
Block Position in subpixels: 36560
Player Position in subpixels: 36701

Player prediction of position (moving -35 subpixels every frame):
36701, 36666, 36630, 36595, 36560, 36525 <-- Position before I am shoved out of the block
However, if you notice, I come across the exact position of the block on a frame, but I still haven't gone into the block yet, which is when it actually pushes you out.  So, 36525 < 36560 - 32 which means that this is a successful walljump, as my lua script shows.
This means that my position before the block shoves me out should be:
floor(36525 / 16).(36525 % 16 * 16)
which is 2282.d0 (2282.208 without hex conversion)
However, sadly, block pressure is going to slightly push you out as soon as you touch the side of the block, landing your actual position at 2283.e0 (increase of 1.10 pixels).  But, this is still a correct walljump value.

So, that is how a walljump works on a subpixel level, and also how you can predict it.

Predicting Jump Speed and Position At A Certain Point In Time

Predicting jumps can be a bit tricky, as the initial jump speed is dependent upon the x speed of the player on the frame that the jump takes place.

If you match up a table of a jump and a spin jump, you will achieve the following:

Normal Jump

[0, -77]

[8, -79]

[16, -82]

[24, -84]

This pattern of x speeds to jumps is actually constant, even though the oscillation scrolls between 2 and 3 because everything is represented as integers.  This change is 2.5 every 8 speed changes.  Knowing this, we can come up with the formula:

ceil(-2.5 * floor(abs(x speed) / 8) - 77)
Which is a variant on arithmetic sequences conforming to the situation, and makes it so that you will always have an integer result.

A similar table can be achieved with spin jumps

Spin jumps have a much more simple pattern though, and this one is an actual arithmetic sequence.

[0, -71]

[8, -73]

[16, -75]

[24, -77]

From here, all you must do is account for negative speeds (like I did in the first example) and account for the fact that the increase between each speed is 8.

2 * -floor(abs(xspeed) / 8) - 71

Now, you have the ability to predict what the player's y speed will be based solely upon x speed.

From here is the more challenging, theoretical standpoint - predicting the position in which the player will be at for a given point in time.  We need a method for passing time - and we'll call this time t.  At 0, t represents the present point in time.  However, we're more interested in what will happen at a future point in time.

First, we'll need a single unit of position to track where the player is going to be at in the future.  For this example (and for most examples) I will be using subpixels.  The subpixel that the player is at is not a "true" subpixel per say, so we'll have to convert that to a "real" subpixel (not in hex).  Also, the player's main position is in pixels, so we'll have to convert that to subpixels as well.

For this specific example, let's say that the player has an x speed of 29, and is at x position 297.f0

Using our previous math formulas, we can calculate the y speed of the player when he jumps.  Let's say that he is doing a regular jump.  You will end up with -84.

Now comes the more confusing part.

From here, we'll need to convert our position into subpixels

297 * 16 + f0 (240) / 16 = 4752 + 15 = 4767

Predicting the position is simple without the delta included because of gravity.  It is simply done by adding the y speed of the player, since the y speed is in its definition subpixels moved per frame.  Every frame from here, we will be adding a new result.  So, a summation is actually needed to do things.

The summation we will be doing will be in reference to the passed frames f from the present frame to the predicted frame.  Let's say that we want to see mario's y position at 15 frames into the future.  Well, we will need a summation from 0 to 15.

To predict the delta, some more observations will have to be done, but you will soon find that holding down B/A increases the y speed by 3, and not increases it by 6.

Mathematical representation:

Predicted position = 4767 + summation {from 0 to 15 represented by f} (-84 + 3 * f)

Remember that 4767 is the position of the player in subpixels, -84 is his initial y speed predicted and 3 is the delta increase every frame.

With this, we will end up with

4767 - 984 = 3783

3783 will be our new position in subpixels.

Happy predicting!

General

Inner SMW is a blog that I started to help people understand an actual mathematical representation of a lot of tricks found in the game, or how things work in general that not everyone would understand without something like this.

My goal for this is to help you learn something new about the game or how to do something you never knew how to do before.  A lot of what I will be doing will be demonstrated in Lua Scripts, and if you don't know the Lua language and how it applies to reading RAM, I would advise you that it will help you a lot (basically, it obsoletes RAM watch, and does much more as a scripting language)