Framerate and speed interpolation

SDL Development
1

Hello

I am wondering what sort of equations must be used to calculate
interpolation for a constant movement between different framerates.

I done various tests with SDL_gfx’s framerates function in my algorythm.

Here is my movement loop;

/**************************************************************************/

/*** .. some init stuff ... **/



SDL_initFramerate(p); //from SDL_framerate.h (SDL_gfx lib)
SDL_setFramerate(p, 60); //p is an FPSmanager, set to 60FPS

speed = 10;  //set speed for movement

while(loop)
{
	while(SDL_PollEvent(&ev))
	{
		switch(ev.type)
		{

			case SDL_KEYDOWN:
				keystate[ev.key.keysym.sym] = 1;
				break;
			
			case SDL_KEYUP:
				keystate[ev.key.keysym.sym] = 0;
				break;

			case SDL_QUIT:
				loop=0;
				break;
		}
	}

	if(keystate[SDLK_LEFT])
		angle-=5.0;

	if(keystate[SDLK_RIGHT])
		angle+=5.0;

	//degrees_to_radiant(double) : converts the angle to rad 		//r : a

SDL_Rect struct
r.x += speed * cos(degrees_to_radiant(angle));
r.y += speed * sin(degrees_to_radiant(angle));

	SDL_FillRect(screen,NULL,SDL_MapRGB(screen->format,0,0,0));
	SDL_BlitSurface(obj, NULL, screen, &r);

	SDL_Flip(screen);
	SDL_framerateDelay(p); //delay for framerate
}

/**********************************************************************************/

From here all is simple, I display the animation at 60FPS

I did some tests between various FPS values to see variations. From
25FPS, movement seems like constant.

40px at 4FPS
60px at 5FPS
…
110px at 10FPS
120px at 11FPS
…
220px at 22FPS
240px at 23FPS
250px at 24FPS
260px at 25FPS

So we can see this doesn’t run same amount of pixels according with fps

My question is : How can a run the same amount of pixels in the same
amount of time, being FPS independant ?

cya

2

Hello

I am wondering what sort of equations must be used to calculate
interpolation for a constant movement between different framerates.

I done various tests with SDL_gfx’s framerates function in my algorythm.

The main problem you are facing is one that many people face. It is the
belief in a constant frame rate. There is now such thing on modern PCs.
Forget about it. Sure, the hardware is running at a constant frame rate,
but your program may or may not be running at any given time. The result
is that you might as well just assume that the time between frames is
random.

Remember that velocity is distance/time you are trying to use
frames/second as a valid time base, and it isn’t working. So, use the
real time. Just grab the time using SDL_getTicks(). and use:

r.x += (distance * time) * cos(degrees_to_radiant(angle));
r.y += (distance * time) * sin(degrees_to_radiant(angle));

where the time is measured in milliseconds and the distance is measured
in pixels/millisecond. Doing it this way gives you a constant visual
motion independent of when you get to draw the next screen.

To say it again, the frame rate is not a usable time base on modern
computers.

	Bob PendletonOn Sun, 2003-11-23 at 17:14, Carlos Alvarez wrote:

Here is my movement loop;

/**************************************************************************/

/*** … some init stuff … **/

SDL_initFramerate§; //from SDL_framerate.h (SDL_gfx lib)
SDL_setFramerate(p, 60); //p is an FPSmanager, set to 60FPS

speed = 10; //set speed for movement

while(loop)
{
while(SDL_PollEvent(&ev))
{
switch(ev.type)
{

  		case SDL_KEYDOWN:
  			keystate[ev.key.keysym.sym] = 1;
  			break;
  		
  		case SDL_KEYUP:
  			keystate[ev.key.keysym.sym] = 0;
  			break;

  		case SDL_QUIT:
  			loop=0;
  			break;
  	}
  }

  if(keystate[SDLK_LEFT])
  	angle-=5.0;

  if(keystate[SDLK_RIGHT])
  	angle+=5.0;

  //degrees_to_radiant(double) : converts the angle to rad 		//r : a

SDL_Rect struct
r.x += speed * cos(degrees_to_radiant(angle));
r.y += speed * sin(degrees_to_radiant(angle));

  SDL_FillRect(screen,NULL,SDL_MapRGB(screen->format,0,0,0));
  SDL_BlitSurface(obj, NULL, screen, &r);

  SDL_Flip(screen);
  SDL_framerateDelay(p); //delay for framerate

}
/**********************************************************************************/

From here all is simple, I display the animation at 60FPS

I did some tests between various FPS values to see variations. From
25FPS, movement seems like constant.

40px at 4FPS
60px at 5FPS
…
110px at 10FPS
120px at 11FPS
…
220px at 22FPS
240px at 23FPS
250px at 24FPS
260px at 25FPS

So we can see this doesn’t run same amount of pixels according with fps

My question is : How can a run the same amount of pixels in the same
amount of time, being FPS independant ?

cya

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±--------------------------------------+

3

The main problem you are facing is one that many people face. It is the

belief in a constant frame rate. There is now such thing on modern
PCs.
Forget about it. Sure, the hardware is running at a constant frame
rate,
but your program may or may not be running at any given time. The
result
is that you might as well just assume that the time between frames is
random.

Remember that velocity is distance/time you are trying to use
frames/second as a valid time base, and it isn’t working. So, use the
real time. Just grab the time using SDL_getTicks(). and use:

r.x += (distance * time) * cos(degrees_to_radiant(angle));
r.y += (distance * time) * sin(degrees_to_radiant(angle));

where the time is measured in milliseconds and the distance is
measured
in pixels/millisecond. Doing it this way gives you a constant visual
motion independent of when you get to draw the next screen.

To say it again, the frame rate is not a usable time base on modern
computers.

Bob Pendleton

Can the motion angle be still affected by framerate (if no framerate
regulation) although speed is displayed as constant ?

4

Can the motion angle be still affected by framerate (if no framerate
regulation) although speed is displayed as constant ?

I’m not sure I understand this question.

Are you asking if you can safely adjust the angle based on the frame
rate? That is, your object is spinning or changing direction over time
as well as moving? In that case you compute the change in angle the same
way you compute the change in distance. For example:

angle = rate * deltaT

where “rate” is in degrees or radians per second and delaT is the time
(in seconds) since the last update.

At least that works for a first approximation. If you want a physically
accurate curve you need to use the parametric forms of the equations
that describe the physics you are modeling.

	Bob PendletonOn Mon, 2003-11-24 at 13:46, Carlos Alvarez wrote:

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±--------------------------------------+

5

Hello, I’m trying to find a way to handle transparency for most common cases.
I must say that my goal is to use png bitmaps only, enable screen alpha, and run the
app only in 32 bits display mode.

It seems to be slower but I don’t want to lose time with optimisation for now.

I would like to draw a surface with a smooth fadein or out (from insivible to initial
transparency/draw mode)

I’ve tried with
SDL_SetAlpha(m_surface,SDL_RLEACCEL | SDL_SRCALPHA, amount);

But it doesn’t do nothing.

The doc seems to state that RGBA RGBA bliting transparency can’t be changed that way…

So, What is the solution ??

Thank you

6

Why do you want screen alpha? Any standard video card will just ignore
it, so it’s only relevant for certain (rather unusual) blending
operations. You probably want to use OpenGL or custom s/w rendering
code for that, as SDL only does basic source alpha blending.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 26 November 2003 11.04, kandjidev at yahoo.fr wrote:

Hello, I’m trying to find a way to handle transparency for most
common cases. I must say that my goal is to use png bitmaps only,
enable screen alpha, and run the app only in 32 bits display mode.