Sign in to follow this  

How would I set a "maximum FPS"?

This topic is 4529 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In Eternal Lands we've set up the following in the renderer:


if(!limit_fps || ((cur_time-last_time) && (1000/(cur_time-last_time) < limit_fps)))
{
//draw everything
draw_scene();
last_time=cur_time;
}
else
SDL_Delay(1);//give up timeslice for anyone else

cur_time is an integer measuring the time in ms since the program was started. last_time denotes the last time we rendered the scene. You can naturally use anything for sleeping 1 ms (and even change how long you wish the application to sleep), we just use SDL in EL, which is cross-platform.

You can calculate the FPS based on the cur_time and last_time, but it will be quite inaccurate hence you won't see the real FPS (and you'll experience that the FPS can jump a lot). In EL we just count the # of frames drawn per second, then set the FPS to this in order to reduce the fluctation of the FPS - This means that it's only updated once every second, so if you want to do it faster, you can split it up (say 4 times per second would mean that the FPS is 4*counted_fps).

Share this post


Link to post
Share on other sites
The method I use in the main loop of my engine is something like this:

this_ticks = GetTicks();
if (this_ticks - last_ticks > (1000 / 60))
{
//Run the main engine stuff here
last_ticks = this_ticks;
}
else
Sleep(0);



GetTicks() is, in this case, a function that returns some (unimportant) value in milliseconds. So if 1000/60 milliseconds go by, the game gets updated.

If you're not programming with the Win32 API, replace Sleep(0) with whatever function yields the remainder of the timeslice to your OS. It's always nice to do this, in case the user happens to be running other important programs in the background. (The OS would still give the other programs time without the Sleep() call, but not all that it could be.)

EDIT:
Wytter's solution, posted while I was still writing mine, is nearly identical. Kewl :D

Share this post


Link to post
Share on other sites
what is it with people wanting to limit the FPS? I'd go crazy if I was playing something which forced my refresh rate to 60fps (not least because I get eye strain below 75hz), infact thats a sureway to cause an instant delete...

The better method is to limit the world update rate and let the gfx card render as often as needed.

my standard link to the Canoical Game Loop which more people should be using.

Share this post


Link to post
Share on other sites
60 FPS is the US standard for zillions of things, games included. In every book and article I've read on the subject, 60 is the sweet spot to aim for right now. That being the case, I wouldn't be surprised if half the games on the shelves of [insert your local superstore, such as Wal-Mart, here] are running at 60. That being said, the thing to do (the method I actually use, for now at least) is to v-sync it -- that is, render at most once for every vertical retrace. There's no point in doing it any more often than that.

Share this post


Link to post
Share on other sites
Quote:
Original post by TDragon
60 FPS is the US standard for zillions of things, games included. In every book and article I've read on the subject, 60 is the sweet spot to aim for right now. That being the case, I wouldn't be surprised if half the games on the shelves of [insert your local superstore, such as Wal-Mart, here] are running at 60. That being said, the thing to do (the method I actually use, for now at least) is to v-sync it -- that is, render at most once for every vertical retrace. There's no point in doing it any more often than that.

Everything is going 60 because that is as fast as they can run. They are not arbitrarly limiting ther games to 60, they are making games go as quickly as they can and being able to go 60.

What is going to happen to your game when the framerate dips to 30? That is still in the playable range, but if you are updating everything based on a "change per frame" method everything is going half as fast!

Share this post


Link to post
Share on other sites
@intrest:
I don't limit my games to a special framerate but the game movement is game independet. Doing that is really no big deal. You just have to have a global frametime variable which stores the time the game needed for the last frame. btw i haven't played a game that limits it's framerate so far...

regards,
m4gnus

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
When I got used to 72HZ in my game there's really no going back to 60 now. But I doubt many casual gamers notice the difference.

Share this post


Link to post
Share on other sites
while developing my last game i ran across the same problem intrest86 mentiones. there was far too much code to start over so i got around the problem by adding additional timers, for example:

if (key_pressed && key_time<=0)
{
key_time=.01;
move_sprite();
}

key_time-=frame_time;

that works fine but i had to add many timers (every key, mouse buttons, accelerations, bacground scrolling, sounds, etc) and i ended up with so many timers i now consider setting a fixed frame rate for my next game.

Share this post


Link to post
Share on other sites
I like to provide frame limiting as an option in my games. I personally don't like being locked into a specific framerate.

I would cache the value you are using to limit (1000 / 60) so you don't perform a divide each frame.

Share this post


Link to post
Share on other sites
Quote:
Original post by intrest86
Everything is going 60 because that is as fast as they can run. They are not arbitrarly limiting ther games to 60, they are making games go as quickly as they can and being able to go 60.

What is going to happen to your game when the framerate dips to 30? That is still in the playable range, but if you are updating everything based on a "change per frame" method everything is going half as fast!


No, that's not as fast as they can run. My computer, not even a top-of-the-line machine, can get hundreds of FPS when unleashed on 3d-intensive tasks. The main reason 60 FPS is aimed for (in the US) is that NTSC signal transmission is 60hz. In any case, I intended that more as a sidenote to the fact that it's best to use the v-sync method. Of course you'll notice that I said "at most once for every vertical retrace". My poor little laptop can only get 30-40 fps on the engine I'm designing right now, so of course rendering occurs less often and of course I have to account for that. Actually, you can't tell much of a difference since the movement is still the same per unit time, and for the most part is still less than a pixel difference.

Oh, and @helix - Any compiler worth its salt will do the divide at compile time for you...not that it makes a nanosecond difference on a P4/Athlon...

Share this post


Link to post
Share on other sites
Why would you ever want to artificially limit the FPS? You're going to have to account for non-constant frame rates anyways if any of the computers you plan to run the software on ever has a chance of falling bellow your predetermined rate. If the end-user wants to limit their FPS, they can just turn on V-sync themselves.

Share this post


Link to post
Share on other sites
By limiting the FPS to the refresh rate, you are making sure the program doesn't consume unnecessary CPU time, instead returning it to the OS where it can be used for other processes running in the background. Rule 1 of Programming: Always play nice with multitasking :) (well, maybe not rule 1, but pretty important nonetheless). And of course I'm not advocating that you code with a constant game state update frame rate in mind, but with a constant delta vs. time in mind. Two different cats, and a million ways of skinning each.

Share this post


Link to post
Share on other sites
there is nothing wrong with limiting frame rate. Sometimes, it's necessary, when the game runs so fast, you get FP inacuracies (mostly on the delta time) so severe it will brake the game. I'd limit it to 100hz personnaly. [grin]

Share this post


Link to post
Share on other sites
Quote:
Original post by oliii
there is nothing wrong with limiting frame rate. Sometimes, it's necessary, when the game runs so fast, you get FP inacuracies (mostly on the delta time) so severe it will brake the game. I'd limit it to 100hz personnaly. [grin]


Which is why you fix the world update rate which should be independant of the frame redraw rate, see my earlier post for an example of this.

Quote:
Original post by TDragon
By limiting the FPS to the refresh rate, you are making sure the program doesn't consume unnecessary CPU time, instead returning it to the OS where it can be used for other processes running in the background. Rule 1 of Programming: Always play nice with multitasking :) (well, maybe not rule 1, but pretty important nonetheless). And of course I'm not advocating that you code with a constant game state update frame rate in mind, but with a constant delta vs. time in mind. Two different cats, and a million ways of skinning each.


Define 'unnecessary CPU time'?
If a game is running fullscreen then the user has already given their agreement that it can run as fast as possible, V-syncing and blocking on IO and other stalls will allow the pre-emptive OS you are running on to swap the task out as and when it wants to, so other processes wont starve. If a user turns off v-sync they have effectively told you 'hey, render as fast as you can!'

So, my game, when it has focus, will use as much CPU time as required, options will be given to allow the user to restrict frame rate if needs be (thinking mostly of laptop users) and ofcourse v-sync lets you limit framerate as well (which is a blocking call, which can cause your thread to be swapped out, again freeing time to the CPU), however all of this are user options, not enforced by the programmer in some draconian manner, but optionally avaible if the end user wants them for some reason, if the end user wants to the program to throw out frames as fast as it can who are we to stop them?

Thus my advocation of a fixed world update step, it lets you render as fast as possible while stoppping your calculations from becoming unstable when you update the world.

Frankly, if you cant see the advantages of this system then I dispair, its not like I dont like a good chunk of code in everything thread to help either [smile]

Share this post


Link to post
Share on other sites
Meh, I guess what I said didn't come out quite right. What I mean to say is, framerate can be limited by the programmer not to be higher than the user's refresh rate. There would be absolutely no difference in what is displayed onscreen at a framerate of 75 and at a framerate of 105 if the user has a 75hz refresh rate from their video card to their monitor. So anything above 75 FPS (in this case) is "unnecessary CPU time". That's not to say that every draw should necessarily be v-synced -- because if you're running at BELOW 75 FPS, there will be a difference. So all I'm saying is, have the refresh rate as a maximum -- in my case, by implementing a 3-state system that only renders if the v-sync indicator is 1 (which means we're getting max FPS equal to or greater than refresh rate) or 2 (which means we're not matching the refresh rate). Each v-sync EVENT increments the state (up to 2); each render decrements it.

Oh, and always keep in mind that the end user is a complete idiot who will destroy their computer if you make it easy enough for them. Not this is something that could destroy a computer...but what I mean is, if render FPS above and beyond the refresh rate is completely meaningless, help the user out with more CPU time for other processes instead.

World update time, as we all know, is a completely different story. It can be fixed, tied to the renderer, or in a whole different thread, or whatever. Nobody really cares, as long as it works correctly. Keeping it in the same loop as the renderer is the easiest. Just have to make sure you calculate everything based on frame time.

Ta,
Twilight Dragon

Share this post


Link to post
Share on other sites

This topic is 4529 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this