www.jpct.net

jPCT - a 3d engine for Java => Support => Topic started by: AGP on September 16, 2019, 06:45:59 pm

Title: Cpct?
Post by: AGP on September 16, 2019, 06:45:59 pm
Now that even Excelsior Jet has been made extinct, how would you feel about making a c# version of jpct? At least the OpenGL bits would be better.
Title: Re: Cpct?
Post by: EgonOlsen on September 21, 2019, 02:26:54 pm
Well, I'm not interested in C# at all. As long as I don't have to use it (and I don't see why that would happen), I won't touch it.
Title: Re: Cpct?
Post by: AGP on September 21, 2019, 07:07:51 pm
Even with the Mono project (and, thus, being multi-platform)? How come? Now that there's no way to make machine code out of Java, I think that I may go with C#.
Title: Re: Cpct?
Post by: EgonOlsen on September 23, 2019, 08:46:01 am
I looked into it briefly, I found it like Java with some additional clutter on top, that doesn't really make it any better and it's Microsoft. I have nothing against Microsoft, but the community is strange. Whenever I had to deal with the community of a Microsoft product (the scripting language in Powershell is an example where I had to rely on it, VBA for Access another), it's somehow disappointing...I've noticed a pattern:

Title: Re: Cpct?
Post by: AGP on September 24, 2019, 02:20:37 am
I have found every question I've ever had already asked and answered. I hope to be able to show something in the next few days.
Title: Re: Cpct?
Post by: AGP on September 27, 2019, 05:25:51 pm
I'm stuck in the FrameBuffer pixels thing. I found a way to do pretty much the same thing (https://stackoverflow.com/questions/1563038/fast-work-with-bitmaps-in-c-sharp (https://stackoverflow.com/questions/1563038/fast-work-with-bitmaps-in-c-sharp)), but pixels[] is too entrenched in the code.
Title: Re: Cpct?
Post by: AGP on September 30, 2019, 08:48:05 pm
Software renderer is compiled and running (not drawing anything yet, though).
Title: Re: Cpct?
Post by: AGP on November 05, 2019, 07:54:37 pm
I even ported the loader. Everything's working except for the actual rendering (when I don't assign random colors to the polygons in SoftGLRenderer). In clearSoftware(Color col), I'm printing this: Logger.log("Coloring. Color: "+color +", Col: "+col.ToArgb());

And the result is: Coloring. Color: 16711680, Col: -65536

Could this be a byte order thing or is it just because the first integer doesn't hold the alpha?
Title: Re: Cpct?
Post by: AGP on November 06, 2019, 06:08:24 am
Sure enough replacing pix=color; with pix=col.ToArgb(); started clearing. I'm now getting unshaded, untextured objects rendered against the appropriate color. Is my line much slower than your bit-shifting?
Title: Re: Cpct?
Post by: EgonOlsen on November 06, 2019, 12:59:23 pm
It's certainly slower. I'm not sure from where exactly this code snippet comes!? Is it inside the rendering loop or some loader/setup code. In case of the former, it might be critical.
Title: Re: Cpct?
Post by: AGP on November 06, 2019, 03:47:44 pm
It's in clearSoftware(Color).
Title: Re: Cpct?
Post by: EgonOlsen 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.
Title: Re: Cpct?
Post by: AGP on November 07, 2019, 03:38:08 am
Done. But if the clear color was wrong, doesn't it follow that the texture-rendering stuff would be, as well (hence the unshaded sillouettes)? Put differently, where do I find the perspective-correct texture code in which to look for this issue?
Title: Re: Cpct?
Post by: EgonOlsen on November 07, 2019, 06:30:04 am
In the SoftGLRenderer.
Title: Re: Cpct?
Post by: AGP on November 07, 2019, 06:49:05 am
It's a bit hairy for me, since I don't really know what you're doing, but from what I gather alpha should be 24 bits shifted LEFT, red shifted 16 left, and so on. Is this line (under OptiZ) wrong (green is shifted by 8, then the whole thing gets shifted by 16)?
Code: [Select]
g=(((col>>8)&255)*(sgI>>10))>>16;
Title: Re: Cpct?
Post by: EgonOlsen 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.
Title: Re: Cpct?
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;
}
Title: Re: Cpct?
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 (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.
Title: Re: Cpct?
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)));
Title: Re: Cpct?
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?
Title: Re: Cpct?
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?
Title: Re: Cpct?
Post by: EgonOlsen on November 12, 2019, 11:24:02 am
No, the are always positive.
Title: Re: Cpct?
Post by: AGP on November 13, 2019, 08:49:55 pm
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?
Title: Re: Cpct?
Post by: EgonOlsen 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.
Title: Re: Cpct?
Post by: AGP on November 15, 2019, 07:31:04 am
I wish that it were a mere matter of placement, but I'm not getting any texturing whatsoever.
Title: Re: Cpct?
Post by: EgonOlsen 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.
Title: Re: Cpct?
Post by: AGP on November 18, 2019, 12:28:22 am
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 (https://www.dropbox.com/s/638qg16adshb77d/screenFromSoftGLRenderer.png?dl=0)
Title: Re: Cpct?
Post by: AGP on November 18, 2019, 12:42:08 am
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).
Title: Re: Cpct?
Post by: EgonOlsen 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) (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#.
Title: Re: Cpct?
Post by: AGP on November 19, 2019, 08:34:24 am
I haven't ported ExtendedPrimitives, but my second model was sphere from Primitives (first one was an OBJ sphere). Same problem.
Title: Re: Cpct?
Post by: EgonOlsen 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.
Title: Re: Cpct?
Post by: AGP on November 20, 2019, 01:33:54 am
OK, done. Same thing: single-colored textures work, images don't (and the images aren't null, either).
Title: Re: Cpct?
Post by: EgonOlsen 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.
Title: Re: Cpct?
Post by: AGP on November 20, 2019, 07:37:24 pm
Loading an image is a simple call to Image.FromFile(filename). Which leaves us the texture coordinates. Would that be in Object3D?
Title: Re: Cpct?
Post by: EgonOlsen 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.
Title: Re: Cpct?
Post by: AGP on November 21, 2019, 07:26:03 pm
I applied my ReverseBytes to the texels and still got black. Actually, at first I got fully-transparent, then I switched the bitwise OR for a bitwise AND for alpha as follows and I was back to black.

Code: [Select]
private static System.UInt32 ReverseBytes(System.UInt32 value) {
    value = (value & 255);//MAKE OPAQUE IT's AN OR IN SoftGLRenderer. WHY?
    return (value & 0x000000FFU) << 24 | (value & 0x0000FF00U) << 8 | (value & 0x00FF0000U) >> 8 | (value & 0xFF000000U) >> 24;
}
    }
Title: Re: Cpct?
Post by: AGP on November 22, 2019, 08:30:37 am
You're a good man, Egon. You were right, the texels[] were black. I'm forced to use the following rather slow nested loop, but voilá, it works.

I think that I'm going to tackle a skeletal structure for it before I try my hand at a hardware renderer, but the eventual C# hardware renderer will benefit from direct access to OpenGL.

Code: [Select]
    int i = 0;
    for (int y = 0; y < image.Height; y++)
for (int x = 0; x < image.Width; x++)
     texels[i++] = (uint) image.GetPixel(x, y).ToArgb();