The BIG game challenge (Ejecta memory management on iOS)

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

Similiar issue here.

Ive found that couple of my games crashed on iphone4 due to game having large spritesheets.

Once Ive cut them a little by using construct2 inbuilt image editor "crop transparent edges" games started to work and they didnt hang on. I was using cocoonjs.

Right now im ultra paranoid when developing and constantly checking out if game runs at all on iphone4, when it doesnt im cutting out graphics a bit.

Im not sure how to solve this problem. Can we unload resources and load them? Could I load and unload graphics that is large and is used only couple of times in project?

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.

Secondly you really cannot diagnose this properly without having a Mac connected to your iOS device (unless you can reproduce the issue in an emulator). If it crashes while connected and running from Xcode, then it should provide you information about the crash in Xcode's logs. Without this information anyone looking at this problem is reduced to guesswork. It would also tell you very clearly if there is a memory problem or if the crash is caused by something else (and then hopefully Xcode's log would help us identify how to fix the problem). It could also be caused by third party plugins, so removing all of them and testing again would help isolate that.

Other than that I don't have much experience with Xcode's codebase - it was written by another developer - so you might get more insight from logging a bug with the official Ejecta project. Even then they will probably immediately ask you for the information from Xcode's logs as well.

If you can extend your deadline, iOS 8 should fix all of this: you can just use PhoneGap, and it should run the same as the Safari browser. Unfortunately in iOS 7 PhoneGap is still very slow.

I would suggest CocoonJS, but they have never supported memory management, so if that's the problem it will likely be even worse there.

— 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.

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

Personally I think Maor has done an amazing job. He has managed to get the game running under Android well enough to publish. Especially since the game wasn't mobile optimized when the mobile part of the journey started. So I'm rooting that we can get this to work. This project would certainly be a testament to the human effort and larger games. Even if it's not something like Crysis

I think bjadams has an idea. Might as well try it out. out of all the optimizing done you never know. A lot was changes on being more efficient on rendering on many levels.

Good luck Maor. I think when you have a Mac on Friday that can help identify the problem.

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.

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. This behavior is not present in Crosswalk/XDK for Android. On CJS, its worse since that "spike" high usage is always from the start.

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.

jayderyu In my own testing, audio music has no impact since its loaded on call and for that track that you play only. Sound is loaded into memory the first time its played (with Crosswalk) so there's a slight delay on the first sound fx, but subsequent ones are fine. Generally sound files (short 1-2s) dont consume much memory.

MaorKeshet My biggest layout in c2 for one of my game was reported as 83MB memory used. It used 460MB of memory when running on devices compiled with CocoonJS. It kills most Apple devices, instant crash on load.

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.

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.

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.

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

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

Have you checked how much memory it uses on iOS yet?

Because older Apple devices have 512mb of ram and if your App uses more than ~200mb, its likely to crash.

Fyi game that currently crashes on me with cocoon js takes 150mb on preloader scren, 190mb on cover screen and it crashes at gameplay screen - probably because it uses more than 200mb then.

Browser webgl memory usage is at 32.7mb.

Im just going to wait for year for ios8 and 80%+ users using it to build with phonegap. There is no point in releasing larger game right now since cocoon sucks hard.

You can release larger games, it will mean you have to set the minimum specs for devices with 1GB of memory. That rules out iPhone 4S and older iPads, unfortunately.

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?