Hello,

getting back again on this matter, the outcome was because on Hardware Renderer we can blit with a floating coordinate system, whereas in the softwre renderer we can't, but we could use floating type for both and then just use the float point for hardware and cast to int on the software renderer, thus having the legacy code running well keeping compatibilty. I think that was the feasable idea behind this whole conversation.

lemme know if its possible to do or not,

many thanks,

Ok...as always, even simple things are not as simple as they seem at first glance, but this might do the trick:

https://jpct.de/download/beta/jpct.jar

and for jPCT-AE

https://jpct.de/download/beta/jpct_ae.jar

I've simply replaced the int types in the blit methods by floats. It worked fine on my tests albeit I didn't test the actual sub-pixel stuff.

Yes, that should work. I'll try to add it in the next few days.

There will always be SIGSEGVs...no driver is perfect and people are doing all kinds of strange things with their devices that are out of your control.

I'm not sure what you mean? Which texture?

No idea about the UV-mapping...about the black polygons? Are you using shaders? If so, that's most likely the problem. Different GPUs show different behaviours in some edge cases and in some cases, it might result in just a black rendering. So...are you using shaders and which devices are affected?

There might a small hickup when uploading textures, which is why you can preload them. But that applies to compiled as well as uncompiled objects. Have you tried to increase the VM's memory pool?

That basic light formula is the same. I've noticed some differences between compiled and "normal" objects regarding vertex lighting as well depending on the GPU used. Especially older AMD based ones have a slightly different interpretation of how to shade the polygons which can result in dimmer lighting in some edge (no pun intended) cases. If you can't compensate for that with a brighter light or by changing some other values like the attenuation, you are basically out of luck and might have to switch to shaders.

The camera's rotation is never reset so I think the issue might lie here...

Yes, most likely. You can try to apply http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Matrix.html#orthonormalize() from time to time to it and see if that helps.