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?

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

I have a major problem with my big app crashing on iOS. After many tests I'm afraid that I have to blame it on memory management. My thread on the issue contains detailed memory snapshots that clearly show the problem.

https://www.scirra.com/forum/the-big-game-challenge-ejecta-memory-management-on-ios_t107188

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

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.

> 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 ?

At the moment, it is not recommended to make big games with lots of art assets for iOS, its just not possible given our current wrapper toolsets: Ejecta and CocoonJS.

For Android, its only possible thanks to Crosswalk, but again, its missing quite a few monetization features. It's a waiting game unfortunately.

We just have to make do with games that don't use too much big art or lots of big animation frames.

— - are you suggesting that my app is too big to ever run on iOS? I did not give up yet...

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.

Thnx. Will try this next.

MaorKeshet since your game does not require super speed, how about using Phonegap and switching to canvas instead of webgl?

I was sure that phonegap is limited to 30Mb app. My app is going to be way larger.

You shouldn't use my Ejecta github code any more - they have merged it in to the main branch along with other changes. Use the official code from https://github.com/phoboslab/Ejecta. That's the first thing to try.

I just run a test of the app with the official Ejecta template from the above source and it is definitely LESS STABLE than the build that was created with Ashley 's template.

— all my sprites are cropped to the edge, that's quite basic.

Thanks ASHLEY. I'm aware of the need for direct debugging from Xcode . From Friday I will have a mac under my hands, I'm sure that will sure help some.

Will try later or tomorrow the ejecta template. Hopefully it will make a difference. Will update here.

EDIT: Thanks to Ashley and the Ejecta team the issue is now resolved. You may want to skip most thread and go directly to the beautiful memory graph at the bottom of page 3.

Hello Constructors

In the last few months I've been working on a pretty big pre-ordered mobile app for toddlers. The app contains ten different games and three lobby screens (for navigation between games).

This http://www.malanapps.com/klalit/ is the app at its current state. So far there are only two screens implemented for each game, but on the final app I'm supposed to have ten screens for each game.

It took tons of reading and consulting (THNX MUCH jayderyu !!!) to optimize the app so it is now running perfectly on android devices. Optimization focused mostly on merging graphics into combined sprites and down-scaling the entire app from 2048 to 1028. IntelXDK was used to create the apk for android.

Since the Ejecta path to iOS was under extensive development recently, I've waited with testing and building for iOS until memory management issue will be declared as resolved.

And it was... So I moved on... But from the moment I started dealing with iOS, this project has become a nightmare I made more than 30 ipa builds of different sections of the app. When installing the ipa's on my iPad Mini I keep getting frequent crashes, some of them on inconsistent basis. My largest layout is less than 60Mb, so layout size is not the reason for crashing.

My Setup

* C2 r168 (64-bit)

* Ashley 's Ejecta template (https://github.com/AshleyScirra/C2Ejecta

* Xcode 5.1.1 via MacInCloud (no direct iOS Device debugging )

* ipa installed on iPad Mini iOS7 and running on WebGL

Export and build procedure:

1. C2 > Export to Ejecta

2. On Xcode > rename project (with auto rename for elements), rename bundle; ans set orientation (on info.plist)

3. On most versions the app worked on the iOSsimulator perfectly. While launching the simulator Xcode suggested me to approve some automatic adjustments on the architectures and I did so.

4. Archive as AdHock > ipa

When I stated testing the app, not even one game was functional on the iPad. I broke down the app into “clean” separate games, excluding navigation and most audio, and started to fight them one by one… After quite a lot of work few games are functional and some more games are functional but crash at end animation or at feedback animation (boy with res shirt popping in).

Current status of the different games can be viewed here https://docs.google.com/spreadsheets/d/1bo6YoPjmHqvfamxPKTr7352WDY0Kdi4dvM9qoL4T2Ig/edit#gid=0 I will keep this report up-to-date as I go along.

While I believe it would only take precise optimization and debugging to get each of the games working, I have a strong doubt if the entire app is going to run on iOS. And this why:

I wanted to exclude the possibility that the crashes are caused by a bug or a memory leak in the logical mechanism of the games. So I created this https://www.dropbox.com/s/klqdp4abc7006du/AllNoEvents_W_Transition.capx version. All game logic was removed, only layouts, assets and navigation event sheet are there. On top I added a “clear transition” – an empty layout including only a text object saying “clear”. This layout is loaded upon any change of layout, pauses for a short while and after it continues to the next layout. I was suggested that such transition layout will help to get a good view of mem management.

Upon testing, some of the layouts load alright and some of them cause the app to crash. But this is not the issue. The issue is that layouts that do load when accessed at app start, crashes later, after some other layouts have been loaded. To the best of my understanding this is a memory management issue.

As my deadline is coming in few weeks this has became a MAKE IT OR BREAK IT SITUATION. Ashley – I hope you can take a look into this problem. I’m really hurting here; spending endless hours and not really sure if thisproject can be finalized and handed to my client using Construct2 .

If you (or anyone else) would like to review the capx file of the entire app I will be happy to share it by PM.

Thanks,

Maor