Optimizing a game for mobile platforms. Your tips?

Get help using Construct 2

Post » Sun Feb 16, 2014 8:10 pm

I don't think that i entirely understand what you mean by this.
Let's suppose that we have a game that is running at a resolution of 320x240. This means that the game's area is represented by 76'900 pixels, which have to be redrawn each tick. Now, if we increase the resolution up to 640x480, then there are 307'200 pixels that need to be updated now, a difference of 3x the original amount! This will obviously be a performance hit for any game...
B
10
S
1
Posts: 163
Reputation: 1,436

Post » Sun Feb 16, 2014 10:08 pm

The problem on old mobile is that:
1/ their RAM is super low: it means you'll hit a limit of resource you can use for the game. Even if you use highly optimized small image, since you have no control over loading/unloading them to/from RAM, you can't really use too much of them.
2/ rendering is slow: it's in general the bottleneck of the game. And the headache is that :
- You can't use too big images like said before (so avoid having something like 5 different big background for each of your levels)
- The work around is to compose a background out of small modular pieces like trees and grass and flowers you can spread accross your level, but then you hit another problem: pixel redraw. Basically if you have a 800 x 600 screen to fill, you have to paint about 480,000 pixels. But if you start layering objects on top of each other, this number will increase since some pixels will have to be redrawn. And the more pixel you have to draw, the more rendering computation. And the more object, the more draw calls. Also, the more object C2 has to handle, the more computation (though at a lesser extend than for rendering)
3/ When using phonegap, or any wrapper based on the built-in webview, you'll have problems, like touch input failure, on some android, with an error on logcat saying "Miss a drag as we are waiting for WebCore's response for touch down". But I guess with CocoonJS it should be ok since I believe it's Android's default WebView bug.

The problem on new mobile is that:
1/ They often stupidely blow up their resolution to gain in image crispiness... (you only really notice a difference when you have two mobile side by side...), Anyway, more resolution means more pixel to draw, and often their performance don't really match the rendering demand.
2/ dunno.. I needed a 2/


In the end, I'm not convinced that using HTML5 for mobile games is such a good choice. It's not C2's fault, it's more that javascript is not tailored for games... at all.
See this interesting article http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

On top of that C2 converts all your events into a big tree that is parsed every tick, so it adds a layer of potential slowness.
Concurrent softwares like Game Maker took the option to instead, export directly a native apk with their interpreter written in Java. Same for iOS. I think scirra did the right thing to stick with HTML5 and try to optimize it as much as they can, because working on android/iOS exporter would require way more man power than what they can currently afford.
But I honestly think that you shouldn't try to make too ambitious games for mobile using C2.

Turn by turn, puzzle games, games where speed and responsiveness isn't a requirement should be good enough. But high paced platformers, fighting games or things of this nature should be avoided. I even had problems with a tetris game (I had to use the canvas plugin to paint the bricks placed and just paint this canvas every tick along with the falling piece... and it's still a bit slow on some devices... hmpf v_v)

Anyway, that's all I got on the top of my head.Yann2014-02-16 22:12:01
B
66
S
22
G
14
Posts: 1,484
Reputation: 16,511

Post » Mon Feb 17, 2014 9:12 am

@Yann That's a pretty good post you made there, quite a bit of information! Either way, i think that this can be worked around:
[QUOTE=Yann]On top of that C2 converts all your events into a big tree that is parsed every tick, so it adds a layer of potential slowness.[/QUOTE]
Just have a variable called "tick" (or just use the system expression) and divide events into groups, for example, player input should be processed every 2 ticks, but enemy A.I. should be processed between the player input ticks - it'd look like this: INPUT - AI - INPUT - AI ...
Then just have a condition for the groups that checks if the current tick number is an odd or even one (tick mod 2 = 0/other, assuming there is a "mod" command or similar in C2).
B
10
S
1
Posts: 163
Reputation: 1,436

Post » Mon Feb 17, 2014 10:23 am

Mobile performance is improving so fast, I find that it doesn't really matter as long as you avoid these two things (currently):

1. WebGL effects, it will cripple mobile performance.
2. Physics, again, performs horribly since it has issues with CocoonJS and Crosswalk acceleration, its not even close to native, since I've also experienced using AndEngine with Box2D and it was blazing fast.

I just avoid these two, my game has huge PNG backgrounds, lots of massive 256 and even 512 (Bosses) sprites, heaps of objects on screen as well as particles, and even on an old dual-core 1ghz HTC Incredible S, its smooth. Anything Tegra 3 or Samsung S3 beyond pretty much runs at 60 fps.

What to look out for if you use CocoonJS, is to not have too much art assets, because it loads everything into vram (not layout by layout as needed).
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,614

Post » Mon Feb 17, 2014 7:31 pm

@Stiivais
Well, yeah of course you can do that kind of optimization, but I was merely describing why C2 was adding an extra processing layer that isn't trivial. Some times ago I made a Conway's game of life on C2 and another directly in javascript and the difference was kind of stricking even if I tried my best to make the C2 version as fast as I could.

@Silverforce
If you have time to read the link I posted in my previous post, you would see that we are hitting some kind of limit as far as mobile performance goes in general and specifically with javascript.
Even if you manage to make some complex games go fast enough (and I honestly doubt you can manage that on Android < 4.x), you can't really compete with Native games. And I'm not sure you will ever be able to compete with them using javascript.
If you find some nice turn by turn mecanics like desktop dungeon C2 should be more than enough to make a pretty and enjoyable game.
But if you want some fast paced game with reactive flawless controls... Well... I'd like to see that =)
B
66
S
22
G
14
Posts: 1,484
Reputation: 16,511

Post » Tue Feb 18, 2014 12:30 am

Its going to depend on your cutoff point for acceptable hardware... for me, anything less than dual core 1ghz is not even a consideration.

My own game is very fast paced on later levels, so many objects, explosions and particles on the screen. Runs flawless on Tegra 3, which is already quite old now. I was shocked an old HTC dual core 1ghz ran it perfectly smooth as well, using Crosswalk.

The only limit is the flawed acceleration of physics and webgl with the wrappers we have. It's not even 10% of the performance what native Box2D is via Android SDK/Eclipse and 2d engines such as AndEngine. As soon as physics is used, even on a Samsung S4, the performance is horrible. There IS a problem there.
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,614

Post » Tue Feb 18, 2014 2:36 am

Okay , kinda big post coming , this is only my own experience and may not be how C2 really works , but C2 being a very optimised engine , I would guess this is how it works

First of all , for the 10/90 rule , it's not really always how it works , with algorithms like raytracing or physics may take more resources than rendering but that is 90% of the time not the case on mobile ...

Let's go even further , I'll try and explain why such optimisation tips are given , I think C2 culls the objects out of the screen and goes thru all of them , just to clarify it , that's why you need to keep 'em low , but this is probably not a bottleneck so ye , also , big sprites take lots of space that old phones don't have , take note that a pixel is 7 bytes ( or more/less in C2's case , probably more ) for color (3) + position (4) as a float so that's around 1.75 mbs for a 512x512 image , loaded in the RAM before drawing , and for multiple images loaded before drawing , that can be a mem-killer , that's what I gathered around playing with OpenGL , hope it helps

tl;dr , keep the num of sprites loaded into memory and objects on screen low Whiteclaws2014-02-18 02:37:48
B
42
S
17
G
17
Posts: 2,247
Reputation: 17,461

Previous

Return to How do I....?

Who is online

Users browsing this forum: TRMG and 31 guests