Cpct?

[EgonOlsen]

No, Hashtable and HashMap don't care about this. And why would they? I consider it to be rather...not stupid...but, well let's go with stupid anyway...behaviour to throw an exception in this case. You would have to modify the code to check for the key and remove/add it or replace it, if that's supported.

[AGP]

I added the test. And then I think I fixed another issue. Now I'm only getting the appropriate background color, and convertTexture(Texture) is printing [ 12/30/2020 3:57:37 AM ] - ERROR: Failed to upload texture! texID, unhelpfully (helplessly?) is always 0.

[EgonOlsen]

That's before the actual upload happens. All it does, is to make the GL driver generate an ID. If that fails, it's most likely that something with your handling of the native buffers is wrong...or whatever C# uses in this place.

[AGP]

About that, I made a GenericBuffer<T> class to mimic Java's xBuffer classes. But there's a chunk in convertTexture() where you do IntBuffer (GenericBuffer<int> in mine) buf = getSmallBuffer(); GL11.GenTextures(buf) and then you claim that the texture refence is now in buf. But buf is a local variable that's never called again.

[EgonOlsen]

The GenTexture call puts it there.

[AGP]

Happy 95% of what remains of this year, pal.

What's with WorldProcessor.createWSNormals()? It seems to me to be both a waste of processing time and a waste of memory.

[AGP]

And what is supposed to be in visList.vobj[0]? It's become null as I tinkered with the World class.

[EgonOlsen]

WorldProcessor.createWSNormals() is needed for the software renderer when using environment mapping in world space. In every other case, it's not even called. All it does is to create 3 float[]-arrays (per WorldProcessor thread) to store the world space normals in, if needed and only once. So as long as you don't use this feature, it won't be called and if you do, then you have to live with the additional memory overhead.

vobj[0] is like any other index of vobj[]. When using the software render, it stores the reference to either the object itself (in that case, it's the same as vorg) or, if the polygon that belongs at this index is being clipped, a reference to the object that contains the clipped polygons.

[AGP]

Can you think of a reason why it might be null? It doesn't happen with the 1.03 World instance, but does with the 1.31.

[EgonOlsen]

vobj and vorg are either populated with the same instance (the actual object itself) or vorg is the object and vobj is the clipped polygon object. If vorg isn't null, but vobj is, then the clipped polygon object is null for some reason.

[AGP]

I'm not getting any lights, I think, since I ported World to 1.31. Everything I render with the software renderer is fully, flatly, black.

And by the way, software rendering on 1.31 is SO MUCH slower than on 1.03 (possibly the transparency additions but I would think it's because of the overall bloating of the code).

[EgonOlsen]

On my side, the software rendering code hasn't changed in ages. If something has been added, it has been added in a new method and leaves the old methods untouched, so having transparency added does nothing to the existing methods. It might be the runtime that for some reason decides not to just-in-time compile some methods or something like that.

[AGP]

I'm not even where I was when I started porting this thing: now even when I don't call setTexture I get a solid black, unshaded model. Same models that were working before. I had SoftGLRenderer print System.Console.WriteLine("Pixel color: "+r +", "+g +", "+b +" Pixel: "+pixels[tx]) and I get for uint[] pixels the interesting value of 4,278,190,335 (binary 11111111000000000000000011111111) in drawShadedZbufferedFilteredScanline(). If you have any insights, please share them because I need them.

[AGP]

Update: I had the epiphany of blitting the texture and calling setShadingMode(Object3D.SHADING_FAKED_FLAT). The texture blit looks perfect and SHADING_FAKED_FLAT made the model shade by the ambient light color (and still not by an added light), but fully and properly textured. I guess the problem would be in the gouraud shading block. Again, any direction would be greatly appreciated.

[EgonOlsen]

The thing is that faked flat actually means exactly that: It's fake. It's still using gouraud shading (there are no other rendering modes in jPCT's software renderer) but with the same color used on every vertex. If that fixes something, I can only imagine that somehow, your light intensity calculation on the vertices is off.