I guess I understood that, but aren't there scenarios when textures don't have to be re-uploaded? (so the textures don't need to stay in VM any more, right?)
So isn't it possible to clear the texture data in VM? Setting the texture data instances to null I suppose, so the GC can pick it up...

Hello,

Well I guess the title explains all...
I wondered because when textures get uploaded to the GPU (even when pixeldata is kept so it should be safe for any context change) why does it still need the texture data in the VM memory?

Is it possible to not have the textures in VM memory but uploaded to the GPU only?

Cheers,
AeroShark333

Hmmm, well yeah I wanted to help to do something back to this community. I've learned quite a lot here and I've been using jPCT-AE for some of my apps
Not completely sure if it's needed, but well... not everyone in the Netherlands has amazing English skills but the English language is quite well implemented in the Dutch education system.
But the online tool sounds alright to me

Hello everyone,

I would like to share my live wallpaper app here which I made using some amazing 3D engine called jPCT-AE!



This app has been out for a while now actually but I never really published it here because it's actually still not finished...
I decided to publish it already so people can already use/enjoy the live wallpaper.
I'm really proud of my work although it's probably not nearly the best live wallpaper out there.
That's not my aim either but I guess I'm a little of a perfectionist so I will try to keep improving it.

I'm not really a programmer, it's just an hobby for me. (I have a busy life as an Applied Physics student so I don't spend that much time on programming)
This is not my first app using this library, my most popular app is Skin Viewer 3D (in my forum signature) which is more than a year old now already.
The GLSL Shader language was rather new to me when I began this project but I managed to learn it a little from examples mainly!
The custom shaders are based on the default shaders but they have mainly be written by myself (and with a lot of help from the internet/Google).
My biggest problem is probably to support a large range of devices since I'm not really able to test on a lot of devices myself.

What I like most about my own live wallpaper is that it is very customizable.
And it's quite funny to see how the live wallpaper changed over the passed few months.
I tried my best to optimize the wallpaper as much as possible to reduce battery usage...
(usually people say Live Wallpapers are battery consuming but in my opinion it just depends HOW you use your live wallpaper... if you're playing with it constantly on your homescreen then it sort of makes sense to me I guess)
Not all features of the app work properly yet but I'm still working on that.

Screenshots:
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-21-13-53.jpg
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-21-19-22.jpg
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-23-11-46.jpg
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-23-12-25.jpg
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-23-12-57.jpg
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-23-13-24.jpg
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-23-13-37.jpg
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-23-14-01.jpg
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-23-15-53.jpg
https://dl.dropboxusercontent.com/u/47988037/Android/Earthify%203D/v3.9.0/scrns/Screenshot_2016-10-19-23-17-32.jpg

Google Play Store link:
https://play.google.com/store/apps/details?id=com.aeroshark333.earthify3d

Special thanks:
EgonOlsen - For making this amazing 3D library and for providing quick support on the forums!

Feel free to comment!

Cheers,
Abiram
(AeroShark333)

Yeah the crashreport is without the 'fix', so basically the same version I sent you in PM a few days ago.
I've been using my 'fixed' version (which doesn't seem to crash).

Hmm, I see... I'm guessing it's the texture uploading... (8192x4096 textures...  )

EDIT:
Would it be possible to increase the uploading speed to GPU? Maybe with a bigger buffer size or something?

Got it, thanks a lot for the help
I've been using my live wallpaper for a few days now and it hasn't crashed so far

There is something I'm wondering though...
So I upload textures, build the world objects and compile the world objects in a separate Thread. While doing so, the FrameBuffer will keep blitting a loadingscreen (untill the Thread dies). Then World.renderScene and World.draw will be called... But the first time when that is called, the (last blitted loading) screen seems to hang for a few seconds... As if either World.renderScene or World.draw is doing heavy blocking operations on its first call... Is it possible to move the (heavy) operations that happen in the first World.renderScene/World.draw call in the separate loading Thread I talked about earlier?

EDIT:
Coincidentally just got a user report on the Google Play Store with the following crash report:

_________________________________________________

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Xiaomi/land/land:6.0.1/MMB29M/V7.5.9.0.MALMIDE:user/release-keys'
Revision: '0'
ABI: 'arm64'
pid: 18979, tid: 18993, name: GLThread 9008  >>> com.aeroshark333.earthify3d <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x75245000
    x0   00000007fe9ac5f0  x1   0000000075244fd0  x2   0000000000008f38  x3   0000000000000000
    x4   0000000000000000  x5   0000005579243b94  x6   00000007fe9afa60  x7   0000000000000000
    x8   0000000000000000  x9   0000000000000000  x10  0000000000000000  x11  0000000000000000
    x12  0000000000000000  x13  0000000000000000  x14  0000000000000000  x15  0000000000000001
    x16  0000007f9a7915e8  x17  0000007fa82f3c08  x18  000000000000000c  x19  0000000000000000
    x20  000000000000c438  x21  00000055791fa45c  x22  00000055791fa3fc  x23  00000007fe9ac5f0
    x24  0000000000000000  x25  0000000000000000  x26  000000557921ac18  x27  000000557918f040
    x28  0000000000000000  x29  0000007fa3d454f0  x30  0000007f9a278044
    sp   0000007fa3d454f0  pc   0000007fa82f3d68  pstate 0000000020000000

backtrace:
    #00 pc 0000000000019d68  /system/lib64/libc.so (memcpy+352)
    #01 pc 000000000017d040  /system/vendor/lib64/egl/libESXGLESv2_adreno.so (_ZN20EsxVertexArrayObject18UpdateInternalVbosEPK17EsxDrawDescriptorjPK16EsxAttributeDesc+1504)
    #02 pc 0000000000271518  /system/vendor/lib64/egl/libESXGLESv2_adreno.so (_ZN20A5xVertexArrayObject11CalcVfdRegsEPK17EsxDrawDescriptorP10A5xVfdRegsi+152)
    #03 pc 0000000000279190  /system/vendor/lib64/egl/libESXGLESv2_adreno.so (_ZN10A5xContext16ValidateVfdStateEPK17EsxDrawDescriptori+48)
    #04 pc 000000000028b700  /system/vendor/lib64/egl/libESXGLESv2_adreno.so (_ZN10A5xContext13ValidateStateEPK17EsxDrawDescriptor+2528)
    #05 pc 000000000028bbd0  /system/vendor/lib64/egl/libESXGLESv2_adreno.so (_ZN10A5xContext18HwValidateGfxStateEPK17EsxDrawDescriptor+16)
    #06 pc 0000000000114e5c  /system/vendor/lib64/egl/libESXGLESv2_adreno.so (_ZN10EsxContext16ValidateGfxStateEPK17EsxDrawDescriptor+636)
    #07 pc 0000000000107618  /system/vendor/lib64/egl/libESXGLESv2_adreno.so (_ZN10EsxContext21DrawElementsInstancedE11EsxPrimTypej10EsxPixTypePKvji+440)
    #08 pc 00000000000db3c4  /system/vendor/lib64/egl/libESXGLESv2_adreno.so (glDrawElements+68)
    #09 pc 00000000000067b4  /system/vendor/lib64/egl/libGLESv2_adreno.so (glDrawElements+28)
    #10 pc 0000000072ed0088  /data/dalvik-cache/arm64/system@framework@boot.oat (offset 0x2406000)

_______________________________--
Device: Redmi 3S
Android: 6.0

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/7KaLwuPr

Setting: Config.blittingMode=2
Result: Crashes without being able to see the world.
Crashlog: http://pastebin.com/qV08hctZ

Setting: Config.blittingMode=3
Result: Crashes without being able to see the world.
Crashlog: http://pastebin.com/7u1vCkWr

Setting: Config.blittingMode=4
Result: Crashes without being able to see the world.
Crashlog: http://pastebin.com/VUc3BA57

Settings: 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/a14ceSVb

Settings: Config.blittingMode=6
Result: Crashes without being able to see the world.
Crashlog: http://pastebin.com/NTPd3Fr1

Settings: 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/QfZtQpdS

Settings: 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...