16
News / Re: Download jPCT
« on: December 14, 2019, 10:41:19 am »
No, it's not dead. The download works fine for me: http://www.jpct.de/download/net/jpct-ae.zip
News:
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.
17
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.
19
Support / Re: Low performance when using uncompiled objects
« on: November 19, 2019, 07:49:46 pm »
Please try this jar: https://jpct.de/download/net/jpct.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.
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.
21
I somehow doubt that it's a coordinate issue...have you tried to use a less complex model for testing? Like a cube from http://www.jpct.net/doc/com/threed/jpct/util/ExtendedPrimitives.html#createCube(float)? 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#.
22
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.
23
Then something in your loading/conversion is wrong. jPCT always uses a texture of some kind. It can't do without. What happens, if you don't set a texture at all? You should get a white texture then. If you don't, your reading from the texture's array is wrong. If you do, then your loading is wrong.
24
Support / Re: Low performance when using uncompiled objects
« on: November 15, 2019, 12:04:47 am »
The OpenGL renderer does support it, so it should actually do something. How large are these textures and which graphics card are you using for your tests?
27
Support / Re: Low performance when using uncompiled objects
« on: November 11, 2019, 01:23:08 pm »So I tried to set Config.glUseVBO to false, and did a lot of different combinations and cases, and still got the same results, perhaps my graphics card always tends to use VBO? Some say that the latest cards only have support for VBO and Display Lists are becoming deprecated.I guess the driver could do something like that, yes. After all, OpenGL is a client/server model (with the client being the application and the server being the driver/GPU) and you can't be sure which data resides on the client or gets copied over to the server in the process.
28
Support / Re: Low performance when using uncompiled objects
« on: November 11, 2019, 12:33:24 pm »
No, you need to call that method anyway. It now does the prefilling in addition to what it did before.
29
I'm not sure about C#, but in Java, you have to handle the fact that the most significant bit of an int actually is the sign. So when shifting value & 0xff000000 down by 24, you have to remove the sign bit afterwards, because if not, you'll end up with some very different number from what you expect. See this test case:
Maybe that's an issue here?
Code: [Select]
public class ShiftTest
{
public static void main(String[] args)
{
int value = 0xabcdef12;
int cw = (value & 0x000000ff) << 24 | (value & 0x0000ff00) << 8 | (value & 0x00ff0000) >> 8 | (value & 0xff000000) >> 24;
int cr = (value & 0x000000ff) << 24 | (value & 0x0000ff00) << 8 | (value & 0x00ff0000) >> 8 | ((value & 0xff000000) >> 24 & 0xff);
System.out.println("wrong: "+Integer.toHexString(cw));
System.out.println("correct: "+Integer.toHexString(cr));
}
}
Maybe that's an issue here?
30
Support / Re: Low performance when using uncompiled objects
« on: November 09, 2019, 02:44:09 pm »
Try this one. It should also prefill the VBO: https://jpct.de/download/net/jpct.jar