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] 2 3 ... 791
Support / Re: Documentation Error
« on: March 20, 2018, 10:24:45 pm », it doesn't. jPCT has no concept of w? when it comes to texture coordinates.

Support / Re: Crash (native)
« on: March 18, 2018, 08:36:56 pm »
Interesting...maybe I'm stripping dummy texture layers away...I'm not sure ATM, but if it works now... ;)

Make sure to call build() before setting the pivot. Otherwise, it will be resetted to a calculated one.

I'm not entirely sure, if I got the problem correctly. I would say that you could either just move the rotation pivot (which might be a little fiddly, because it's given in object space) or just use multiple dummy objects that are all located at that central point...and then rotate those.

Support / Re: Crash (native)
« on: March 11, 2018, 05:18:59 pm »
Try this jar:

It should support textures up to 16384 in size.

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?

Pages: [1] 2 3 ... 791