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.

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.

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.

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:

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?

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.

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.

I did something. It's called compileAllObjects(<FrameBuffer>) and can be found in World. It doesn't seem to cause a crash, so that's a good start. I'm not sure how much it helps though. There might still be the uploading of the actual data to GPU left at rendertime, but everything else should be done if you call this method. The GL renderer had be enabled when doing so or otherwise, the method will do nothing. Please give it a try: https://jpct.de/download/net/jpctapi_132b1.zip

Yes, you could ignore the sub-sequences and just interpolate across the whole animation by using http://www.jpct.net/doc/com/threed/jpct/Object3D.html#animate(float). You could interpolate the needed index from the animation's total number of frames and the number of frames in each sub-sequence. However, this works only for adjacent sub-sequences and in most cases, it might look very strange anyway.