Performance - Why 200fps is not good.

I see a lot of new developers get excited when the Unity Stats panel is showing that their game is running at 200 frames per second (fps). And this is good, yes? Well, no, actually it isn't.

Currently I am doing a lot of development for the Quest 2 and on this device (which is inherently an Android phone) frames per second are paramount for screen refresh. So frames per second is a good way of judging the performance of your game, but do not get excited about 200 fps in the Unity Editor window.

For example, my current work-in-progress runs at 890 fps in the Unity editor window when it is docked in the Editor frame. But my development machine is a fully kitted out Ryzen-9, so it should get at least that. Interestingly, when I un-dock the game window from the Editor and drag it to another monitor, the fps drops to 572. This suggests an overhead in Unity when windows are not docked.

This is an actual screen shot from the Quest 2, flying a space fighter in WebXR.

If I then build and run the resulting app on the same machine, frame rate drops again to to 370 fps, which suggests that Unity Stats are not really accurate, and on an older machine without all the bells and whistles, it drops to 190 fps. When I build for mobile, on the iPhone X it runs at 160, an on an older Android phone, it drops to 120 fps.

But I am developing this game for Quest, so what happens there?

On the Quest 2 native, it runs at 110 fps (although the Quest 2 is capped at 90 fps unless you tweak it - basically it is tied to the refresh rate), but in WebXR (VR on the Web), I am down to 57 fps on the Quest 2 and 42 fps on the Quest 1. All this when starting at 890 frames per second in the Editor. So basically, to get to the capped 90 fps on the Quest 2 and the capped 72 fps on the quest 1 which is my target, need well over 1000 frames per second in the Editor.

In summary, the Unity stats panel is basically estimating the game frames per second. In a blank scene, you will get over 3000 fps. Add a UI counter to this and it will show around 400 fps. Build and run on you machine, it will be tied to the screen refresh rate and probably show 60 fps if you have VSync on in the quality settings (more on this regarding different devices in the Patreon Post). The trick is to use the same method each time for a benchmark comparisons, and learn how to use the Unity profiler to find bottlenecks.

Before you get tired of reading, let me mention one last thing. Always, and I mean always, test on the slowest device you have, even if it is not your perceived target device. I test on my Quest 1 even though my market will be Quest 2. If you are targeting PC users, drag out an old laptop or your last machine before you upgraded and set that up as a test bench. Not all computer games are hardcore and can afford a state of the art system. And for Mobile, test on the oldest one you have that still works.

Some of you will say that you are targeting high-end Mobiles, maybe you create games for children and they will use their parents phone. Perhaps, but if you game is successful and the child wants to play it all the time, the parents will either give them their old phone, or purchase a low spec cheap mobile for their gaming.

To wrap this up, I will publish some FPS Counter code for Patreons. While there are many  snippets of code available to do this, not all of them are accurate, although they do give you a benchmark if you use the same one each time. In the same post, I will also document the main areas you should look for when you strive to get that elusive 1000 frames per second and if it is possible at all.
© 2022 Copyright: CranberryBlue R&D Limited