151
Projects / Re: Instrument Cluster for a Muscle Car
« on: March 30, 2018, 07:34:37 pm »
Looks cool! Interesting idea too, good luck!
I suppose it's mostly or only 2D?
I suppose it's mostly or only 2D?
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Yes, it's save and it's cheap. However, compiling the object fixes the texture stage count for it. That's why you are getting that exception with the TextureInfo. YOu could assign a TextureInfo with the same amount of stage but using some dummy textures, compile, assing the actual textures. That should actually work.So I tried this with two TextureInfo's (one 3-layered with dummy textureID and one 3-layered with the actual textureID's) but I am still getting the Exception.
final int dummyID = textureManager.getTextureID(textureManager.getNameByTexture(textureManager.getDummyTexture()));
final TextureInfo ti = new TextureInfo(dummyID);
ti.add(dummyID, TextureInfo.MODE_ADD);
ti.add(dummyID, TextureInfo.MODE_ADD);
obj.setTexture(ti);
obj.build();
obj.compile();
obj.strip();
world.addObject(obj);
world.renderScene(frameBuffer);
world.draw(frameBuffer);
03-18 11:35:18.768: E/AndroidRuntime(4487): java.lang.ArrayIndexOutOfBoundsException: length=1; index=1
03-18 11:35:18.768: E/AndroidRuntime(4487): at com.threed.jpct.Object3D.setTexture(Object3D.java:3660)
When the real TextureInfo only holds one texture(layer) it won't crash... So it doesn't really seem to set 3 layers using the dummy textures or something..?// old
clockBar[i].rotateZ(((float) i / 10) * 361f);
//new
clockBar[i].rotateZ(((float) i / 10) * ((float)Math.PI)*2f);
Yes, it's save and it's cheap. However, compiling the object fixes the texture stage count for it. That's why you are getting that exception with the TextureInfo. YOu could assign a TextureInfo with the same amount of stage but using some dummy textures, compile, assing the actual textures. That should actually work.Alright, thanks for the help!
16k and 32k...it's absurd IMHO to use those. A 16k texture with 32bit and no compression but mipmaps would require ~2GB auf GPU memory and almost the same in VM memory. Still not very feasible IMHO.Hmmm yeah, I understand... Though that would be true for squared textures but for me just one dimension would be okay. I can already kind of use 16384x4096 textures on my phone using NPOTTexture (which I guess is kind of a hack-ish way to surpass the 8192 limit restricted by jPCT. So well yeah...
A lot of apps using jPCT-AE are doing it all the time (including mine) without any problems. However, I'm well aware that it might cause trouble, which is why there are these config settings for it (which are just some shots in the dark as well). The actual problem is, that I've no idea why this happens and when. I've checked the code at least a dozen times because of this and it's just fine.
Your apps...are these all wallpapers or standard apps?Mixed, however I can run the renderer class in a regular Android Activity too but that'd not really make much of a difference..?
Any ideas about which "in the wild" crash rate we are taking here? 50% 1% 0.1%...any clues?Well it depends on the context..? Higher polygon count seems to make it more likely to crash. While lower polygon models don't crash at all...
And because fiddling around with the blitting config seems to changes things for you: Are you actually blitting stuff? What happens if you don't?Yes, I do blit things before the first world.draw() call.
Which buffer size do you mean exactly?03-05 10:19:44.749: I/jPCT-AE(2711): Blitting buffer size: 600
compat mode:
runs: 10
succes: 5
crashes: 5
no compat mode:
runs: 10
succes: 1
crashes: 9
compat mode:
runs: 10
succes: 4
crashes: 6
no compat mode:
runs: 10
succes: 0
crashes: 10
compat mode:
runs: 10
succes: 5
crashes: 5
no compat mode:
runs: 10
succes: 0
crashes: 10
As you can see it drops the chance of crashing from ~96% to ~53%.And which device are you using to test this?I'm currently using a Genymotion emulator (With a Nexus 5, Android 5.0.1 build) to reproduce these crashes. (I can reproduce crash on older physical devices, just to make sure... Plus many people reported this SIGSEGV crash through the Google Play Store and I think I can assume they are not using an emulator... )
My device (ZTE Axon 7 @ Android 7.1.1 Custom ROM):
-> Low VM RAM (discard what I said about 300 MB RAM usage in VM earlier... It's about 30 MB actually (I guess my eyes added a digit... derp))
-> No memoryleak when rotating screen in VM (but there is in native/video memory)
-> However, in developer options -> Active services, the RAM usage keeps rising (300+ MB+ here (could go much higher though (1,8+ GB after many many screen rotations => device will kill other processes and might even reboot here) so I suppose it's not VM but native+video+VM that is being displayed here)
Some old tablet (Difrnce DIT4350 @ Android 4.0.4)
-> Low VM RAM
-> No memory leak with rendertarget textures
-> Crashes after many screen rotations..?
Old tablet 2 (Asus TF101 @ Android 4.0.3)
-> Low VM RAM
-> Crashes after many screen rotations?
Emulator #1 (Android 4.1.1):
-> Low VM RAM
-> No memory leak with rendertarget textures in VM
Emulator #2 (Android 4.2.2):
-> Low VM RAM
-> No memory leak with rendertarget textures in VM
Emulator #3 (Android 7.1.0):
-> Low VM RAM
-> No memory leak with rendertarget textures in VM
-> I don't see the VM+Video+Native memory usage as high as on my own device here in developer options... Unloading seems to work just fine here
-> No memory leak with rendertarget textures in native+video
-> Low VM RAM
-> No memoryleak with rotating screen
-> Memoryleak with renderers when restarted in native+video RAM (renderer restarts when a setting is changed)
To answer your last question: The textures and other native data is using that RAM.Ah understood.
About the render targets: As long as you don't create a new FrameBuffer, nothing happens for the textures if your rotate the device.Yes, they are fine if the device is rotated
However, I've no idea how it's supposed to work that way, because rotating the device should destroy the context (simply because width and height are changing) and so you should need a new instance of the buffer.Well it is a live wallpaper, and live wallpapers are able to preserve EGL context on pause (or something like that).
But anyway...as long as the buffer doesn't change, there's actually no need to unload the render target texture at all. Have you tried what happens if you don't do that at all?I tried that... but the render target won't have the right dimensions then and it will give weird results on screen.