The BIG game challenge (Ejecta memory management on iOS)

> Other users have reported a temporary spike (doubling) in memory use during layout changes with Ejecta. That spike can cause crashes if the device doesn't have enough memory to handle it.

>

Sounds like this could be the culprit for Maor's project. Does Ashley know about this?

Ashley ?

That shouldn't crash the game. It's normal in garbage collected languages that the memory can spike up quickly, but as it does so it should collect to release older resources to avoid running out of memory. So I'm not convinced that's the problem.

I would recommend filing an issue with the Ejecta developers since they've now merged in my code (with changes).

Ashley - did you see my earlier comment about getting better results with your ejecta template (over the official one) ? I am a bit confused which would be the correct template to use at the moment...

In the mean time. how about another experiment. Full game, but remove the audio from the project entirely. I wouldn't think there would be much of a problem with audio if it's not being called. but might as well experiment. audio also tends to unpack to larger sizes in memory.

jayderyu - I run a "No Audio" test but the results are identical.

I got my hands on a Macbook and I run many tests on Xcode connected directly to the iOS device. So long for the "create games without any programming skills" concept"....

The memory graph helped me to do some further optimization on the assets and most games are now functional on the iOS device, if accessed upon app launch .

But when navigating from game to game the memory load builds up and once it hits ~235Mb, it crashes with a "memory pressure" message. (I run the tests on a 512Mb RAM iPad mini since my pre-ordered app has to run on such devices).

According to the tests described below, even if the app will be limited to 1Gb RAM devices, it will still crash when loading few more layouts (more games or more screens within a game, I have more than 70 game layouts in my app).

The official Ejecta template was used to create the test app.

https://dl.dropboxusercontent.com/u/8918895/Full%202.1%20shrink.zip - This is a copy of the App Folder I used in Xcode, if you care to reproduce the test or run any other tests.

And this is a diagram of the app structure, so it is easier to follow my tests.

https://dl.dropboxusercontent.com/u/8918895/App%20Structure.JPG

Web version of the app can be found here http://www.malanapps.com/klalit/

(I can't publish the capx since the client owns the app code. I can share it by PM if you wish).

The tendency of all the test graphs upwards (A-B), with no effective clearing is very obvious.

TEST 1:

https://dl.dropboxusercontent.com/u/8918895/T1.jpg

This test shows that when returning to the same layout (outdoors lobby) over and over, memory usage of this layout goes up constantly (sections 1,2,3).

TEST 2 shows that when returning to a layout that was used before, utilizes more memory than it did at first entry (sections 1 & 2)

https://dl.dropboxusercontent.com/u/8918895/T2.jpg

TEST 3 shows that even while navigating back and forth between two layouts the memory usage still goes up (1,2,3)

https://dl.dropboxusercontent.com/u/8918895/T3.jpg

Some Garbage Collection is happening from time to time (yellow stars) BUT it is not really effective as it is very minor and rare

There is a very small headroom left for additional optimization by sizing down the assets (I already have pic quality issues on the iPad). So I wonder what my next step should be

The responsibility for memory management and garbage collection falls between Scirra and Ejecta and we are stuck in the middle.... Is this going to be the big break for C2 on iOS or is it going to be a "re-run" of the frustrating C2-CocoonJS situation??? I am wondering... and hoping for the best...

EDIT: I have posted the same issue at phooslab https://github.com/phoboslab/Ejecta/issues/401

Ashley - Are there any specific log files that may help to resolve this issue

Hmm. Match and Dots seemed to explode the memory. However it looked like when leaving Match not all the assets were released as the the memory was higher than just going about the lobbies. I'm wondering why. It does seem that when leaving match tot he lobby that memory should have cleared down to just the lobby values.

MaorKeshet

I suggest you try CocoonJS, while it lacks memory management, it does not have this memory accumulation issue upon changing layout (other user of Ejecta have reported the same bug). So if its <200MB total with CJS, it should be ok on 512mb devices. Not ideal though.

Hopefully later this year, Phonegap + iOS8 will be great.

Neither Match or Dots) are on the heavy side of the layouts... these are the games that are less likely to crash actually [sigh]

MaorKeshet

I suggest you try CocoonJS, while it lacks memory management, it does not have this memory accumulation issue upon changing layout (other user of Ejecta have reported the same bug). So if its <200MB total with CJS, it should be ok on 512mb devices. Not ideal though.

Hopefully later this year, Phonegap + iOS8 will be great.

Thnx Silverforce. As far as I know CocoonJS is limited to 30Mb app size. My completed app will be ~150Mb. Is there a way to wrap such large app with CocoonJS?

> MaorKeshet

>

> I suggest you try CocoonJS, while it lacks memory management, it does not have this memory accumulation issue upon changing layout (other user of Ejecta have reported the same bug). So if its <200MB total with CJS, it should be ok on 512mb devices. Not ideal though.

>

> Hopefully later this year, Phonegap + iOS8 will be great.

>

Thnx Silverforce. As far as I know CocoonJS is limited to 30Mb app size. My completed app will be ~150Mb. Is there a way to wrap such large app with CocoonJS?

If you request premium access with them, they will up the limit to 200Mb. But just in case, you cannot upload over 50Mb APK to the Google Store currently.

The memory issue is more with IOS. Seems that most Android devices run on 1gb for a longer period of than IOS has been. Seems that CJS may be worth a shot with all the optimizations that have gone on. I would suggest trying with the launcher and copying an export out.

The memory issue is more with IOS. Seems that most Android devices run on 1gb for a longer period of than IOS has been. Seems that CJS may be worth a shot with all the optimizations that have gone on. I would suggest trying with the launcher and copying an export out.

jayderyu My CJS build crashed upon startup so I'm not going to continue this path. Not sure what you meant about "copying the export out" though. From C2 I exported to CJS and used the cloud compiler.

I took this up with Dominic (lead dev of Ejecta) and Dominic managed to identify an Ejecta bug that was causing WebGL to fail to delete textures. The patch has been submitted to the main codebase (https://github.com/phoboslab/Ejecta). Try re-downloading the files and let me know if memory management is working better.

This is great Thanks ASHLEY.

I already downloaded the xcode master zip, will test and report as soon as I'm back to my desk.

I took this up with Dominic (lead dev of Ejecta) and Dominic managed to identify an Ejecta bug that was causing WebGL to fail to delete textures. The patch has been submitted to the main codebase (https://github.com/phoboslab/Ejecta). Try re-downloading the files and let me know if memory management is working better.

Excellent, glad its just a small bug and doesn't require a lot of work to fix!

Looking forward to the results MaorKeshet !

Ashley jayderyu —

I run few quick tests with the new ejecta master template. Memory engagement look very effective, I was surprised to find out that the memory usage drops occasionally even while playing a game (!)

Many thanks to Ejecta team and to Ashley

https://dl.dropboxusercontent.com/u/8918895/Screenshot%202014-06-20%2014.38.26.png