Performance on mobile isn't as bad as we think

[Apologies if this should go in Open Topic, I wasn't quite sure.]

Hey all,

I was just reading this interesting paper by the creator of Aquaria, who also ported the game to ipad. It shows that, as we know, graphics performance on mobile is largely limited by the pixel fill rate.

One statement in particular interested me. Even in a native app, the latest ipad can only draw 4x the size of the screen and keep a steady rate of 60fps (not counting overhead performance). Ashley has been telling us this all along (but we keep complaining!), along with the fact that native developers often use optimization tricks to make the games run faster. This paper shows one such example.

The paper goes on to state that 2D games with hi-res art (pretty much all C2 games fall into this category) are as such very hard to make as they don't take full advantage of optimized 3D graphics processing in such devices - they suffer from overdraw as graphics are laid on top of each other - even transparent pixels have to be drawn!.

The rest of the paper describes how the developer essentially 'cuts out' every 2D image and puts them on a 3D 'canvas' - using the 3D technology so that overdraw is no longer a problem. He reports significant performance benefits.

Obviously something like this would be non-trivial to integrate into C2, probably even impossible (maybe once webGL becomes more widespread). However, it gives a good perspective and shows us that HTML5's mobile performance isn't as bad as we think.

Any thoughts?

(Please correct me if my ignorance caused me to butcher the facts!)

I haven't read the paper yet, but you're correct about overdraw, it's easy to forget with mobile devices having full HD resolutions that they can't do nearly as much at those resolutions as desktops can.

Another point is drawing semi-transparent pixels also is a lot harder on mobile devices' gpus then drawing fully opaque or fully transparent ones. Fading out the opacity of the HUD in loot pursuit on mobile causes a very significant frame rate dip, so on mobile I have it immediately set to invisible instead.

On mobile, HTML5's main performance problem is JavaScript speed, in my opinion. The rendering is more limited by the hardware itself (not that there aren't ways to improve performance on that front via software as well).

We have occasional but repeated support requests along the following lines:

1) User with 300mb of images on a single layout wonders why their game doesn't run on a device with 50mb of free memory for applications

2) User with 4 fullscreen size images, all on-screen, wondering why such a "simple" game performs poorly on mobile

In some cases the users blame Construct 2 for being slow or buggy. I always try to explain how mobile devices are much, much weaker than desktops, but it seems almost everyone new to Construct 2 assumes a game running well on their 500W desktop PC with a 300-core GPU and 1 GB of dedicated VRAM will run well on a battery-powered phone with a 4-core GPU with no dedicated VRAM, just shared system memory, of which there might be only 50mb free.

This paper is also interesting for pointing out how mobile GPUs are actually optimised for 3D, and also how native developers go to quite extraordinary lengths to squeeze extra performance out of low-end hardware. We do our best to make Construct 2's engine as fast as possible, but when you do things like use your entire overdraw budget with four sprites, it's difficult for us to do much in the engine to mitigate that. Good game designers just design their games better than that, with awareness of the capabilities of the hardware.

The technique the paper describes is interesting, but impossible to apply in the canvas 2D renderer (so it won't work on Safari for iOS). It's also still pretty complicated to apply automatically in the WebGL renderer since as the paper notes it can't handle disjoint images, as well as the fact we've already highly optimised the WebGL renderer for quads. However it helps you understand how to design an efficient mobile game, even in Construct 2. Remembering transparent pixels are still "drawn" is a good rule of thumb. A common mistake I've seen is people making window borders by making a fullscreen sprite, mostly transparent, but with borders round the edges. Splitting this in to four separate objects for each edge should give a good performance boost - and save lots of memory! In general, splitting up sprites with large areas of transparency is sort of the manual version of what the paper suggests.

I'm sure Javascript is fast enough. The fact our WebGL renderer is usually twice as fast as the canvas 2D renderer, where the rendering calls happen in native code, is a sign how good it can get. However we need more widespread WebGL support to get the benefit of that. In the mean time I think the most common problem is just that Construct 2 makes it really easy to throw in loads of sprites and effects and give a mobile device more than it can handle - something that native developers usually know to avoid.

Does low screen size can boost FPS?

Great read, thanks for the link sqidd!

Does low screen size can boost FPS?

Low screen size by itself does not boost FPS.

It's the same as having a high-end GPU render on a 11-inch monitor at 1440x900. The results will most likely be good because the resolution to graphics power ratio is low.