Help with mobile graphics please

0 favourites
  • 12 posts
From the Asset Store
Game with complete Source-Code (Construct 3 / .c3p) + HTML5 Exported.
  • Hi everybody

    For the past 4 moths I've been making a game targeted to android/iOS

    The engine worked and everything was fine, but as I started adding more images (specially backgrounds) the game became slower and slower and now it doen't event load, it just send me back to the mobile's main screen.

    The game was designed 900x600, compiled with cocoonjs and tested in 2 android 2.3 devices, 1 iPad and 1 iPhone

    Since Construct packs the images in sheets by power of 2 (128x128, 512x512 and so) I have also split my backgrounds in order to save space and memory

    I used to have 19 900x600 images for the backgrounds, which I think are loaded as 1024x1024 by the device... and now I got 29 512x512.   and got a ridiculous improvement ( loader screen, main screen, one extra and "pum" back to the device "desktop")

    Unfortunately I can't share a capx because it's a comercial project and the other part might kill me if I do... also I don't have a better device to test..

    the game only runs if I delete all the backgrounds

    is there any other way to optimize the graphics for mobile devices? or getting into mobiles through wrappers limit us to use low quality graphics??

    any reply would be helpful.. thanks to everybody

  • The only way will be to redesign the concept. 29 backgrounds is too much.

    I dont how big your capx file is... but i found out through testing that the xcode/ipad2 has memory issues with more then 20 MB sizes.

    And the limit is a device limit . Try to use less background a mobile device has texture memory limits

    It will also take forever if you load too many files. Think about it this are only images. Maybe you want also sound effect, background sound etc.

    All this stuff will be preloaded and also uncompressed loaded into the memory.

  • Which iPhone and ipad are you using?

    I seem to recall reading that ludei is going to implement c2's layout by layout loading, that would solve your problems. Hopefully they'll have that implemented soon - you could ask them via their website if they have any idea when it might be implemented.

  • thanks for the reply...

    about the 29 backgrounds.. actually I've been reported that is working better than before... I think 29 512x512 takes less resources than 19 1024x1024.. I think theyt are too much too, but I'm in charge of the code only..

    The iPhone/Pad are old I think, maybe "1" or "2"

  • Hi everybody

    Since Construct packs the images in sheets by power of 2 (128x128, 512x512 and so) I have also split my backgrounds in order to save space and memory

    My understanding is that is only the case for tiled backgrounds?

    Breaking down backgrounds into smaller, repeatable elements is the way to go. Generally 20 smaller sprites will run faster than one big one.

  • hi thehen what I meant is that breaking down the backgrounds to make them fit in 512x512 sheets works better than having a 900x600 which I think is being loaded as the nearest 2* texture (in this case 1024x1024)... tiled backgrounds just repeat the same image, but in my case I'm arranging the sprites like a puzzle to get the full back..

    and apparently that improved a little the situation... I've been recently told that it is running "playable" on the iPad

  • Interesting, I thought that power of two only applied to tileable backgrounds. Perhaps it's different with CocoonJS.

  • An iPhone 1 or 2? The hardware in those are very weak and have very little memory, I'm surprised it runs at all. Ipad 1 is underpowered as well, though not as much.

    Power of two is still important for how graphics cards work (though many or possibly all modern gpus can have rectangular power of two textures, such as 64x128) but c2 does it for you on export. 4 512x512 textures will take up the same space as 1 1024x1024 texture and should be basically the same speed to draw, unless the early iPhones don't support textures of that size. If they don't, then it could either slam the frame rate or break the texture up automatically, I don't know.

  • Hello,

    Definitively, devices like iPhone 3GS and iPad1 have limited memory cappabilities. This does not mean a game won't work (we have several fairly complex games running on them) but you have to manage your resources carefully. For instance, do not load all the backgrounds at a time, but when you need them. Having power-of-two friendly resources definitively helps to minimize the memory waste but remember that some graphics hardware/drivers do not allow textures bigger than a certain size (2048 is usually the limit).

    rule of thumb, control as much as you can what resources you use each time.

    Regards,

    Iker.

  • ludei - by saying "do not load all the backgrounds at a time," what does that mean for cocoonjs's memory management? Does it load textures as they are used and unload them when they are not? Does that mean c2's layout by layout loading has been implemented, or is that your own memory management system? I'm very interested to know the specifics of how it works.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Arima,

    At this moment, CocoonJS is HTML5 standard compliant on this matter. This means that an image is loaded to memory when it is loaded and deallocated when there are no more references to it. So, do not load images until you need them and be sure not tu reference them again if you are not using them anymore. I guess that with an authoring tool like Construct, it is difficult to have such a control and that is why Scirra has added some kind of "extensions" to handle resources more accurately. Ludei will try to provide this kind of APIs soon.

    Regards,

    Iker

  • Awesome, thanks Ludei!

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