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 4 ... 805
Support / Re: Crash (native)
« on: January 28, 2020, 10:15:42 am »
That's the one (or at least very similar) that I'm seeing for my own apps every now and then. But it doesn't really help. All the engine is doing, is to tell the GL driver to draw some geometry. Why this causes a crash deep inside of the GL pipeline under some circumstances is beyond me. Another problem is, that you can't be sure when this happen because there's no context. You don't know if this happens during normal operation (I've never ever experienced this on one of my own devices) or if it happens when the context is shutting down anyway (or doing some other wierd thing).

Support / Re: How can we overcome the GC pauses?
« on: January 27, 2020, 07:17:26 pm »
I never really played around with GC settings and I never noticed it causing any slowdowns or hickups at least during the last decade. On earlier Android versions, this was a problem but on the desktop...!? Are you sure it's the GC that causes the problem?

Support / Re: Loading performance - Cotninuation
« on: January 23, 2020, 03:11:56 pm »
No, because a static method has no idea which objects are actually to compile. It can't access the actual references. In the TextureManager, this works because it's a singleton. But World or FrameBuffer aren't, so this is not possible.  It wouldn't help anything anyway, because static or not, the preloading/-warming has to happen in the render thread, which in case of the AWTGLRenderer is the AWT event dispatch thread. Hence the delayed operation. In this case, the actual build/compile/prewarm has to wait for the render thread to initialize the GL context (that would be indicated by the message that I asked for).
I'm not sure why it freezes though. It looks like a dead lock, because there are some sync operations between the threads going on, but if there's no "Waiting..."-message, I don't see why this should happen ATM. I need a test case to reproduce and debug this, I'm afraid. Can you provide me with something?

Support / Re: Loading performance - Cotninuation
« on: January 20, 2020, 09:17:14 am »
Seems like a dead lock between the render and the main thread. Are you getting some messages like this:

Code: [Select]
Waiting for renderer to initialize...<some number up to 50 here>

Support / Re: Loading performance - Cotninuation
« on: January 19, 2020, 11:17:04 pm »
You can configure the logger in the Logger class. Just set the log level to something higher (like and the messages should disappear. The compileAllObjects-method is still there, I've just renamed it so that it reflects better what it actually does. It's now called prewarmAllObject(<FrameBuffer>)

Support / Re: how to select uniform in renderhook
« on: January 14, 2020, 09:20:07 am »
There's no formal way. You could extend Object3D and add your uniform to it, or you could use to add some context instance to your object. That's a little bit dodgy, but it might do the trick.

I'm sorry, but I've no idea. All that jPCT-AE does is to render into the GL context provided by the app. It doesn't do anything in terms of modifying this context or playing around with layers or such. Whatever goes wrong here, has to be a problem with your app's setup, not with jPCT-AE.

News / Re: Why is the library not loading from the site? JPCT-AE is dead?
« on: December 14, 2019, 10:43:45 am »
No, it's not dead. The download works fine for me:

News / Re: Download jPCT
« on: December 14, 2019, 10:41:19 am »
No, it's not dead. The download works fine for me:

Support / Re: Cpct?
« on: November 21, 2019, 11:19:31 am »
Loading an image is a simple call to Image.FromFile(filename). Which leaves us the texture coordinates. Would that be in Object3D?
Are you sure? Loading is one thing, but you have to make an int[]-array out of the loaded image. I would rather think that this step is wrong.

Support / Re: Cpct?
« on: November 20, 2019, 10:31:07 am »
Then either your loading/conversion of the texture is wrong or your texture coordinates are. I tend to the former, because that's more likely to get broken in porting then some simple floats that should behave the same in both languages.

Support / Re: Low performance when using uncompiled objects
« on: November 19, 2019, 07:49:46 pm »
Please try this jar:

I've modified the behaviour so that prewarming should happen when using the AWTGLRenderer too. Please note that I've renamed the method World.compileAllObjects() to World.prewarmCompiledObjects(), because that's what it does. It doesn't actually compile anything but it uploads objects on which compile() has already been called.

Support / Re: Cpct?
« on: November 19, 2019, 12:53:53 pm »
Yeah, but Primitives don't really have proper texture coordinates. That's the point of ExtendedPrimitives. I suggest to port that too to have something that helps to limit the possible problem sources.

Support / Re: Cpct?
« on: November 19, 2019, 08:26:41 am »
I somehow doubt that it's a coordinate issue...have you tried to use a less complex model for testing? Like a cube from If that displays a texture (maybe use some simple RGB colored one like one stripe or each compontent) with with wrong colors, your conversion or rendering is wrong. If it doesn't render a texture at all or it looks distorted, your coordinate handling is wrong. Albeit I don't know how you should habe managed to do that, because the data types used for these should be the same between Java and C#.

Support / Re: Low performance when using uncompiled objects
« on: November 19, 2019, 08:21:29 am »
Oh, you are using the AWTJPCTCanvas renderer!? I wasn't aware of that, I always thought you were using the "normal" GL renderer. In that case, it's pretty clear that the preWarm doesn't help. That's because with the  AWTJPCTCanvas renderer, your application and the rendering are running in two different threads and your application can't access the GL context hence it can't execute preWarm directly and just ignores the call. I would have to make sure to push the preWarm() into the rendering thread's pipeline and execute it from there. I'll look at it.

Pages: 1 [2] 3 4 ... 805