So I tried to get some crashes on different settings of Config.blittingMode with the LiveWallpaperRenderer.
Setting: Untouched.
Result: Crashes without being able to see the world.
Crashlog:
http://pastebin.com/NsDhHhsK Notice: On line #2766 just before the crash, capacity > limit? Is that supposed to happen?
Setting: Config.blittingMode=1
Result: Crashes without being able to see the world.
Crashlog:
http://pastebin.com/7KaLwuPrSetting: Config.blittingMode=2
Result: Crashes without being able to see the world.
Crashlog:
http://pastebin.com/qV08hctZSetting: Config.blittingMode=3
Result: Crashes without being able to see the world.
Crashlog:
http://pastebin.com/7u1vCkWrSetting: Config.blittingMode=4
Result: Crashes without being able to see the world.
Crashlog:
http://pastebin.com/VUc3BA57Settings: Config.blittingMode=5
Result: Crashes most of the time without being able to see the world.
When it does load, everything seems fine.
But watching in the direction of the sun/lensflare seems a bit laggy for some reason.
Crashlog:
http://pastebin.com/a14ceSVbSettings: Config.blittingMode=6
Result: Crashes without being able to see the world.
Crashlog:
http://pastebin.com/NTPd3Fr1Settings: Config.blittingMode=7
Result: Crashes most of the time without being able to see the world.
When it does load, everything seems fine.
But watching in the direction of the sun/lensflare seems extremely laggy.
When the sun is hidden behind the Earth (so the lens flare is hidden), the lag is gone.
When not watching in the direction of the sun/lens flare, the lag is gone as well.
So basically, the extreme lag is only there when the lens flare is being blitted.
Crashlog:
http://pastebin.com/QfZtQpdSSettings: Config.blittingMode=8
Result: No crash, no lag.
Crashlog: None (couldn't get the live wallpaper to crash, I tried loads of different combinations)
Log:
http://pastebin.com/zd1LxDTM (works normally here)
I would say my problem is solved when using Config.blittingMode=8
I wonder what your opinion is on this, because you seem sceptical...
Thanks a lot so far!
Three another small things, it seems that a lot of textures are being loaded. (I guess most are 2x2 textures...)
It's probably because my loading screen blits letters onto the framebuffer using 'new Texture(2,2, new RGBColor(col,col,col))' (with col ranging from 0 to 254)
Wouldn't it be possible to just be able to bllt colors instead?
I suppose that would be more lightweight than having to load textures and unload them in the end.
Or is this nothing to worry about?
I also wonder if Object3D.shareCompiledData(obj); would be wise to use for me... since basically all objects use the same Mesh and have the same model.
Main differences between some of the objects are: transparency, inverted culling and texture.
And the last thing I wondered about is that jPCT supports and uses 32-bit colored textures by default. But isn't it true that most devices these days only have a screen that is capable of displaying 16-bit colors? So why aren't the textures loaded as 16-bit textures? Wouldn't it be better to save my texture files (compressed) as 16-bit or 24-bit textures to reduce the APK file size? Or should I keep it 32-bit for future devices? I'm a bit puzzled about all of this...