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!