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.
No comments:
Post a Comment