Okay, so I have been working on a little platforming game,its pretty much complete.

Played successfully on four computers, but none with CPU’smore powerful than 2.4ghz. However when I sent it to my friend who has a 3.8ghzi7, he noticed that the jump height of the character was about 10 pixels lessthan it should have been, and hence wasn’t able to navigate the platform.

The code is below, im hoping there is a reason why a superclockedprocessor causes change in the movement physics, if the velocity change is timebased and not CPU power based. I need this to work well on any computer as itwill be on a portfolio. So I really hope you guys can help.

The main loop is below.



int main (int argc, char* args[])
{
bool quit = false;

int xPlayMenu = 0;

initFunc();

Timer Delta;

Player myPlayer;

Level myLevel;

loadAudio();

Mix_PlayMusic( soundTrack, -1 );

Delta.start();

// Game loop

while (quit == false)
{
while (SDL_PollEvent (&event))
{
myPlayer.handleInput();

if (event.type == SDL_QUIT)
{
quit = true;
}
}

mainSoundCheck();

myPlayer.move(Delta.getTime());

Delta.start();

myLevel.draw();

myPlayer.show(Delta.getTime());

if( SDL_Flip( screen ) == -1 )
{
return 1;
}
}


Basically the delta clock is set the same way as LazyFoosets it in his tutorial (independence from frames.)

The move function is below.



void Player::move(Uint32 deltaTime)
{
checkCollisions(playerBox, platform);


velocityCalc();

playerBox.x += xVelocity * (deltaTime / 1000.f);
playerBox.y += yVelocity * (deltaTime / 1000.f);
}


Again the movement is based on the timing. So should imhoping im missing something obvious.

Just in case, here is the movement and acceleration and physicsfunction called to calculate the velocity during the move function.


void Player::velocityCalc()
{
if (rightDown == true)
{
if (grounded == true)
{

if (xVelocity < 0)
{
xVelocity += (ACCELERATION*2);
}

else if (xVelocity >= 400)
{
xVelocity = 400;
}
else
{
xVelocity += ACCELERATION;
}
}

else if (grounded == false)
{
if (xVelocity < 0)
{
xVelocity += (ACCELERATION*0.5);
}

else if (xVelocity >= 400)
{
xVelocity = 400;
}
else
{
xVelocity += (ACCELERATION*0.25);
}
}
}

if (leftDown == true)
{
if (grounded == true)
{

if (xVelocity > 0)
{
xVelocity -= (ACCELERATION*2);
}

else if (xVelocity <= -400)
{
xVelocity = -400;
}

else
{
xVelocity -= ACCELERATION;
}
}

else if (grounded == false)
{
if (xVelocity > 0)
{
xVelocity -= (ACCELERATION*0.5);
}

else if (xVelocity <= -400)
{
xVelocity = -400;
}

else
{
xVelocity -= (ACCELERATION*0.25);
}
}
}


else if ((leftDown == false) && (rightDown == false))
{
if (xVelocity+(ACCELERATION*2) < 0)
{
xVelocity+=(ACCELERATION*2);
}

else if (xVelocity - (ACCELERATION*2) > 0)
{
xVelocity-=(ACCELERATION*2);
}

else
{
xVelocity = 0;
}
}

if (jumping == true)
{
if (yVelocity < 0)
{
yVelocity +=(ACCELERATION*1.7);
}

if (yVelocity >= 0)
{
yVelocity = 0;

jumping = false;
}
}


if (falling == true)
{
if (yVelocity >= 1500)
{
yVelocity = 1500;
}

else
{
yVelocity += (ACCELERATION*1.5);
}
}
}


and finally this is the code that is executed when the jump button is pressed


if (playKeystates[SDLK_SPACE])
{
if (grounded)
{
Mix_PlayChannel( -1, jumpSound, 0 );
jumping = true;

yVelocity = -750;
}
}


i know this is a long topic and a weird problem. but Im hoping there is something obvious in the code that cause these different physics on a much faster machine (and i imagine much slower ones cause the opposite problem). Would truly be more grateful than can be imaginable for any help.

That's because the timestep is differing between the two machines. This is a math problem, not an alternative library problem. You don't limit your framerate, so deltaTime will vary a lot from computer to computer. Euler Integration (which is what you are using when you calculate the new position from the old velocity) has very different errors for different values of deltaTime, so you need to cap your framerate or come up with another way to ensure that deltaTime will vary little between different computers.

And secondly, when adding acceleration to velocity, you also need to multiply acceleration by a deltaTime component if your deltaTime isn't constant.

I guess Delta.getTime() returns the number of milliseconds since last call to Delta.start(). There is some time between you do myPlayer.move(Delta.getTime()) and Delta.start() so here you miss some time in your calculation which will make the animation run faster on a faster computer. I also don't understand why you use a different delta time with the show function.

I guess Delta.getTime() returns the number of milliseconds since last call to Delta.start(). There is some time between you do myPlayer.move(Delta.getTime()) and Delta.start() so here you miss some time in your calculation which will make the animation run faster on a faster computer. I also don't understand why you use a different delta time with the show function.

the show function has its own counter that controls how fast the animation frames progress.

so yeah, it looks like the best way to fix this problem will probably be to cap the framerate i think. (will also make the animation easier to deal with as well)