Hurry you only have 16 ms to render everything

So I’ve been working on my new game and I’m doing some tweaks here and there on the engine.

Mainly with the rendering section, trying to squeeze as much as possible, thus maintaining an acceptable framerate. It’s not like I’m doing a heavily graphic game but I like to know that It can be used even on slower pcs and that I’m not using more cycles than necessary.

This past week and after reading a bunch of stuff and keynotes from John Carmack about Rage (60FPS ftw) I decided to measure my own stuff.

So let’s break this down, your framerate or FPS is the number of images you draw per second, not just that, you have to animate stuff, play sound, collisions, etc.

Most 3D games nowadays target 30 FPS, it’s the minimum acceptable before you start noticing slowdowns or not so smooth animations, for 2D games it’s a pretty realistic objective to target 60FPS.

Let say you want to target 30 FPS,

  1 second = 1000 milliseconds
  1000/30 = ~33.3 milliseconds

That means that for 30 FPS you have to calculate, animate, do collision and draw the scene in under 33.3 milliseconds. And do it again 30 more times.
Sounds hard doesn’t it?

At 60 FPS it’s even worse

  1000/60 = ~16.6 milliseconds

16.6 milliseconds to do a full loop on your engine. Actually with modern technology it’s not an impressive accomplishment depending on what you are doing but it’s a good practice to
look at these numbers, consider them while you code.

Now I’ve been making some tests on my own engine and I placed 2000 sprites each with a sprite animation and an A* pathfinding (2000 paths can be cached at a time) rendering at 100 FPS.
It runs well and each loops takes 9ms.

   1000/100 = 10ms

Each loop could take up to 10ms, so I’m wasting 1ms for each loop, bringing the sum up to 100ms per second.
When I say waste it doesn’t mean you could be doing something else but you could make you game a bit more CPU friendly make making it sleep that extra millisecond each cycle.
This will actually make you game use less of a processor and you can even check it on the Windows Task Manager.

At just 60 FPS, let’s say I’m drawing everything at 9ms too, but I could take up to 16.6

   16 - 9 = 7ms
   7 * 60 (FPS) = 420ms

You can make your application sleep for almost half of a second and the game would run exactly the same
Isn’t that something?

I’ve made a change on my pump to accommodate this and tested on Vizati, now most of the time it uses 12% of the CPU with bursts of 32%.
Of course by measuring this you can also do cooler stuff like, let’s say you walk by a heavy area, or need to do some calculations, by lowering the intended FPS and drawing less times in that second you can get the other calculations done faster and return to a normal FPS much faster.

Well I hope this wasn’t too boring =)

EDIT:
After talking to some other devs there are mixed feelings about the benefits of putting your application to sleep those extra milliseconds. One thing that’s worth mentioning is that when you put your application to sleep you only guarantee that it will be idle for a minimum of let’s say 5ms, you may only regain control after 7ms, that’s really up to the OS.
So my suggestion is, leave it as an option in the game, CPU throttling or something. Each user may test and see if it benefits, and in a couple of years it may in fact make some difference with to futuristic 30 core cpu where you don’t need to be using 100% of it. Starcraft 1 got a patch to do just that some time ago.

One Comment

  1. Ape

    In javascript, there is a function you can call that makes the browser handle the frame synchronization called requestAnimationFrame. It does some neat things like slow the game down when you are not in the tab (saving battery life of a laptop!) and other great freatures like that. Perhaps there are ways to do this on other platforms? I know that enabling v-sync can cause a similar effect depending on how you set up your rendering pipeline.

    google did a presentation on the issue, but I can’t find the youtube video. However you can read more about requestAnimationFrame here: http://www.nczonline.net/blog/2011/05/03/better-javascript-animations-with-requestanimationframe/

    Just say no to busywaiting!

Leave a Reply