Sign in to follow this  

Controlling High Frame Rate ? Discuss

This topic is 4092 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

Hi All, I want to open an dicussion on Disadvatages of having high Frame rate Or the otherway it could be merits of limiting the frame rate. I am working on a 2D-engine its giving a very high Frame Rate in some of the screens. It goes to 200 to 300 FPS many times. Since the Monitor refresh rate is generally around 60Hz, so i don't find any use of producing a FPS greater than 60.--------Pls Comment? My Questions are: 1) Merits of restricting the frame rate (always less than the refresh rate of mointor). 2) Aproaches to restrict the frame rate. 3) Is making the main thread(Game loop thread) sleep for the extra time, left after finsihing the target FPS, will be usefull? Thanks & Regards

Share this post


Link to post
Share on other sites
A few thoughts, based on four different game-loop and fps-limiting styles:

If game-logic, input, and rendering all operate on the same thread and at the same frequency, and the frequency is not limited:

Pros:

  • Easier to program

  • Input is highly responsive on a good machine

Cons:

  • Game logic/physics/AI won't act precisely the same on each run, and might be significantly different on machines with different levels of performance (example

  • Input might get unpleasantly unresponsive on a not-so-good machine


If game-logic, input, and rendering all operate on the same thread and at the same frequency, and the frequency is limited:

Pros:

  • Still relatively easy to program (though a bit harder than the first method)

  • Game logic/physics/AI will act more or less the same on any machine that is able to maintain the limited frame-rate

Cons:

  • Game logic/physics/AI still won't act precisely the same on each run, and machines that can't maintain the limit frame-rate will still act differently

  • Input responsiveness at the limited frame-rate might not satisfy all players

  • Input might get unpleasantly unresponsive on a not-so-good machine


If rendering occurs separately from game logic, input, and so forth, and the frequency is not limited:

Pros:

  • Game logic/physics/AI will can be made to act exactly the same on each run, on every machine

  • Input can be very responsive, even on slow machines

Cons:

  • Can be significantly more difficult to program than either of the above methods

  • Wastes GPU/CPU power, rendering more often than needed


If rendering occurs separately from game logic, input, and so forth, and the frequency is limited:

Pros:

  • As above, game logic/physics/AI will can be made to act exactly the same on each run, on every machine

  • Again, input can be very responsive, even on slow machines

  • Does not waste GPU/CPU power on excessive rendering (preferably, let user pick frame-rate, so that they can determine what is "excessive")

Cons:

  • Perhaps slightly more difficult to program than the 3rd method, though not by much worth talking about

  • Player doesn't get to brag about ungodly huge frame-rates

Share this post


Link to post
Share on other sites
From what I have seen, it is generally a bad thing to limit the framerate. Yes, it might make some parts of your program easier to code, knowing that they are going to be updated on a regular basis, but it isn't a good idea. If the frame rate drops below 30 fps (or whatever your desired frame rate is) your program may behave erratically. Its generally a much better idea to use time based movement so that the program can run as fast as it wants to. Besides, limiting a game to 30 fps doesn't give users with high end hardware any reason to own high end hardware. When using a variable framerate scheme, they can tweak graphics settings so that things look much better but still will run over 30 fps.

Share this post


Link to post
Share on other sites
For a 2D game it might make sense to turn vsync on, for smoother scrolling and low CPU usage. Downside is that users can force this off, and if your rendering takes too long your fps will drop to about half the monitor refresh.

Limiting framerate with a precision timer doesn't make much sense because your program will be running a timer loop which puts CPU usage on full again. Using Sleep() will avoid this but doesn't have precise timing, I think it's related to the duration of process time slices or something. But combining this with a precision timer might work.

I think it's best to keep track of time with a precision timer and use this in your game logic, so don't use a fixed amount of movement per frame. It might also be a good idea to let your physics run at a fixed frequency to get consistent results, by updating your 'physics time' with fixed intervals until it's equal to 'game time' that you measured with your timer.

Share this post


Link to post
Share on other sites
Movement based on current frame rate is really the only wise choice.
The problem with that is that if your FPS is way too high, and you use ints to hold object positions, those objects might not move at all due to rounding. (EG, a thing is supposed to move 100 units/second, but if the FPS is higher than 100, that thing will try to move <1.0 per frame, and stick in place.)

What I've done in my engine is set an option for max FPS, which makes the engine Sleep() for X ms when it's running too fast. The OS won't hand control back in exactly X ms everytime, but it's usually close enough that nobody notices a difference. I've also put in a min FPS option, which makes the game physics run slower when the game is lagging terribly.

The short answer is, there's no use for an FPS over the current refresh rate, but there's no reason to put a lot of work into preventing it from happening.

Share this post


Link to post
Share on other sites

This topic is 4092 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