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

**(depending on which side you are coming from)**

*floor(**([theoretical block position] - [player position]) / speed + 1) * speed + [player position] = [theoretical block position] +/- 47*Then corner clip the block.

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

## No comments:

## Post a Comment