Mobile performance - rendering specifically.

So I’m assuming semi complex event tick functions are generally something to stay away from but I expect draw calls to be more of an issue, for me at least.

What’s a good DC number to stay below these days? I hear anything from 30 to 300… I expected 30 to be where I should aim but I might’ve been too cautious there?

Also, particle emissions seem to swallow DC’s -

How does one handle textures/sprites/images in the best way? Not larger than 4k * 4k and try to fit in as many sprites into that as possible or does the number of images not have a major impact?


Draw call number depends on your target devices, the best info you can get is to setup a representative scene (different meshes, different materials) and run it on your slowest platform and see how the rendering thread is (‘stat unit’). I’d say around 300 for iPhone 4S and above as a ballpark figure.

Mesh emitters can explode your draw call count easily, so watch out. However recently we made a faster rendering path for them. They are still one draw call per particle, but a lot less engine overhead involved in drawing them.

For flipbook textures, the size of the texture doesn’t have much impact on performance, just on memory.

Great, thanks. And the number of textures don’t matter? I’m mainly wondering if one 4k4k is better than two 2k2k…

4K on Mobile?!

One 4K would never be better than two 2K textures. You can get four 2K textures inside one 4K.

For mobile, I would stick with 2K, or even dumb it down to 1K textures. It will look perfectly acceptable on a smaller screen.



The comparison was hypothetical mainly, 4k is probably overkill indeed. :slight_smile:

And yes, four 2k textures fit into one 4k (oops - brain fart) but what I’d do would be to put all those 2k textures into my single 4k.

My main question was really if the number of textures mattered or if it’s just the total memory sum of all textures combined. It might seem logical that if the device can load all sprites from a single file (texture) you can gain some advantages. I’m basing that mainly on loosely made assumptions drawn from my own fading memory banks based on articles I might’ve read in recent history. Struggled to find info when I looked into it again so thanks for any input!

I don’t think 4K is necessarily unreasonable on mobile. It depends on how much you are packing into one texture. If you model an entire house (or all your game sprites) mapped with one set of UVs it will look blurry with 1K textures. You would just lose flexibility because using any piece of the house (or any one of your sprites) would require the master texture in memory.

In theory, bigger the textures mean fewer texture state changes (i.e. draw calls) so it should be faster, but on mobile there is usually no distinction between GPU and CPU memory. With newer mobile APIs (like Metal for iOS) the cost for a draw call that swaps textures should be much less. With standard OpenGL drivers it would have to re-transfer the texture from the CPU to the GPU, but with Metal it should just be able to swap a texture pointer so batching textures will be less crucial for performance.

In practice, it’s probably best to batch as much as you can still–just group all your textures that will always be used together. You might use a 1K texture for power-ups that you reuse every level, but your main level sprite sheet could be 4K if you have a large and detailed sprite sheet. I would start there at least; it’s always easy to downsample to 2K if memory becomes an issue.

That gives me a good starting ground, thanks a lot for the explanation!