How to reduce the number of crashes (mobile)

0 favourites
From the Asset Store
“What number is it?” is a game where you hear the sound and have to guess which number the sound comes from.
  • Hi,

    My mobile game runs nicely on Android (not many crashes), but on iOS, especially when exported with Phonegap Build, I have too many crashes! Even on an iPad Mini 2. Is there any precise tips to try to reduce the number of crashes? Should I delete as many images as possible, or should I rather try to deactivate as many event groups as possible, or something else?

    I found this thread on the topic, with a reply by Ashley :

    Crashes (as in the app exits) are usually caused by buggy graphics drivers, or running out of memory. In rare cases it may be a browser bug, but the first two causes are far more likely. There's not much you can do about buggy drivers; most mobile platforms don't allow updates outside of updating the entire OS, which is subject to the carrier/manufacturer approving the update.

    If there's a bug in the C2 engine then if the JS code goes wrong it probably won't crash the app. It will probably freeze instead, since the browser engine catches the JS error, halts the script, and then continues running the page. That's useful in web pages but since the C2 engine is all JS then the game logic halts freezing the game then the last frame remains on-screen. If that happens then ideally you'd be able to reproduce it and report it as a bug to us so we can fix it.

    My problem is probably memory, as my game runs mostly on only one layout.

    Thanks!

  • The dirty little secret with Apple devices is that their specs are often very underwhelming vs their cost; case in point, no iPad or iPhone (except for the iPad Air 2) has more than 1GB of memory, the same amount I have in my $20 android phone. Most decent androids have 2GB now, and flagships usually have 3GB.

    iOS doesn't have as bloated a footprint as android, which is part of why it runs so well, but that still leaves you with precious little memory. In combo with being a 1 layout game, you're playing with fire. What is your estimated footprint for your project in C2? If it's over 250MB, I'd be worried.

    might be able to give some guidance too; I wonder how much memory Star Nomad uses?

  • I don't have exp with PhoneGap so I can't comment to this specific crash.

    I used CJS WebView+ which ran on WKWebView (requires iOS 8+) on iOS with enhanced memory usage and performance. I don't know if PhoneGap uses that or just the default system WebView, which actually suck a lot for C2 games that are complex.

  • Given memory use is probably the most likely cause, what is the memory use of the game that is crashing as measured by C2? (It estimates it in the editor status bar, or you can view it from the debugger.)

  • TiAm I'm unaware of what a footprint is (sorry). But I guess it's what Ashley is asking for in his reply?

    Ashley The C2 editor tells me "Memory use : 298.2 mb"

    When playing the game in Debug mode, memory usage (images) goes sometimes higher than 100Mb. Sometimes even higher than 120Mb if the player wanders on the map...

    From what I experienced, on an iPad mini 2, the game seems to crash as soon as the memory use is above 100Mb, which is quite problematic.

    What I noticed is that even if I delete the objects, they are not erased from memory. Actually the game only refreshes memory when changing layout.

    Is there any way to refresh memory other than changing layout?

    Otherwise, separating the map on a different layout seem to be mandatory.

    Any other tip?

    Thanks a lot!

  • An iPad Mini 2 apparently has 1 GB RAM, so it should be fine with that much... but still, 300mb estimated memory for a mobile device is quite a lot, perhaps the tips in Remember not to waste your memory will help.

  • Oh, I actually forgot something important! This test was done on my PC, using the uncompressed images, but each time I export Healer Quest, I replace all the images with their compressed version in the image folder. I think the image folder's size drops from 50+ Mb to 16 Mb! So the actual memory usage is probably less than what is displayed in the editor and debug mode. So it should be still better than what I told in my previous post.

    Still, the game crashes a lot !

    Thanks Ashley, I remember reading this post a few month ago, but I'll read it again.

    EDIT : Have read it and it contains the info I was looking for :

    "In Construct 2, images are loaded layout-by-layout. This means when a layout starts, every object on the layout is loaded in to memory immediately. This is to avoid mid-game pauses as textures are loaded on the fly. When the layout ends, it will free all the images in memory not used by the next layout, and load any new images the next layout uses."

    So I'll definitely try to put my map on a separate layout if possible.

  • Doesn't make any difference if you compress the images (this only reduces the app size on download & installed), art gets loaded into vram as raw textures.

    C2 underestimates memory use in the editor because that assumes a few key factors which may not apply to mobiles.

    The first thing is you need to figure out: is PhoneGap using the system WebView on iOS? If so, forget-about making complex games with lots of art assets and using PhoneGap. Just forget about it. iOS hates games that use above 100MB of memory and definitely anything 200MB+ is asking for repeated crashes. Do not forget that our testing devices are quite clean, user devices are bloated with many many apps running in the background.

    You need to use iOS8+ improved WKWebView if you have a complex game.

  • TiAm I'm unaware of what a footprint is (sorry). But I guess it's what Ashley is asking for in his reply?

    I'd like to know what footprint is too.

  • See 'Common misconceptions' in Performance tips:

    [quote:1qvyu1dr]Image formats (e.g. JPEG, PNG-8, PNG-32) affect the download size but have no effect on runtime performance or memory use (they are all decompressed to 32-bit bitmap on startup).

    In other words, the image file size/format has no effect on memory use. It's effectively decompressed and loaded in to memory as a 32-bit ARGB bitmap.

  • Thanks for the info about memory use. Very useful!

    : I don't really know about what Phonegap Build is using. Do you mean XDK should be better? I will keep your tips in mind for my next game but here I need to find efficient ways to reduce memory usage on a finished game.

    I have another new element to share : I'm using a "container" layout in my game that contains most graphical elemens of the game in it, and is never played.

    The idea is that, as I have only one layout for every fight of the game, put all the enemies' images on the "game" layout will make it quite heavy. So I have them on an unused layout and only create the images I need at the beginning of each level. Is there any drawback to this method that I'm unaware of?

    I just moved one of my images from my game layout to the container layout, and the "memory use" moved up from 298 Mb to 300 Mb, so I guess this memory use is for the "container" layout? But as this layout is never played, the memory usage displayed in the editor is probably not relevant, isn't it?

    If I'm guessing right, it's the number inside the debugger which gives a clear indication of memory use (images only), which in the case of Healer Quest can go up to 120 Mb.

    Another question : I have many big, invisible, flat-colored squares that I use as collision boxes in the game. Their weight is about 200 bytes each in my image folder. But do they use big part of the memory too?

    Is partial transparency (i.e. 20% opacity) taking more memory than 0% or 100% transparency images?

    At least I now see what I can do to reduce memory usage, so thanks a lot for all the very useful advices. And splitting my big layout into 2 parts (game+map) already seems to limit memory usage in game to around 90-100 Mb maximum.

  • The memory use indicator is the layout which creates most memory usage.

    Therefor, it is not a good representative of the memory use.

    I use objects layouts in every one of my projects too.

    would you split up your biggest "container" layout, into two or three, the memory usage will reduce too. (but it is just an indication, not actual memory usage)

    As far as I know this is good practice and has no drawbacks ..

    Good advantage is that you can prep all your objects on them too ...

  • i think that "container layout" is not good idea ...

  • i think that "container layout" is not good idea ...

    Why not? Could you please develop your thoughts?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • matrixreal No a container layout is the best practice you can use because to create a object it has to be somewhere in your project if you have a container layout the images are only loaded when used or else for some objects i.e bullets you would have to put them somewhere in your project that is a active layout using memory that doesnt need to be used

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)