# How would I set a "maximum FPS"?

## Recommended Posts

DarkCybo1    172
As in, I wouldnt want my program to ever go faster then 60 FPS?

##### Share on other sites
Wytter    156
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 on other sites
oliii    2196
call the windows message pump until the time elapsed since last frame = your frame tick rate.

##### Share on other sites
TDragon    679
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 on other sites
_the_phantom_    11250
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 on other sites
TDragon    679
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 on other sites
intrest86    742
Quote:
 Original post by TDragon60 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 on other sites
m4gnus    240
@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 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 on other sites
ursus    206
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 on other sites
_the_phantom_    11250
Quote:
 Original post by ursus..i now consider setting a fixed frame rate for my next game.

I hope thats a fixed world update rate, not a fixed redraw rate...

##### Share on other sites
ursus    206
sure it's the real world update rate! i don't think any human being would be able to function with frame rate over 60!

##### Share on other sites
helix    301
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 on other sites
TDragon    679
Quote:
 Original post by intrest86Everything 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 on other sites
Mantear    251
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 on other sites
TDragon    679
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 on other sites
oliii    2196
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 on other sites
_the_phantom_    11250
Quote:
 Original post by oliiithere 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 TDragonBy 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 on other sites
TDragon    679
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