Texture lost

[EgonOlsen]

That's overcomplicated, hacky and rather pointless then IMHO. The bitmap will be released anyway, jPCT-AE doesn't hold a reference to it. It holds the raw pixel data in VM memory by default, but you can get rid of that by calling keepPixelData(false) on the Texture. You can also use this http://www.jpct.net/jpct-ae/doc/com/threed/jpct/TextureManager.html#virtualize(com.threed.jpct.Texture) to swap pixel data to the sd card instead of keeping it in memory.

Anyway, which device that's still being used today and is powerful enough to run your app is limited to 32m? I haven't come across a 32m VM for years. Letting the GPU generate the mipmaps via GL_GENERATE_MIPMAP is unreliable especially on the older devices you are targeting. That's why jPCT-AE generates mipmaps on the CPU by default (http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Config.html#internalMipmapCreation).

[gamenewer]

Hello Egon, I make a test on my handset,  when I add 30 numbers 512X512 size texture , the app OOM,
01-21 18:46:14.324: E/dalvikvm(11106): Out of memory: Heap Size=32391KB, Allocated=29256KB, Bitmap Size=512KB, Limit=32768KB
I have set tx.keepPixelData(false)  but it still OOM,    when I create texture by myselft , upload gpn  and then free the bitmap, it's Ok.
Is the keepPixelData  no effect ?

[EgonOlsen]

It has, just not at the stage in that you think it has. In your code, you upload the textures directly after loading them. jPCT-AE doesn't do this by default, because it can't ensure that you are in the render thread at that stage.
You can work around that by calling TextureManager.preWarm(<FrameBuffer>) after loading and assigning each texture. What kind of application is that? Why do you need 30+ 512*512 textures?

[gamenewer]

it seems no effect 
                                      for(int i = ... i<30...               
                                        Texture  tx = new Texture(bitmap);
                                        bitmap.recycle();
               tx.keepPixelData(false);
               TextureManager.getInstance().addTexture(txitem.tname,tx);
               TextureManager.getInstance().preWarm(buffer);
               

[EgonOlsen]

Maybe because of the additional mipmaps, that will be created by default. Those will add another ~10mb to the mix. Just look at the log output to see what happens (it would be great if you could post that as well). However, i still think that you are fighting the wrong fight here. Loading 30+ 512*512 is simply too much for a mobile device especially for one with a 32mb VM: Your textures alone will eat 30mb (512*512*4*30) of that amount and on older Android versions, garbage collection wasn't that great. So with just maybe 1 mb left, you are at a limit where it will start to become unstable.  If you have to such an insane amount of textures, why don't you provide two resolutions at least? One 512*512 for 64+ VMs and one 256*256 for the lower ones.

[gamenewer]

This  is only a test I do, I want to know how many textures can support by jpct , and I want my app can run on old android device. so  if there is a way to extend  jpct  memory useage    from natvie  , it's much helpful  and powerful...

[EgonOlsen]

Your way of creating textures is limited by the same restrictions as jPCT-AE's internal code is. It doesn't use other kinds of memory or has more memory at its disposal. It's the exact same thing, just done by reinventing the wheel to a degree. Texture as a class holds a simple reference to the texture on the gpu, some additional status flags and settings and, if you let it do so, a reference to the original pixels array (compressed or uncompressed). There's no hidden memory leak or something.
If you feel that you have to work around the engine's core, then feel free to do it. I just don't see the point of this whole thing. Making an app run on more limited devices is one thing and if that's the only device that you have to test it on, i fully understand that you want/have to...but honestly: An app that pushes such a device to the limits by adding a large amount of huge textures won't run very well on it anyway. If you are designing for such devices, you'll have to watch your content and performance. Stuffing as many textures into it as possible is a nice academic test case, but it has very limited value in the real world.
jPCT-AE offers you plenty of means to keep memory usage low if needed like dumping the pixels array altogether, compressing it in-memory, swapping it onto the sdcard (compressed or uncompressed), uploading the texture in 4bpp or as ETC1 compressed. You can even swap geometry out to the sd card, if you want that.

[gamenewer]

Thank you very much,  I hope all this not waste your time  thanks again !