on behalf of Chris, this particularly sounds like a memory allocation problem within the Android toolchain. We are aware of a problem for asset collections bigger than approx. 20MB and are currently working on fixing that. How large are your asset files (images and sounds) in total (uncompressed)?
If you’re using some jpeg files you can temporarily save them with lower quality to bypass this problem until we have a proper fix for that. I’ll keep you updated, thanks for the hint!
the images and sounds have at the moment a size of aprox. 16 MB. The finished version will have about 50 MB and i am working also on a hd2-version for tablets that will surely have a size of about 80 – 100 MB.
good news, we just pushed an update for our Build Server, resulting in shorter build times, smaller app binaries, and probably of interest for you, building Android projects with a lot of assets again. 😉
now that the project can be build with all its assets, i am facing a new problem, always on android. When the player reaches another level i change the background graphics of the scene. I do this by using the Image element and changing its source. This works for aboout 10 levels, then the screen gets black and the app hangs. Looks like a memory lag. Is qt internally instantiating always another image object, when the source gets changed? I set the chache property of the Image element to false, but when i reload a image that i used before, it loads very well, just like it would be cached.
we are caching the images in the cocos renderer, which might be the source of your problem. Could you reproduce this error, e.g. by changing the source of the Image x times, leading to an app crash at the same amount of x? Could you also upload the image files that causes the problem together with the test of changing the image source, so we can have a detailed look at it? How big are the images, actually?
In this example i am using 30 images with a size of 500×500 px and 250KB. They are named “Image1.jpg”, “Image2.jpg” ….and so on, till “Image30.jpg”. I am using a Samsung Galaxy Ace, that is not able to reach the last image. It would be great, if one could choose, if the image should be cached or not (maybe by setting Image::cache to false).
I had a close look at this problem and tested it with a Samsung Galaxy Ace and a couple of other devices. It turns out, that you should not use jpg files at all, because they have a longer loading time and take up much more graphics memory than pngs. Also, please keep in mind to create 3 different image versions for sd, hd and hd2 devices and using the MultiResolutionImage component. The Ace is in the sd (=single definition) category, which works best with images made for 480×320 or 320×480, depending on your game being in landscape or portrait mode. We also added documentation about this topic here: http://v-play.net/doc/vplay-different-screen-sizes.html
The best performance can be achieved by packing all images into a spritesheet, with the excellent tool Texture Packer. By using the spritesheet, your image only needs to be loaded once into memory and can then be used efficiently.
In addition, we also added a new function to the NativeUtils component called clearCocosTextureCache(). This allows you to manually remove cached textures that are currently not in use. You can use it, if you know you will not load the images anytime soon, and it will be available with the next V-Play update v1.3.