Hi 'yall
I need help with how I limit the fps in my programs. The documentation
availible did not help me much. If someone could demonstrate it with
some (simple) code I would really appreciate it.
Thanks
Alexander Backlund
“Alexander Backlund” schrieb im Newsbeitrag
news:3AF4A516.1040104 at crosswinds.net…
Hi 'yall
I need help with how I limit the fps in my programs. The documentation
availible did not help me much. If someone could demonstrate it with
some (simple) code I would really appreciate it.Thanks
Alexander Backlund
i’m doing it this way :
Uint32 wait=(Uint32)(1000 / framerate);
Uint32 cticks,bticks;
while(!done) {
bticks=SDL_GetTicks();
draw_something();
cticks=SDL_GetTicks();
if ( (cticks-bticks) < wait )
{
/framerate exceeded limit…so we wait the difference/
SDL_Delay( wait-(cticks-bticks) );
}
}
I get the feeling that maybe you are going about this the wrong way.
Why exactly would you want to limit the framerate? I think what you
really want to do is limit the speed of your animation. You can do this
by determining how much time has elapsed since the last frame, and using
that combined with a velocity to calculate the distance to move. As an
example:
// in the main loop
curFrameTime = SDL_GetTicks();
do_motion(curFrameTime - lastFrameTime);
lastFrameTime = curFrameTime;
// in do_motion
GLdouble elapsedSec = timeElapsed / 1000.0;
// move according to velocity
pos[0] += elapsedSec * velocity[0];
pos[1] += elapsedSec * velocity[1];
Doing your motion this way will make it dependent only on time elapsed,
not on framerate. Therefore, you don’t need to limit your framerate,
which is a strange idea anyway, and your motion runs the same on any
machine.
-Ted
Alexander Backlund wrote:> Hi 'yall
I need help with how I limit the fps in my programs. The documentation
availible did not help me much. If someone could demonstrate it with
some (simple) code I would really appreciate it.Thanks
Alexander Backlund
I get the feeling that maybe you are going about this the wrong way.
Why exactly would you want to limit the framerate? I think what you
really want to do is limit the speed of your animation. You can do this
The only reason I could think of is if you have something else running at
the same time that needs CPU too and you dont want to starve it because
all your CPU is going into graphics.
-Larry
Of Lawrence W. Leung
I get the feeling that maybe you are going about this the wrong way.
Why exactly would you want to limit the framerate? I think what you
really want to do is limit the speed of your animation. You can do this
The only reason I could think of is if you have something else running at
the same time that needs CPU too and you dont want to starve it because
all your CPU is going into graphics.-Larry
Perhaps to maybe skip frames when running on slower computers and idle when
the computer is too fast. Basically to have a consistant virtual frame rate
no matter what speed the computer is.I can see where limiting the frame rate for really fast computers when your
program animates at the maximum speed the computer can put out. Anyone ever
try and play their 286-class games on their Pentiums? The old games were
designed with the slow computer in mind, so they just go full throttle, even
on a fast PC, which makes in impossible to play. Ultima 7 experiences this
problem too (was the right speed on a 386/486<33Mhz, anything faster you
couldn’t play it, the Avatar would be on the other side of Britannia by the
time you released the button.)Music tends to be one of those things that are frame-rate specific, (Anyone
ever try play an Adlib-only music game on a Pentium?) Where the music is
supposed to be syncronized with the frame rate so the animation goes in
sync. … I think every Origin product between Ultima 6 and 8 had the “Runs
too fast to play” problem. The Training Flight simulator in Wing Commander 1
runs way too fast on a pentium machine. The opening would have gone through
it’s entire sequnce before the music got to play more than a dozen notes.
The arcade game/trainer in Wing Commander 1 would go so fast that you didn’t
have the chance to fire on the enemy before the time expired.Sierra games do not have this problem because they all implemented "speed"
controls that basically slow down the game. In the early games you could
switch between “slow, normal, fast, and fastest” in which Fastest was the
equivilent of turning off the speed limiter. In later games, they put in a
varible slider that allowed the user to fine-tune the speed. Though there is
another consistant problem with the sierra games, mainly the sound blaster
wave driver on the SCI games that started using samples for sound effects
was programmed in a way that anything over a 386 would be too fast and would
lock up the game. They released a patched driver for 486’s, but the problem
came back with the pentium series of processors.So, In my opinion it’s not so much “frame rate limiting” that should be
looked into, but rather internal game speed syncronization. Game too slow,
skip a few redraws. Game too fast, idle between frames to slow it down.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com----- Original Message -----
From: owner-sdl@lokigames.com [mailto:owner-sdl at lokigames.com]On Behalf
Sent: May 6, 2001 12:40 PM
To: sdl at lokigames.com
Subject: Re: [SDL] Frame rate limiting
Kisai wrote:
Of Lawrence W. Leung
I get the feeling that maybe you are going about this the wrong way.
Why exactly would you want to limit the framerate? I think what you
really want to do is limit the speed of your animation. You can do thisThe only reason I could think of is if you have something else running at
the same time that needs CPU too and you dont want to starve it because
all your CPU is going into graphics.-Larry
Perhaps to maybe skip frames when running on slower computers and idle when
the computer is too fast. Basically to have a consistant virtual frame rate
no matter what speed the computer is.
Did either of you read all the way through my last email? The code I
pasted should work around both of these problems. Your graphics routine
should be getting called in sequence, and taking up only the time it
takes to draw a frame. Your other code runs before or after it, so it
should be getting called just as often as the graphics code, with
nothing being “starved.” As for things running at a consistent speed,
that’s exactly what my code snippet did, limit movement by the amount of
time elapsed between frames.
So, In my opinion it’s not so much “frame rate limiting” that should be
looked into, but rather internal game speed syncronization. Game too slow,
skip a few redraws. Game too fast, idle between frames to slow it down.
You shouldn’t have to worry about skipping frames or anything, just let
the computer draw as many frames as it can handle, and limit the speed
of your world representation, not the graphics themselves.
-Ted> -----Original Message-----
From: owner-sdl at lokigames.com [mailto:owner-sdl at lokigames.com]On Behalf
Sent: May 6, 2001 12:40 PM
To: sdl at lokigames.com
Subject: Re: [SDL] Frame rate limiting
Did either of you read all the way through my last email? The code I
pasted should work around both of these problems. Your graphics routine
should be getting called in sequence, and taking up only the time it
takes to draw a frame. Your other code runs before or after it, so it
should be getting called just as often as the graphics code, with
nothing being “starved.” As for things running at a consistent speed,
I didn’t say your approach was wrong. I have a program that does just
what you proposed and it uses 100% cpu when it runs…
-Larry
Ah, my apologies. I see what you’re getting at. My solution to that is
to never try to do anything else while I’m playing games 
-Ted
Lawrence W. Leung wrote:> I didn’t say your approach was wrong. I have a program that does just
what you proposed and it uses 100% cpu when it runs…
-Larry
“Lawrence W. Leung” wrote in message
news:Pine.SOL.4.30.0105061702430.6936-100000 at quasar.CS.Berkeley.EDU…
I didn’t say your approach was wrong. I have a program that does just
what you proposed and it uses 100% cpu when it runs…
I think there is something wrong with that approach: it’s not as
deterministic as a fixed frame rate. This may cause strange behavior on
vary fast or very slow computers (e.g. objects moving through walls or
objects not moving at all), and it makes any kind of synchronization (think
multiplayer or demo playback) much more difficult. I would not want to
debug such a beast.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Works well for 3D games, but usually is more work for 2D games. And despite
what anyone may believe, 2D games are not dead, and never will be. You have
to keep in mind that there’s more than one way to solve almost any problem
when it comes to game design. It’s great to offer alternate method to fellow
programmers that they might not have considered, however it’s rather arrogant
to think the way they have chosen is probably the wrong way when you know
nothing at all about their game or it’s design goals. I’m not flaming you,
just trying to broaden your mind a little. Have a nice day.On Sunday 06 May 2001 12:39, you wrote:
I get the feeling that maybe you are going about this the wrong way.
Why exactly would you want to limit the framerate? I think what you
really want to do is limit the speed of your animation. You can do this
by determining how much time has elapsed since the last frame, and using
that combined with a velocity to calculate the distance to move.
Oh god yes, heh. Having worked on a commercial game trying to get the demo
system to work and using movement based on frametime, I can tell you first
hand how much of a nightmare it is. We never did get it working, though I
think we were getting close. It was finally decided that we should abandon
the attempt, since it was costing us too many man-hours. So just a little
wisdom to pass along that might help someone out someday.On Sunday 06 May 2001 19:19, you wrote:
“Lawrence W. Leung” wrote in message
news:Pine.SOL.4.30.0105061702430.6936-100000 at quasar.CS.Berkeley.EDU…I didn’t say your approach was wrong. I have a program that does just
what you proposed and it uses 100% cpu when it runs…I think there is something wrong with that approach: it’s not as
deterministic as a fixed frame rate. This may cause strange behavior on
vary fast or very slow computers (e.g. objects moving through walls or
objects not moving at all), and it makes any kind of synchronization (think
multiplayer or demo playback) much more difficult. I would not want to
debug such a beast.