Performance problem with mobile/CocoonJS

Hi all

I'm having a shot at developing my first mobile game.

However I'm running into some rather large performance issues. I rebuilt a simple test and it seems that by exporting to CocoonJS I can get about 80 sprites on screen before it hits <10fps on a Google Nexus. My game is a variation of Tetris, so a 9x9 grid would be around 81 sprites on screen, not counting all the UI sprites and the preview blocks. Once the screen fills up about halfway it's pretty common to dip into the 15-20fps range.

Sample Capx

I've seen a lot of threads about performance on mobiles, but should it be this bad or am I just doing something wrong? It's not like I'm doing anything fancy with the sprites. I've run the 'Sprites' demo in CocoonJS that can get about 400 sprites on screen before it dips to 30fps, so I'm not sure how it's doing that.

boolean I took a look at your sample capx, and I think you could increase your games performance by using System every --> ? seconds instead of Every tick.

When ever you have a lot of sprites moving at angles it will kill your games performance. My first Android game Falling Fruit Frenzy has a lot of sprites moving at angles, and I had to sacrifice quite a bit of my original game idea to get it to run at a playable speed with CocoonJS.

I don't know if developing for Android is worth all of the headaches, heartaches, and disappointments anymore. I invested a lot of money in Android devises for testing on just because I believed in companies like AppMobi, and CocoonJS. But it seems like they have abandoned us lately. AppMobi's direct canvas I could never get to work with Android, and now that Intel bought there tools, and developers they never come here anymore. And CocoonJS it seems like there new flagship is 3D so I don't expect them to be fixing anything we have all been waiting for, for over a year now like in app purchases, audio, or a ad revenue service that's not a scam like MoPub is.

My disappointments with Android have even left me afraid to invest in other mobile platforms devises. I might just get out of the mobile market all together until I see someone from here actually turn a profit.

It runs fine on my Samsung Galaxy S3 in Chrome for Android. But note you're doing the classic instance-vs.-instance collision check with lots of instances. You've effectively got a collision test checking every sprite to every other sprite. So with 80 sprites you're running 80x79 = 6320 collision checks per tick (if it could still hit 60 FPS, that would be ~380k collision checks per second). I guess that's enough to drag down weaker mobile CPUs. The most obvious thing to do would be just to set a flag when the sprites "land", and put a condition checking the sprite has not landed, e.g.:

+ Sprite: 'landed' flag is false

+ Sprite: does not overlap (...)

-> Do stuff

Since conditions are also run top-to-bottom, you only run collision checks on the sprites with 'landed' set to false, which is typically only a handful even after they've stacked up.

You'll need to consistently make optimisations like this to ensure good performance on mobile. This is not because Construct 2 is just slow, it's what native developers work hard at as well.

Wink: I'll give that a shot and see how it goes, cheers mate.

Ashley: That's a good point. I was under the impression that the biggest bottleneck was drawing graphics to the screen, so I may have underestimated the importance of the logic running underneath. I'll do a proper test tomorrow when I have a bit more free time, but I noticed that in a lot of places I'm doing:

+ Sprite: 'landed' flag is false AND not overlapping SpriteB

-> Do stuff

As opposed to:

+ Sprite: 'landed' flag is false

+ Sprite: does not overlap (...)

-> Do stuff

By bumping that overlap check down one level it wont get hit every tick.

Hopefully that gives it a bit of a speed boost <img src="smileys/smiley1.gif" border="0" align="middle" />