I need help to resolve 2 issues .
1.In my program loop stops to work because of problem as I believe with performance/and or sound in Safari for ipad2(ios6).
2. Can not open in ipad2 with cocoonjs(ipad3 is opened and working properly but sometimes get out from running)
You can find sample of my project with subset of code here scirra.com/forum/topic60264.html
I will pay $100 for fixing (if it is possible ) those 2 problems.
PS . I can not have less pictures and they compressed already to PNG8 .
Program works without problem on PC(google chrome), cocoonjs on ipad3 (can not open in ipad2(black screen after unzip))
The most likely problem is the device is running out of memory. We're working with the Scirra guys to find a way to load/unload images as they are needed, but for the moment CocoonJS loads all images on startup, and it needs enough memory to do that.
Also, image compression doesn't help at all for this, as images are decompressed when loading them into the graphics card. So, for the purpose of in-game memory usage, it's like if you were using BMP images (or uncompressed TIFF images for the ones with alpha channel).
There's also the issue of NPOT textures, which makes textures of 513x513 pixels use memory as a 1024x1024 texture, for example. Always try to reduce images to power-of-two sizes (or tightly pack several small images into a bigger POT one) if you are able to do so. Otherwise you'll be wasting lots of GPU memory.
Until we implement a way to load/unload images on request, our suggestion is to reduce the images size until they fit in memory.
Thanks, for fast answer . Do you have some estimate for total size,size of pictures, size of sound that will work with cocoonjs?
Develop games in your browser. Powerful, performant & highly capable.
ludei - Construct 2 users don't need to resize their images to power-of-two sizes, unless they are for tiled backgrounds. Construct 2 automatically packs Sprite images in to power-of-two size spritesheets which helps minimise the memory use. More info in this blog post. I've emailed you about how to support the memory management we've already coded, it should be relatively straightforward and a top priority for you guys.
Yep, the "relatively" part is the tricky one. Because of how it's implemented internally it's not as easy as it would seem at first sight. We'll definitely have to think of something, though. We'll keep you posted.