Jump to content

View more

Image of the Day

Working on an auto spawn system. #gamedev #indiedev #screenshotsaturday https://t.co/Mm2kfekz7b
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

How do you benchmark your game?

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Ed Welch   Members   


Posted 23 March 2013 - 10:37 AM

Do you think it's a good idea to use more metrics than just average frame rate when testing render performance? I mean 95th percentile, minimium frame rate, etc.


#2 NiteLordz   Members   


Posted 23 March 2013 - 11:38 AM

I track CPU memory use along w/ a breakdown of functions timing in ms.
Code makes the man

#3 MJP   Moderators   


Posted 23 March 2013 - 01:47 PM


Yeah average framerate alone definitely isn't enough. You really want a graph of frame times (don't use FPS, it's non-linear) so that you can clearly see if there's any spikes, fluctuations, or stuttering. A highly variable frame time results in a very bad playing experience, even if the average frame rate is still "high". So a game that's locked at a constant 33.3ms (30fps) will often be perceived as "smoother' than a game that averages close to 16.6ms (60fps) but fluctuates from frame to frame.

Edited by MJP, 24 March 2013 - 12:28 AM.

#4 Servant of the Lord   Members   


Posted 23 March 2013 - 01:50 PM

Profiling helps identify bottlenecks, when looking to optimize. Profilers tell you the average amount of time a function takes, and even more importantly, the number of times it is called during a specific program run. Saving 10ms on a function that is only called 20 times a frame isn't as good as saving 1 ms on a function that is called two hundred thousand times a frame.

Edited by Servant of the Lord, 23 March 2013 - 01:53 PM.

It's perfectly fine to abbreviate my username to 'Servant' or 'SotL' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal | [Fly with me on Twitter]

#5 MichaelNIII   Members   


Posted 23 March 2013 - 09:47 PM

Fps is a bad test - as in, if you are testing the whole range of possible inputs (which you kinda should check, at the very least checking the limits)- you could speed up the avarage fps - and perhaps make every number modulously divided by 5 much slower then the avarage resulting in jumpy gameplay even though the function on avarage is faster.

Mapping out your program/parts of your program by hand before you dive into writing them often saves a lot of time when it comes to optimizing, as you should be able to see where your bottlenecks are likely to accure if you would of attempted to write it the way you origionally intended and can code with the intent on not having certain bottlenecks.

#6 mightypigeon   Members   


Posted 30 March 2013 - 12:01 AM

Speaking of profiling and performance tracking, riting your own lightweight profiler is a great way to keep on top of how different bits of your game are performing.  You set it to run per-frame and record timings for various bits of code.  This is valuable for knowing where to look when you get performance drops during development - you might think the hit may be coming from what you're working on, but another part of the code has been affected.


A good example/tutorial is here:



I wrap certain functions up (culling, physics update, particles update, game code update, rendering, etc etc) in a profiling event and output a colour coded graph so I can quickly see what's going on.  No where near as fine grained as a proper profiler but I feel it's much more useful!

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.