When I write SDL games, I like to limit the frame rate to around 60fps. I do
it like so,
long then;
// main game loop
while (true)
{
then = SDL_GetTicks();
... // routines and graphics
while (SDL_GetTicks() < then + 16){} // don't do anything
}
Now… the bit that I’m concerned about is the
while (SDL_GetTicks() < then + 16){}
Whilst it works and doesn’t really affect the system too much, it is
sitting there in a while loop for a bit until it reaches a point where it is
allowed to continue (ie - after 1/60th of a second has be reached).
I figured that I could do,
while (SDL_GetTicks() < then + 16)
{
SDL_Delay(1);
}
which seems kinder to the system… but then I lose around 10fps.
When I write SDL games, I like to limit the frame rate to around 60fps.
This may sound stupid, but… why?
I
do it like so,
long then;
// main game loop
while (true)
{
then = SDL_GetTicks();
… // routines and graphics
while (SDL_GetTicks() < then + 16){} // don’t do anything
}
Now… the bit that I’m concerned about is the
while (SDL_GetTicks() < then + 16){}
Whilst it works and doesn’t really affect the system too much, it is
sitting there in a while loop for a bit until it reaches a point where it
is allowed to continue (ie - after 1/60th of a second has be reached).
I figured that I could do,
while (SDL_GetTicks() < then + 16)
{
SDL_Delay(1);
}
which seems kinder to the system… but then I lose around 10fps.
I think the problem is that the scheduler simply won’t wake you up soon
enough. For example, on current (2.4.x-ish) Linux kernels, you’ll get a
scheduling granularity of 10ms because that’s the interval between timer
interrupts.
Any advice?
Not really. Of course, you could always spend some time on improving the
operating system’s realtime capabilities… :}
cu,
Nicolai
Thanks,
Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE9xmK2sxPozBga0lwRAk1bAKCiNue5QwXD/HQQc3BVUuW3g0kC+wCgk9aI
SMthx7E0+lJCno8iCGuv9rM=
=3Wm3
-----END PGP SIGNATURE-----On Monday 04 November 2002 12:50, Sweeney, Steven (FNB) wrote:
Why? It helps with doing some stuff like timing. Also… when I first wrote
an SDL game, I was getting around 50fps when playing it. People reported it
me they were getting more than 80fps and it was unplayable because it was
too fast. Basically I had coded to rate of enemy fire, etc to be correct
with the frame rate I was comfortable with. For example, an enemy bullet
might take around 2 seconds to cover the length of the screen, but at faster
game rates, it was taking less than a second.
Sorry… I think I’ve confused people with frame rate and program execution
time! :)> -----Original Message-----
From: Nicolai Haehnle [SMTP:prefect_ at gmx.net]
Sent: Monday, November 04, 2002 12:06 PM
To: sdl at libsdl.org
Subject: Re: [SDL] Limiting game speed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On Monday 04 November 2002 12:50, Sweeney, Steven (FNB) wrote:
When I write SDL games, I like to limit the frame rate to around 60fps.
This may sound stupid, but… why?
I
do it like so,
long then;
// main game loop
while (true)
{
then = SDL_GetTicks();
... // routines and graphics
while (SDL_GetTicks() < then + 16){} // don't do anything
}
Now… the bit that I’m concerned about is the
while (SDL_GetTicks() < then + 16){}
Whilst it works and doesn’t really affect the system too much, it is
sitting there in a while loop for a bit until it reaches a point where
it
is allowed to continue (ie - after 1/60th of a second has be reached).
I figured that I could do,
while (SDL_GetTicks() < then + 16)
{
SDL_Delay(1);
}
which seems kinder to the system… but then I lose around 10fps.
I think the problem is that the scheduler simply won’t wake you up soon
enough. For example, on current (2.4.x-ish) Linux kernels, you’ll get a
scheduling granularity of 10ms because that’s the interval between timer
interrupts.
Any advice?
Not really. Of course, you could always spend some time on improving the
operating system’s realtime capabilities… :}
cu,
Nicolai
Thanks,
Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
From: Matthijs Hollemans [SMTP:matthijs at allyoursoftware.com]
Sent: Monday, November 04, 2002 12:11 PM
To: sdl at libsdl.org
Subject: Re: [SDL] Limiting game speed
Steven,
I figured that I could do,
while (SDL_GetTicks() < then + 16)
{
SDL_Delay(1);
}
which seems kinder to the system… but then I lose around 10fps.
When I write SDL games, I like to limit the frame rate to around
60fps.
I don’t know what platform you are targetting, but my laptop’s video
card (Nvidia) seems to have a fixed framerate of 52 point something
fps in 640x480x32 fullscreen mode using page flipping. (Even though
the settings indicate the refresh rate is set to 60 Hz.) If your
game uses a fixed rate of 60 fps (i.e. you expect each frame to take
up no more than 16ms), systems such as mine may not be able to keep
up (because frames can’t go faster than 20ms). I don’t know if the
refresh rate I am getting is typical for laptops.
If you are writing a 2D game aimed at the general public (not
hardcore gamers), 60fps may be too fast for typical consumer
hardware (PII 300, lame video card). On the other hand, if you’re
writing a 3D game, a better approach is not to fix the frame rate,
but use whatever framerate you can get. Movement is now based on
elapsed time – how long the last frame took is how much the objects
have moved. Slower machines may have to disable certain features to
still get decent performance.–
Matthijs Hollemans
All Your Software www.allyoursoftware.com
You might want to consider basing object motion on time instead of frames.
That will make your game independent of cpu speed, load, and refresh rate.
You probably calculate object location like this right now:
x=x+vx
y=y+vy
To make it dependent on time instead of frames calculate it like this:
x=x+vxdt
y=y+vydt
Where dt is the amount of time that has elapsed since you last moved the
objects. Therefore when your framerate is fast, dt will be smaller and the
objects will move in smaller increments. When framerate is low, objects
will move in bigger chunks. Apparent rate of motion will be independent of
frame rate.
Regards,
Dan.> ----- Original Message -----
From: sweenes@fnb.co.uk (Steven Sweeney))
To:
Sent: Monday, November 04, 2002 6:49 AM
Subject: RE: [SDL] Limiting game speed
Why? It helps with doing some stuff like timing. Also… when I first
wrote
an SDL game, I was getting around 50fps when playing it. People reported
it
me they were getting more than 80fps and it was unplayable because it was
too fast. Basically I had coded to rate of enemy fire, etc to be correct
with the frame rate I was comfortable with. For example, an enemy bullet
might take around 2 seconds to cover the length of the screen, but at
faster
game rates, it was taking less than a second.
Sorry… I think I’ve confused people with frame rate and program
execution
time!
-----Original Message-----
From: Nicolai Haehnle [SMTP:prefect_ at gmx.net]
Sent: Monday, November 04, 2002 12:06 PM
To: sdl at libsdl.org
Subject: Re: [SDL] Limiting game speed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On Monday 04 November 2002 12:50, Sweeney, Steven (FNB) wrote:
When I write SDL games, I like to limit the frame rate to around
60fps.
This may sound stupid, but… why?
I
do it like so,
long then;
// main game loop
while (true)
{
then = SDL_GetTicks();
… // routines and graphics
while (SDL_GetTicks() < then + 16){} // don’t do anything
}
Now… the bit that I’m concerned about is the
while (SDL_GetTicks() < then + 16){}
Whilst it works and doesn’t really affect the system too much, it is
sitting there in a while loop for a bit until it reaches a point where
it
is allowed to continue (ie - after 1/60th of a second has be reached).
I figured that I could do,
while (SDL_GetTicks() < then + 16)
{
SDL_Delay(1);
}
which seems kinder to the system… but then I lose around 10fps.
I think the problem is that the scheduler simply won’t wake you up soon
enough. For example, on current (2.4.x-ish) Linux kernels, you’ll get a
scheduling granularity of 10ms because that’s the interval between timer
interrupts.
Any advice?
Not really. Of course, you could always spend some time on improving the
operating system’s realtime capabilities… :}
cu,
Nicolai
Thanks,
Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
You’re getting no more than 52fps in 640x480x32? Try running in 16 or 24 bit
instead. Maybe that even though the mode is supported, it’s not the fastest.
I develop on a laptop in 1024x768x16 and everything races along (but it’s
got a 1Ghz processor and 256MBs of RAM)> -----Original Message-----
From: Matthijs Hollemans [SMTP:matthijs at allyoursoftware.com]
Sent: Monday, November 04, 2002 1:23 PM
To: sdl at libsdl.org
Subject: Re: [SDL] Limiting game speed
When I write SDL games, I like to limit the frame rate to around
60fps.
I don’t know what platform you are targetting, but my laptop’s video
card (Nvidia) seems to have a fixed framerate of 52 point something
fps in 640x480x32 fullscreen mode using page flipping. (Even though
the settings indicate the refresh rate is set to 60 Hz.) If your
game uses a fixed rate of 60 fps (i.e. you expect each frame to take
up no more than 16ms), systems such as mine may not be able to keep
up (because frames can’t go faster than 20ms). I don’t know if the
refresh rate I am getting is typical for laptops.
If you are writing a 2D game aimed at the general public (not
hardcore gamers), 60fps may be too fast for typical consumer
hardware (PII 300, lame video card). On the other hand, if you’re
writing a 3D game, a better approach is not to fix the frame rate,
but use whatever framerate you can get. Movement is now based on
elapsed time – how long the last frame took is how much the objects
have moved. Slower machines may have to disable certain features to
still get decent performance.
What I meant is that this is the rate at which the vertical sync
happens. So if a game runs in fullscreen mode (SDL_FULLSCREEN), uses
a hardware surface video mode (SDL_HWSURFACE), and uses page
flipping (SDL_DOUBLEBUF), the screen cannot be refreshed faster than
52-and-something times per second on my laptop. It does this
independently of the screen’s dimensions and color depth. Since you
develop on a laptop as well, maybe you can measure your vsync
rate – I am curious what refresh rates you are getting.–
Matthijs Hollemans
All Your Software www.allyoursoftware.com
luckily you can do 2 way timing…if the game is running too fast, you can
wait on frames to keep the game sync’d, but also in some types of games you
can also get away with skipping frames if the fps is too low. It isnt
always appropriate to do this though :P> ----- Original Message -----
From: matthijs@allyoursoftware.com (Matthijs Hollemans)
To:
Sent: Monday, November 04, 2002 8:52 AM
Subject: Re: [SDL] Limiting game speed
You’re getting no more than 52fps in 640x480x32?
What I meant is that this is the rate at which the vertical sync
happens. So if a game runs in fullscreen mode (SDL_FULLSCREEN), uses
a hardware surface video mode (SDL_HWSURFACE), and uses page
flipping (SDL_DOUBLEBUF), the screen cannot be refreshed faster than
52-and-something times per second on my laptop. It does this
independently of the screen’s dimensions and color depth. Since you
develop on a laptop as well, maybe you can measure your vsync
rate – I am curious what refresh rates you are getting.
Don’t forget about the poor old people with really slow computers that can’t
handle 50 fps!
I have a game loop which looks something like this :
int currentTime = SDL_GetTicks();
int nextTime = currentTime + timeIncrement;
do {
// frame limiter, based upon timeIncrement;
while(currentTime < nextTime) {
currentTime = SDL_GetTicks();
SDL_Delay();
}
// frame skipper - bring the game back up to speed.
while(nextTime < currentTime) {
nextTime += timeIncrement;
updateGame();
}
} while(!finished());
With the main game logic being in the function updateGame().
That way, you get a game of consistant speed on any computer, and can change
it by modifying timeIncrement. The only problem is that you will get some
latency with the keyboard handling at very low frame rates.
But as has already been mentioned, your game might be better off using
whatever framerate it can get and using the timeslice from the current frame
and the previous to figure out how far to move things.
Cheers,
JasonOn Monday 04 Nov 2002 12:49 pm, Sweeney, Steven (FNB) wrote:
Why? It helps with doing some stuff like timing. Also… when I first wrote
an SDL game, I was getting around 50fps when playing it. People reported it
me they were getting more than 80fps and it was unplayable because it was
too fast. Basically I had coded to rate of enemy fire, etc to be correct
with the frame rate I was comfortable with. For example, an enemy bullet
might take around 2 seconds to cover the length of the screen, but at
faster game rates, it was taking less than a second.
