Show Posts

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.

Messages - EgonOlsen

Pages: 1 ... 4 5 [6] 7 8 ... 796
Support / Re: Crash (native)
« on: March 09, 2018, 08:18:03 am »
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.

16k and'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.

Support / Re: Crash (native)
« on: March 08, 2018, 09:07:42 am »
Though, there's one problem... How can I set textures to my Object3D's after building and compiling them?
If I remember correctly it'd have a delay or something before the textures get visibly applied or something if you do it this way.
...I'm not sure what you mean by that...???

Support / Re: Crash (native)
« on: March 07, 2018, 07:42:51 am »
Blitting is just like rendering an object except that the data of that "blitting object" is dynamic and changes every frame. That's not a problem per se, animate objects do exactly the same. 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. It's the same code that desktop jPCT uses as well and it doesn't have this problem. My current app is blitting stuff before doing anything else and that is fine as well.

Your apps...are these all wallpapers or standard apps?

Support / Re: Crash (native)
« on: March 06, 2018, 04:41:06 pm »
That looks more like the normal distribution of GPUs in the Android market than anything else. The stackoverflow post doesn't help either. Of course, I'm rewinding the buffers. Otherwise, it wouldn't be able to render anything in the first place.

Personally, I just accepted a certain "crash rate". It just happens on some devices, may it be caused by driver errors or by some custom rom that has some great "optimization" in it that just doesn't work.

Any ideas about which "in the wild" crash rate we are taking here? 50% 1% 0.1%...any clues?

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?

Support / Re: Crash (native)
« on: March 06, 2018, 09:26:01 am »
No, they aren't using an emulator for sure, but...from my own experience, crashes happen mostly on MALI-based GPUs. Can you confirm this based on the Google Play stats?

Support / Re: Crash (native)
« on: March 05, 2018, 10:01:12 am »
Which buffer size do you mean exactly? And which device are you using to test this?

Support / Re: Environment Mapping with Software
« on: February 13, 2018, 09:13:08 am » would have to write yourself a line algorithm that not just interpolates x and y but also z (or the reciprocal of z) just like the polygon rendering routines do.

Support / Re: Environment Mapping with Software
« on: February 12, 2018, 09:42:43 am »
I'm not sure what you mean. Do you have  a screen shot of how it looks like and how it's supposed to look like?

Support / Re: Environment Mapping with Software
« on: February 09, 2018, 12:15:32 pm »
About the PolyLine in software mode: I've no plans to add support for this, I'm afraid.

Support / Re: Crash (native)
« on: February 09, 2018, 12:13:06 pm »
As mentioned, unloading of texture data from the GPU's memory has to happen in the GL rendering thread with a valid context. Otherwise, there nothing to unload it from. If the OS destroys a GL context, the graphics driver should actually free the associated memory. If that doesn't happen...well, I can't do anything about it then.
Have you tried this on some other device witha different GPU? Does it behave the same?

Support / Re: Environment Mapping with Software
« on: February 09, 2018, 12:10:32 pm »
The software renderer doesn't support multiple texture layers. Or at least not in the way in which the hardware renderer does. You could use a different path for the software renderer and use setBlending(true). Then assign three textures to it (diffuse, envmap and envbump) but use a single colored texture with (128/128/128) as color value for the envbump texture. That should give you some kind of blending between diffuse and env.

Support / Re: Ambient Mapping with Software
« on: February 07, 2018, 10:45:44 am »
Just to clarify this: With "ambient map", you mean the environment map?

Support / Re: Crash (native)
« on: February 07, 2018, 10:44:31 am »
To answer your last question: The textures and other native data is using that RAM.

About the render targets: As long as you don't create a new FrameBuffer, nothing happens for the textures if your rotate the device. 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. But 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?

Support / Re: Crash (native)
« on: February 05, 2018, 09:50:32 am »
Sorry, I haven't spotted your question ealier. The upload method works only at render time, i.e. if you call unload, it doesn't really unload but waits for the next render call and then does the unloading. That's because it has to happen in the GL thread or otherwise, there's nothing to unload.
If you rotate the device, it might be that the actual context is already lost (or onDrawFrame not called anymore on it) so that the unload never happens but somehow the driver keeps the copy in memory (albeit it shouldn't, because it should be bound to the context and if that changes, it should go away).
If you sure to be in the right thread, you can try to set Config.unloadImmediately to true and see if that helps.

Support / Re: Drawing a Graphic on a Separate Thread
« on: February 05, 2018, 09:44:18 am »
Then why don't you do the loading in a different thread and let the main thread render the splash screen? That's what I'm doing in Naroth as well.

Pages: 1 ... 4 5 [6] 7 8 ... 796