deWitters 4th game loop HELP!

OpenGL Development
#21

That’s because you’re still extrapolating. You need to change
[icode]player.viewX = player.x + interpolation * (player.x - player.prevX)[/icode]
into
[icode]player.viewX = player.prevX + interpolation * (player.x - player.prevX)[/icode]

With that change you’ll be INTERpolating between the previous position and the current position.

#22

It seems that the inclusion of updateTime in the interpolation calculation greatly effects this. If I did at it in the first part of the equation I started jumping!

but…

After playing around with the code and doing your suggestions I seem to have got it to work! My movement is now smooth! Agent D thank you so much for all the help!

The final game loop product


//The max amount of time the game logic loop can be updated befoire forcing the render call
const int MAXUPDATES = 5;

//Time we have updated the game logic loop
int loops = 0;

//The amount of time (in milliseconds) spent updating the game loop in this case 33.33333 milliseconds
double updateTime = 1000.0 / 30.0;

//Used for the interpolation calculation
double interpolation;

/*
	Get the current time before we start the main game loop
	timeGetTime() returns the amount of time since the "system" has started in milliseconds
	In this case the system is Windows
*/
double gameClock = timeGetTime();

while(runGame)
{


	//Reset the loop count
	loops = 0;

	/*
		The GAME LOOP!
		Continue to update the game until the game Clock is greater than the current time ( timeGetTime() )
		OR
		Until we have hit the max amount of time we are allowed to update before we a re focring the game to render
		( the loops < MAXUPDATES part)
	*/
	while( (timeGetTime() >= gameClock) && (loops < MAXUPDATES))
	{

		
		//Store the previous player position
		player.prevX = player.x;
		player.prevY = player.y;

	
		//Movement right
		if(currentKeystate[SDKL_d])
			player.x += player.speed;

		//Movement left
		if(currentKeystate[SDKL_a])
			player.x -= player.speed;

		//Movement up
		if(currentKeystate[SDKL_w])
			player.y -= player.speed;

		//Movement down
		if(currentKeystate[SDKL_s])
			player.y += player.speed;

		//Add onto the game clock by the update time; Add onto the number of loops
		gameClock += updateTime;
		loops++;
	}

	
	//Calculate for interpolation
	interpolation = ((timeGetTime() - gameClock) + updateTime) / updateTime;

	//Apply the interpolation to the player's render position before actually rendering the game
	player.ViewX = player.prevX + interpolation * (player.x - player.prevX);
	player.ViewY = player.prevY + interpolation * (player.y - player.prevY);

	//Render the game sprites and etc using on the render positions ( player.viewX / player.viewY )
	drawGame();

	//Flip / swap the buffers to draw everything to the screen
	SDL_GL_SwapBuffers();
}
#23

Fixed time step simulations = good. Variable time step simulations = many many bad things.

#24

If you look at your updating code, you can see why you need to add updateTime to the time you calculate. Since you loop until [icode](timeGetTime() >= gameClock)[/icode], the value of gameClock will be more than the current time. If you don’t add updateTime to the value, the value [icode](timeGetTime() - gameClock)[/icode] will be negative! To be precise it will be between -updateTime and 0. If the update was instant, gameClock will be exactly one frame ahead, so the interpolation value becomes -1. If updating took a long time, it’ll approach 0. Therefore you will want to add updateTime to it before dividing to bring it to 0.0-1.0 instead.

A note about the interpolation though: Remember that the update loop only updates 5 times at max. If the game freezes for a second or so, it’ll behave a bit weirdly. In short, the game will attempt to show an extremely extrapolated view of the game since [icode](timeGetTime() >= gameClock)[/icode] will be extremely large and the “interpolation” value will be over 1.0. Since this might make the game look extremely weird (things continue through walls and so, basically the same popping you got before when movement changed but 10x worse) while the game catches up, it might be a good idea to clamp this value to 1.0 to prevent potentially inaccurate extrapolation. Just an idea though, depending on the game, the extrapolation could in the case of linear movement completely hide the fact that it’s still catching up since the extrapolation is accurate. I guess this is kind of a minor detail since if your game freezes up for a long time you’re kind of having more severe problems than the interpolation not being 100% accurate. =S