Recent Posts

Pages: [1] 2 3 ... 10
1
Support / Re: Cpct?
« Last post by AGP on November 11, 2019, 03:58:02 pm »
I know that Java doesn't have them, but should I just make pixels[] uint or is there a scenario when they're supposed to be negative?
2
Support / Re: Low performance when using uncompiled objects
« Last post by EgonOlsen 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.
3
Support / Re: Low performance when using uncompiled objects
« Last post by EgonOlsen 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.
4
Support / Re: Low performance when using uncompiled objects
« Last post by Jakes on November 11, 2019, 12:05:19 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 also tried with uncompiled objects (with and without textures, with more or less objects) but got to the same result.

Quote
Try this one. It should also prefill the VBO: https://jpct.de/download/net/jpct.jar

Thanks, I'll give it a go when I get home later on.

Btw, no need to call World.compileAllObjects(FrameBuffer) or any other method on this change?

5
Support / Re: Cpct?
« Last post by EgonOlsen 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?
6
Support / Re: Cpct?
« Last post by AGP on November 11, 2019, 12:31:05 am »
Note: the following line produces, "Texture of polyID 1: DarthVader.png." And the texture was added to the TextureManager.

Code: [Select]
Logger.log("Texture of polyID 1: "+TextureManager.getInstance().getNameByID(sphere.getPolygonManager().getPolygonTexture(1)));
7
Support / Re: Cpct?
« Last post by AGP on November 10, 2019, 08:47:30 pm »
Update. I'm now getting a pretty fast framerate and rendering solid, shaded but untextured objects. (I was adding to the wrong byte and it was just OR 255):
https://www.dropbox.com/s/638qg16adshb77d/screenFromSoftGLRenderer.png?dl=0

Code: [Select]
private static System.UInt32 ReverseBytes(System.UInt32 value) {
    value = (value | 255);//MAKE OPAQUE
    return (value & 0x000000FFU) << 24 | (value & 0x0000FF00U) << 8 | (value & 0x00FF0000U) >> 8 | (value & 0xFF000000U) >> 24;
}

If I call setTexture on this MD2, Darth Vader becomes unshaded and solid black.
8
Support / Re: Cpct?
« Last post by AGP on November 10, 2019, 08:22:45 pm »
I read somewhere that the bytes are flipped. So before drawing I'm trying to change them the following way. I get only a blank screen, once more.

Code: [Select]
private static System.UInt32 ReverseBytes(System.UInt32 value) {
    value += 4278190080;//MAKE OPAQUE; IS THIS RIGHT? (THAT'S 1111 1111 0000 0000 0000 0000 0000 0000)
    return (value & 0x000000FFU) << 24 | (value & 0x0000FF00U) << 8 | (value & 0x00FF0000U) >> 8 | (value & 0xFF000000U) >> 24;
}
9
Support / Re: Low performance when using uncompiled objects
« Last post by EgonOlsen on November 09, 2019, 02:44:09 pm »
Try this one. It should also prefill the VBO: https://jpct.de/download/net/jpct.jar
10
Support / Re: Low performance when using uncompiled objects
« Last post by EgonOlsen 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.
Pages: [1] 2 3 ... 10