Rachels Lab Notes

Game Development as seen through the Blum Filter

“Frames per second” is not relevant

with 8 comments

Insomniacs Mike Acton created quite a stir when he claimed yesterday that keeping your game at 60fps doesn’t matter. Unfortunately, his article bases this only on correlation between frame rate and final score. While it’s of great importance to the business end of making games, there’s little reasoning on the technical side why 60fps and 30fps make so little difference.

(Based on what else I read from Mike, I’m sure he’s reasoned about it alright – it’s just not part of this particular article.)

The concept of frame rate matters at all because the update rate of the entire world is tied to the refresh rate – the game progresses “one frame” at a time. That, in turn, is done since the final draw that a world update triggers needs to be tied to the screen refresh to avoid screen tearing)

But “the world” is not a monolithic block – games do many things, and the order in which you do them matters very much. Mick West has an excellent article on what he calls “response lag” – the time it takes for a button press to finally cause a result on screen. And effectively, you measure this lag time by stating how often you need to run “the world” (or the main game loop) until the input causes a visible effect.

That, in turn, means that with the same internal delay, a 30fps game takes twice as long to react to a button press as a 60fps game. Now, if your game is well engineered, that internal delay is “only” 3-4 frames. At 30fps, that’s just below the human reaction time – that’s why most gamers don’t complain about 30fps if it’s a well-engineered game engine.

Things start to get different once the gamer is not reacting, but planning ahead and trying to hit a button at an exact time. Music games, for example. Or FPS players who lead a shot. Here what matters is not so much the lag per se – we can learn to anticipate that. What matters is that that lag is constant, so there are no timing surprises.

So what matters is predictable lag that does not exceed the human reaction time – which is just so achievable with 30fps, and a monolithic step function.

And that’s the core assumption everybody was making for the “60fps or die” argument – your step function is monolithic. It was, for a long time, with a single core synced to the screen refresh. That argument simply isn’t true any more.

We have multiple cores available that can run completely decoupled from each other1. That means, for example, that I can sample the controller at a much higher rate than I refresh the screen. We might run the physics engine at a time step significantly shorter than the duration of a single frame. In other words, we can run components of the world at different speeds and only have the drawing synced to the screen.

The tricky issue here is that we are sampling – aliasing effects can be introduced along the way. Which is really all that “lag” is – it’s the result of discrete sampling of a continuous world.

And that is the part that surprises me most – while we have a ton of really smart guys working on keeping our lag small, nobody seems to treat it as an aliasing problem, bringing signal theory to bear on it. Am I missing something?

  1. Multi-core is not a panacea. Any fixed overhead you incur by frame compels you to lower framerates. If you have a fixed absolute overhead for distributing tasks, it takes a larger relative chunk of a 16ms frame than a 33ms frame. 

Written by labmistress

October 30th, 2009 at 8:43 am

Posted in Uncategorized

8 Responses to '“Frames per second” is not relevant'

Subscribe to comments with RSS or TrackBack to '“Frames per second” is not relevant'.

  1. Mick West*


    30 Oct 09 at 10:35 am

  2. I’ve been a professional developer working in systems level software for servers for years. I recently began getting into game development, and honestly don’t understand why (on PC based games) there is still a lock-step with framerate for processing of the game components. With so much of the rendering pipeline taking place on the GPU, even without a multi-core CPU, you can do the actual game logic in a separate thread from the rendering loop and have a dramatic increase in frame rate and responsiveness.

    The amount that developers compalin about the PS3 seems to indicate a resistence to this type of processing model, yet the only explainations I hear from people is that threading is hard. I imagine in the future there will be middleware libraries available that implement all the necessary locking internally so that the developers won’t need to worry about whether the engine multi-threaded, multi-process, or a monolithic game loop.


    30 Oct 09 at 10:36 am

  3. @anon: Ooops. Sorry. Fixed.


    You need to be careful with asynchronous processing. As I alluded to in the last paragraph, you will create aliasing artifacts if different subsystems run on desynchronized clocks. That’s why I’m think modelling a game using signal theory might not be the worst idea. Searching for research, nothing found yet.

    As for the PS3: It’s not threading that’s hard, per se. It’s the fact that it’s a new paradigm, and that Sony always manages to make their hardware hard to develop for. I personally think they do it so titles can increase in quality over lifetime of console.

    As for the middleware – they will all need a threading solution. And if they all have a separate one, I can’t wait to see the fun that ensues when you connect them ;)

    We might very well see some consolidation in that space.


    30 Oct 09 at 11:06 am

  4. You are absolutely right, games need to separate the rates for drawing, physics, and input. I don’t know if it is the same for everyone, but I find that 30fps looks choppy when there is a lot of motion on the screen. Movies run at 24fps in theaters which looks fine when there isn’t much motion on the screen, but as soon as the camera pans too fast you get visual tearing. 60fps will allow for a smooth picture no matter how fast the camera moves. For some games, there isn’t enough motion to need a 60fps rate.


    30 Oct 09 at 11:54 am

  5. @Blacktiger: Actually, movies run at 72fps – they just run the same frame 3 times. And due to some weird physiological stuff, your eye likes that better than 24 fps.

    Fast camera pans shouldn’t cause tearing in movies, but motion blur. I’d be interested to see a movie that tears instead. (Digital FX, maybe?)

    And in that same vein, if games actually did proper motion blur, they might very well get away with 30fps rendering. (You can still draw at 60 fps if you keep that independent from the 3D rendering)


    30 Oct 09 at 12:19 pm

  6. Agreed. I am glad I am not the only one thinking this. Sure 30 fps may chop a little with a very fast turn, but I cant see how anyone would notice anything more than 50 fps.

    Really, people should now be concentrating on the quality of the content, not the frame rate.

    Archiform 3D

    31 Oct 09 at 7:41 am

  7. Agreed. I am glad I am not the only one thinking this. Sure 30 fps may chop a little with a very fast turn, but I cant see how anyone would notice anything more than 50 fps.

    Really, people should now be concentrating on the quality of the content, not the frame rate.


    19 May 10 at 10:22 am

  8. Thank you so much for giving everyone an exceptionally wonderful chance to read in detail from this blog. It’s always very good and also packed with a lot of fun for me and my office fellow workers to search the blog really three times in 7 days to study the fresh issues you have got. Of course, we are always satisfied with the terrific information served by you. Selected 2 points in this posting are essentially the most suitable I have had.


    6 May 13 at 8:27 pm

Leave a Reply