# Odd Jumping Behavior?

While testing my player's jumpinig algorithm, I've come across two odd problems.

1) My player's hard-coded jump height is always much greater (roughly 1.5 times) than the in-game result, making me enter completely abstract numbers for the hard-coded value.

2) My player's jump height increases with lower FPS. At 60 FPS, the jump height was found to be 237, and at 30 FPS it was 269.

This has me completely bumfuzzled. I've been using this article pretty heavily while implementing my jumping function which can be seen below.

Player::Player(param1, param2, int init_jumpheight, double init_jumptime, param3..)
{
jumpheight = init_jumpheight;
jumptime = init_jumptime;

m_gravity = -(2 * jumpheight) / (jumptime*jumptime);
// other stuff
}

void Player::handleJump()
{
if(animState != JUMPRISE && animState != JUMPFALL)
{
animState = JUMPRISE;
jumpspeed = 2*jumpheight/jumptime;
jumpTimer.start();
}
else if(animState == JUMPRISE || animState == JUMPFALL)
{
jumpspeed += m_gravity*jumpTimer.get_ticks()/1000;
int yshift = jumpspeed*jumpTimer.get_ticks()/1000;

if(DEBUGMODE) printf("%0.2f\t%d\t%d\t%d\n",jumpspeed,yshift,jumpTimer.get_ticks(),m_coords.y);

shifty(-yshift);
jumpTimer.start();
if(yshift < 0 && animState != JUMPFALL) animState = JUMPFALL;
}
}


And here's my console log (the bit that records the details of the jump):

1258.40 20      16      1520
1219.40 18      15      1502
1180.40 17      15      1486
1146.60 14      13      1471
1107.60 16      15      1459
1068.60 16      15      1445
1034.80 13      13      1431
1001.00 13      13      1420
962.00  14      15      1409
923.00  13      15      1397
886.60  12      14      1386
852.80  11      13      1376
816.40  11      14      1367
777.40  11      15      1358
738.40  11      15      1349
704.60  9       13      1340
668.20  9       14      1333
631.80  8       14      1326
598.00  7       13      1320
559.00  8       15      1315
520.00  7       15      1309
483.60  6       14      1304
449.80  5       13      1300
410.80  6       15      1297
371.80  5       15      1293
332.80  4       15      1290
293.80  4       15      1288
257.40  3       14      1286
228.80  2       11      1285
189.80  2       15      1285
153.40  2       14      1285
117.00  1       14      1285
80.60   1       14      1286
39.00   0       16      1287
0.00    0       15      1289
-36.40  0       14      1291
-65.00  0       11      1293
-104.00 -1      15      1295
-143.00 -2      15      1298
-182.00 -2      15      1302
-218.40 -3      14      1306
-252.20 -3      13      1311
-288.60 -4      14      1316
-325.00 -4      14      1322
-361.40 -5      14      1328
-403.00 -6      16      1335
-442.00 -6      15      1343
-478.40 -6      14      1351
-517.40 -7      15      1359
-551.20 -7      13      1368
-590.20 -8      15      1377
-629.20 -9      15      1387
-665.60 -9      14      1398
-694.20 -7      11      1409
-746.20 -14     20      1418
-782.60 -10     14      1434
-821.60 -12     15      1446
-860.60 -12     15      1460
-899.60 -13     15      1474
-938.60 -14     15      1489
-980.20 -15     16      1505


When calculating the change in y-position, you aren't accounting for the change in velocity between frames. Essentially what you have is this:

s = change in position
v = velocity
t = time between frames
a = acceleration

v += a * t
s = v * t


What you should have is this:

s = change in position
v = velocity
t = time between frames
a = acceleration

s = v * t + 0.5 * a * t * t
v += a * t


Here's a video explaining the above formula.

Alternatively, here's some text to read.

Since we're talking about video games, though, an easy solution is to implement a fixed timestep.