Cpct?

[EgonOlsen]

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.

[AGP]

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 Expand


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


[AGP]

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 Expand


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.

[AGP]

Note: the following line produces, "Texture of polyID 1: DarthVader.png." And the texture was added to the TextureManager.

Code Select Expand

Logger.log("Texture of polyID 1: "+TextureManager.getInstance().getNameByID(sphere.getPolygonManager().getPolygonTexture(1)));

[EgonOlsen]

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 Expand


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?

[AGP]

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?

[EgonOlsen]

No, the are always positive.

[AGP]

I just spent much longer than anticipated converting pixels to uint[]. It works, now, but I'm getting the same result (shading if untextured, and a black silhouette if textured).

Have you another suggestion?

[EgonOlsen]

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.

[AGP]

I wish that it were a mere matter of placement, but I'm not getting any texturing whatsoever.

[EgonOlsen]

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.

[AGP]

I didn't know it always used a white texture. This is what it looks like with a green texture applied:

https://www.dropbox.com/s/638qg16adshb77d/screenFromSoftGLRenderer.png?dl=0

[AGP]

And blue looks really blue. The problem, then, has to be in the texture coordinates, don't you think? And where might I fix them? And don't say the Loader class, because the same problem happens with multiple formats (and I have to have gotten at least one right lol).

[EgonOlsen]

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

[AGP]

I haven't ported ExtendedPrimitives, but my second model was sphere from Primitives (first one was an OBJ sphere). Same problem.