Large FPS vs consistent FPS

Question

When optimizing the frame rate of a game, when should I focus on a large FPS and when should I focus on a consistent frame rate.

This is often a hotly contested issue, so please note I'm not asking which is better.

What are the pros and cons of each?
In which situations is one preferred over the other?

Also note: my input polling/processing, physics, and game update rates are independent of my frame rate. The only thing the FPS affects is how often a screen is rendered.

Answer 1

This is subjective, of course, but I think that consistency is much more important to game play than speed.

Basically, players will put up with a slower frame-rate if the game is consistent, fun to play and not jarring. However, even if the game totally rocks, if it gives people headaches to look at because it bursts, and/or they can't control things, they will become annoyed & stop playing.

So...

Focus on consistent FPS throughout design & development.

Focus on faster (but still consistent) FPS when the game is nearly done, and you have time to improve performance without worrying about bug fixes, etc.

One way to get better performance is to use callbacks/delegates/interrupts (depending on your language/platform) rather than polling.

Answer 2

Both. I'd say ideally, consistently over 60 frames per second. Realistically, consistently over 30 frames per second. Under 30 frames per second and it starts affecting how well the player can perform (I'm thinking of FPS/twitch-based games by the way, strategy games can probably get by on lower).

If you really had to say one or the other, I'd go with consistency. If you can guarantee a frame rate, then you can focus on moving that guaranteed framerate higher.

Answer 3

It sounds like you've got at least two threads of execution, with your rendering on its own thread. If that's the case, then you actually have two frame rates to worry about. You'll want both to be as fast as possible. However, it also depends on the kind of game you're building.

Are you building a first-person shooter, where small drops in frame rate could give an opponent an advantage? If so, then you'll want to make sure your average fps is high enough, but also worry about your worst-case frame times. Are you building a board game? If so, the occasional frame time spike isn't going to kill the user experience.

In my own games, my process is usually something like this:

• Run a profiler on the code
• Look at the average frame rate. If it's too low on average, bring the averate fps up by optimizing the slow stuff.
• Once average fps is high enough, look for worst-case frame times (frames where you see big spikes in computational or rendering time). Try to optimize those worst-case scenarios to improve worst-case frame time.

If you're at 30 fps most of the time, but you spike to 200ms every 10 seconds, that's going to cause problems. But if you're averaging 15 fps, bring your average fps up first.

So, the short answer would probably be: optimize whatever makes the biggest improvement to the user experience first.

Answer 4

Locking your FPS to a consistent number allows you to:

• Maintain a smooth visual appearance
• Keep animations running in linear time, physics objects falling at a consistent rate between frames, etc.
• However, the most useful part of locking your FPS is that on frames where you have some down time you can do other work--collect garbage, work on streaming in the next area of the map, etc and you will have some headroom when rendering something big and shiny or when knocking down a pile of boxes.

Answer 5

I would think you would want both a consistent and larger FPS. The smoother the graphics (due to refresh rate), the better. If it starts dropping below 30FPS your users are going to start to notice the jitteriness and will become frustrated with lack of response time to actions.

Answer 6

Larger is always better, but:

Inconsistent framerate can lead to motion sickness.

(We had an internal tester throw up when his framerate jumped between 20 and 60 for 10 seconds.)

Answer 7

What you should do:

• Lock game logic to a fixed framerate
• Render graphics as fast as possible

That way, if the framerate drops you don't get input lag (I'm looking at you, Just Cause 2), and if the framerate becomes too high (think games from the 90's) the game doesn't become unplayable.

Here's how I do it:

s_PhysicsCurrent = GetTickCount();
float delta = (float)(s_PhysicsCurrent - s_PhysicsStart);
s_PhysicsStart = s_PhysicsCurrent;

s_PhysicsTime += delta;

while (s_PhysicsTime > ONEFRAME)
{
    // Update
    Game::Tick(ONEFRAME);

    // Clear input
    Keyboard::Clear();
    Mouse::Clear();

    s_PhysicsTime -= ONEFRAME;
}

s_Window->Clear();

Game::Render();

s_Window->Swap();

You basically collect a "stack" of frames to do logic for and you can interpolate between them perfectly.

Answer 8

If you want to prevent tearing, you should use V-sync which will lock the FPS to the refresh rate of the monitor, or lower (if you go higher it won't be visible, so it'd be a waste).

Answer 9

There's only one answer, and that is.. always go for high during development and when your down bring it down to the lowest spike, this will bring the game into a sick steady flow. I'm sitting on the code, and it will stay there because it's my secret way of the coding dragon. /Eyhe