Ejecta Iphone WebGL / CacoonJS memory limit

Hi.

Game size after export is 46MB.

Memory use in game is 429MB

In C2 estimated Memory use is 509MB

CPU util in debug is 14%

DrawCalls 1.8%

Engine 4.5%

Specs

Nvidia 670GTX

16GB RAM

Windows 7 SP1 64Bit

Quad Core I5 processor

Hi.

Game size after export is 46MB.

Memory use in game is 429MB

In C2 estimated Memory use is 509MB

CPU util in debug is 14%

DrawCalls 1.8%

Engine 4.5%

Specs

Nvidia 670GTX

16GB RAM

Windows 7 SP1 64Bit

Quad Core I5 processor

14% CPU use from an i5 is fine for mobiles. It's exactly what I get for Star Nomad during combat. Runs very well even on pretty weak stuff. So whatever is the problem, its NOT on the logic side of things.

500MB is not going to happen for iOS, no way, no how. Its also extremely on the edge for a lot of Android devices. If they even run your game at all, once they go to the homescreen and it suspends, they cannot resume due to overloaded memory, your game will crash & restart.

At this point I suggest you really reduce the resolution of your images, theres absolutely zero need for them to be high res. What looks awful pixellated on your PC screen looks perfectly acceptable on a small device of 4-7 inches.

Cram everything down into power of 2 sizes, 128 x 128, 256 x 256, 512, 1024, etc. Do not have images that are a bit larger than power of 2 size, its a total waste of memory.

For example, a 557 x 600 image uses 4MB in memory. But a 512 x 512 uses 1MB only. Likewise, if you have any image thats even a tiny bit larger than 1024, its 16MB in memory for that single image.

ps. I made the same mistake as you with my first big game (mine was 460MB in memory on Android hehe), make it first then optimize later... completely stupid way to do games, especially for mobiles. I learnt the hard way.

It doesn't sound like this is anything to do with Construct 2. 500mb memory usage is still pretty extreme for mobile devices. You are probably running in to hardware limitations that you will encounter with any engine or framework, even a hand-written native app. I'm not sure where you got the idea that 500mb ought to work, but I'd recommend aiming for <100mb memory usage to be able to run on a wide array of mobile devices, and ideally <200mb to run just on mid- to higher-range mobile devices.

Apart from that I'd recommend not using CocoonJS, since it doesn't have memory management and will try to hold the entire game in memory at once (which will be higher than C2's estimated memory usage, which assumes a browser that does not do that). Both Ejecta and Crosswalk have working memory management.

Definitely agree with Ashley on this.

Even with Android and its stronger hardware with more ram, a phone for the average user has 20-50 processes running in the background consuming memory. You do not want to force it to run a game >200MB, random crashes during gameplay occurs and even crashing on startup for a lot of devices.

Us devs always test with "clean" devices, very little bloatware. But users in the real world? No, their phone is full of crap.

Definitely go with Crosswalk and re-fix your game to make it compatible or faster with XDK/Crosswalk, your game is simply too big for CocoonJS, even once you reduce your art resolution, it will probably still be ~300MB with everything loaded.

In regards to the slow performance with WebGL effects, a lot of them are performance destroyer for mobiles. Just do not use it, a few effects you can use as they don't impact performance much. I made a post recently with some testing data on different effects.

Ldk

I spent about 3/4 months with Maor(on the site) to go from a fine desktop game to mobile. It was a lot of back and forth. And the first element that needed to be worked on was the fact that the memory usage was pretty much killer on the systems.

I suggest lowering your graphical quality by half as just a start. There are many other performance enhancers after that. Use mono audio can cut audio in half. So unless your game needs stero audio, just mono it.

I understand your points. I respect that they are valid. But it would still not explain how a Mac with 4gb ram cant run it.

Also i did go through an extensive sprite exercise and not a single one is is above 512px

The only optimization i can do is change my sprites from spites to tileable backgrounds. But only for detailing ones like grass.

I have another suspicion that i will investigate regarding animations with a high frame count.

I understand your points. I respect that they are valid. But it would still not explain how a Mac with 4gb ram cant run it.

Also i did go through an extensive sprite exercise and not a single one is is above 512px

The only optimization i can do is change my sprites from spites to tileable backgrounds. But only for detailing ones like grass.

I have another suspicion that i will investigate regarding animations with a high frame count.

Mac with what graphics? If its intel HD4000 etc, it will struggle on some WebGL shaders and as I've said you need to test anytime you add a feature to see if it adversely affect performance.

You've made the same mistake I did first time around, pile everything on, works great on PC, runs awesome, pile more on... finished game! WOW, crap.. it doesn't run on mobiles or weak graphics PC/MAC. Ouch! Removed all the webgl shaders, fixed all the sprites to optimize memory use and suddenly its 60 fps smooth on everything.

I know. Sad part is im no longer using any webgl effects on layers.

Time will tell.

I know. Sad part is im no longer using any webgl effects on layers.

Time will tell.

Stop stalling and give us the .capx already

Seriously. You had me at performance issue. It may sound weird, but I love figuring out reasons for performance issues.

Ok so i found where the performance suffered that caused all the lag.

Basicly it comes down to this.

Basically the sprites fill up too much of the screen with wasted pixels that are still being rendered.

IOS especially is well optimized for opaque pixels, but when it comes to masked of translucent pixels it doesn't do too well.

The blue area indicates the benefit of using polygons for sprites.

It will save a crap load of overdraw