construct 2 mobile performance

jayderyu

Thanks for the great hints! Could you please explain a bit more point 1?

I also think it would be a great article!

Egyptoon clockworkmonster

You make only one sprite that contains all the animations for the all objects and pin it to an invisible sprite that is the object itself that handles the collision.

Example:

You have sprites: enemy1, enemy2, enemy3 -> These are only simple sprite used for collisions (they will be invisible during runtime). The interaction in game will be made with these sprites. Also, include a variable as "animationUID" to know what animation belongs to it.

sprite: enemyAnimation -> Contains the animations for enemy1, enemy2, enemy3

Events:

For each "enemy1"

Pick enemyAnimation by UID = enemy1.animationUID --> "enemyAnimation" set position to "enemy1" (image point 0)

... something like this should reduce draw calls

More info:

tgeorgemihai

Thanks a lot for the hint!! Very useful!!

Is it really necessary to use an empty sprite and "pin" the animations? I mean, You can use the collision poligon in each frame of the animation. This way you avoid using one extra sprite + the "pin" behaviour.

Shouldn´t this improve performance even more? It seems that using many "Pin" behaviours can affect performance...

Don't use per animation frame colliders. Each collider on a different frame will Trigger the collision again.

jayderyu

Thanks for the hint!

4. Some behaviours are just slow.

I will use this one as an example. I wanted a rotating background in my game. So I made a 2048 by 2048 image. The game currently ran at 60fps with the background not rotating. As soon as I added Rotate Behaviour the performance dropped to 8fps. whoaawhh

I switched to rotation in the EventSheet and that jumped performance to 30fps.

I then rotated in the EventSheet every other tick(ie updating the image rotation at 30fps) and the game ran at a buttery smooth 60fps. And there was no visual difference.

Lesson. Don't use Rotate Behaviour. I don't know why. I looked at the code. Doesn't seem like anything would hit performance. But eh.

Stories like this make no sense at all to me, because the Rotate behavior works pretty much identically to an event saying "every tick, rotate speed * dt degrees". I really cannot think of anything at all that could explain any big performance difference. I think it is likely in this case something else caused the performance difference, in particular you mention a 2048x2048 texture which will really push the memory bandwidth/fillrate of the device really hard, which is really not a good idea for mobile devices which tend to have constrained memory bandwidth and fillrate and probably is more likely the explanation for 8 FPS. (This applies exactly equally to native apps: it's a hardware limitation, and you'd get the same performance results doing the same thing in native.) Also note if nothing is changing in the game then C2 skips drawing the screen at all, which could explain 60 FPS when it's not rotating (because it's not actually drawing anything), and you incorrectly attributed the performance drop when rotating to the behavior, when in fact it's simply the rendering vs. not rendering performance difference. Yes, performance is a complicated subject

This comes up a lot in general when people talk about C2's performance: either the cause of performance problems is mis-attributed, or you'd get exactly the same results in native tech because you're running in to hardware limits.

Anyway if you ever get weird performance results like this, please post them to the bugs forum as performance bugs so I can investigate, but I am 95% sure it will work out as being something else, like bottlenecking the GPU memory bandwidth.

A few sums to demonstrate how to work out things like memory bandwidth:

A 2048x2048 texture has 4,194,304 pixels, each taking 4 bytes (ARGB), using 16mb memory. To render that at 60 FPS, the GPU needs to shift 16mb x 60 per second = 960mb/sec bandwidth. So with a single object you've pushed the memory bandwidth to nearly one gigabyte per second, and that's not including anything else. Especially for old mobile devices, this could already be way over the hardware memory bandwidth capabilities of the device. Then people conclude we need to optimise our engine...

jayderyu

I ran into this too. My current project is a straightforward mobile game, but it does have one large object that can be freely rotated on a per-tick basis (a steering wheel).

I read some about rotation being an expensive calc, and tried some benchmarks which confirmed that rotating a dozen or so moderately large sprites is enough to slow things way down on a low end mobile.

This lead to some googling and perusal of stackexchange. TL;DR version: it's really not just us. I found native android devs struggling with the same issues.

Rotation is actually a complex process, and even on a powerful desktop, really good rotation algos are non-realtime. There are faster algo's for realtime usage, but on a wimpy mobile device, it's really asking a lot.

I doubt there is anything particularly wrong with the way rotation is implemented in c2; just consider it's usage carefully on mobile.

So i'm guessing it would be better to animate a sprite, to make it look like its rotating instead?

that would be around 6 animation frames, and i'm guessing with a speed of 10.

Would that be a better solution for mobile? or will it be the same?

make that 16 animation frames for a smooth rotation. Not sure what's best to do?

Anyone?

Ashley i hope there is a benchmark for native mobile implementations vs C2 (crosswalk/ludei) of similar task.. I know the criteria will be skewed or it will be like comparing apples vs orange implementations but at least people have a grasp of the difference between natives and html5. I feel C2 can be used to build "good games / quality games" for mobile as neversommer aim for. C2 or html5 has this curse, that it is not for professional devs or its only good for prototyping. Btw. any news for C3?

neversommer pixelart mobile games works pretty good with C2. try using ludei 's Canvas+ its pretty fast, though there are few limitations going through the cocoonjs path. i love using unity btw their mobile integration is superb, but i like using C2 for 2d/web/webmobile games.

The point of my previous post was "don't use lots of huge images".

If you're wondering what is fastest, you can find out yourself by making measurements.

jayderyu

I think Ashley would also suggest

This: https://www.scirra.com/blog/112/remembe ... our-memory

Using layer rotation.

It can be done via families, but the math is a little harder. It not bad mind you, sin/cos should handle it.

I remember when we had one of the first contests that involved rotation. If we would have had a mobile option back then this probably would have come up.