Fillrate - Killing frame rates since 1982

Recently I was looking through someone elses unity scene looking for ways to up the frame rate. Said scene had over 100 sprites onscreen and crawled along at a blistering 10 or so fps.

There was a ‘background’ being rendered, a full screen poly, after blowing it away (which changed very little, because it was mostly covered) the frame rate jumped substantially, roughly double, in fact.

So, I thought, as a good way to test how much overdraw you’re using, is to override all materials in your scene with an additve material set to 64,64,64 rgb. Anything that shows up as pure white, is being drawn 4 times, and is starting to hurt your peak fill rate.

After all, fill rate is as big of a nemesis as poly count :slight_smile:

if anyone has a better way to check if a scene is being rendered efficiently, feel free to tell me :slight_smile:

Hey Bentley,

There are a few other little non-Unity tricks you can try to determine if you are fill bound etc. First is to visualize it as you have already done with an additive shader to show overdraw hotspots (this will likely run horribly slow BTW).

You can also simply reduce your viewport size down to something like 1x1 and see if your fps improves. This keeps the T&L burden the same while reducing main-memory fill. This test is one that is easy to enable on-the-fly for problematic scenes.

Another thing you can try is to see if you’re texture fetch limited by replacing your textures (if possible) with 8x8 debug textures (this size is MBX specific). Sprite games often use textures that are too large for their texel:pixel ratio IMO.

Also, recall that fill rate on tile-based architectures does not act like what most folks that come from PC/Console backgrounds expect. BTW - I’m assuming the sprites you mention are alpha blended. It’s a good idea in general to reduce high levels of alpha overdraw for a variety of reasons. When drawing opaque triangles, tile-based systems are blazing fast and can generate very low or even zero per-pixel overdraw in most cases.

Identifying perf bottlenecks is tricky and on the MBX often involves a mix of memory performance, draw call management and scene complexity. When using Unity or other middleware it’s hard to do some other tricks but Rej is likely doing a great job on those items anyway :slight_smile: FYI - In another thread, I linked to a GDC Mobile presentation on tile based rendering that I gave some years ago that may help a little too ( http://forum.unity3d.com/viewtopic.php?p=187948#187948 ) - good luck!

Stephen