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
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

17
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.

18
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.

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.

20
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.

21
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 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
Support / Re: Cpct?
« on: November 15, 2019, 10:39:07 am »
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?

25
Support / Re: Cpct?
« on: November 15, 2019, 12:03:05 am »
I'm not sure...personally, I would create a set of uni-colored textures (one red, one green and one blue), set the ambient light to all white and see which color value a rendered pixel gets then. Maybe that helps to find the root cause.

26
Support / Re: Cpct?
« on: November 12, 2019, 11:24:02 am »
No, the are always positive.

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
Support / Re: Cpct?
« on: November 11, 2019, 10:23:59 am »
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:

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

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