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 5 ... 805
31
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.

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

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

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

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

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

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

38
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

39
Support / Re: Low performance when using uncompiled objects
« on: November 08, 2019, 01:06:41 pm »
It might be possible to do the VBO transfer beforehand as well. I'll try to look into it this weekend. The reason why this doesn't happen, is because all GL related operations have to take place in the GL thread (which owns the context). Depending on the renderer, this can either be applications main thread or the awt event dispatch thread of Java or a normal Java thread. To ensure that it always happens in the correct thread, some operations are postponed until jPCT can be sure to be in the right place. I never saw these little hickups as a problem myself (didn't notice them at all), so I kept it that way.
Have you tried to disable VBO support in Config (http://www.jpct.net/doc/com/threed/jpct/Config.html#glUseVBO)? In that case, the transfer doesn't happen and these hickups should go away in case they are really caused by this.

40
Support / Re: Animation Interpolation Between Sequences
« on: November 08, 2019, 01:01:25 pm »
You could do that and yes, it should update even when compiled, but it might not the very fast. It might be better to create different animations out of the individual frames and do the blending. You can reuse the frames, so it's not a memory issue.

41
Support / Re: Cpct?
« on: November 07, 2019, 10:33:48 am »
No, it's fine. It's some fixed point magix. You should be able to port that just at it is. Apart from that, your assumptions about the colors is correct. It's plain ARGB format.

42
Support / Re: Cpct?
« on: November 07, 2019, 06:30:04 am »
In the SoftGLRenderer.

43
Support / Re: Low performance when using uncompiled objects
« on: November 06, 2019, 10:32:59 pm »
I did something. It's called compileAllObjects(<FrameBuffer>) and can be found in World. It doesn't seem to cause a crash, so that's a good start. I'm not sure how much it helps though. There might still be the uploading of the actual data to GPU left at rendertime, but everything else should be done if you call this method. The GL renderer had be enabled when doing so or otherwise, the method will do nothing. Please give it a try: https://jpct.de/download/net/jpctapi_132b1.zip

44
Support / Re: Cpct?
« on: November 06, 2019, 08:45:20 pm »
I see. In that case, just move the call to col.ToArgb() out of the loop and assign the result, so that you don't have to do it thousands of times for frame.

45
Support / Re: Animation Interpolation Between Sequences
« on: November 06, 2019, 08:43:16 pm »
Yes, you could ignore the sub-sequences and just interpolate across the whole animation by using http://www.jpct.net/doc/com/threed/jpct/Object3D.html#animate(float). You could interpolate the needed index from the animation's total number of frames and the number of frames in each sub-sequence. However, this works only for adjacent sub-sequences and in most cases, it might look very strange anyway.

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