I actually solved the ArrayIndexOutOfBoundsException. That little program I had written over a few years (it was the first one I built with jPCT) and it uses both the software and the hardware renderer (not at the same time obviously). And in changing it a million times I had introduced a stupid glitch in which I called run in one part of it (one attempt at getting the non-canvas OpenGL renderer to use the software loop), and started a separate thread that called it. So sometimes, draw() was being called twice at the same time (and before it draws it moves the objects). So that's that.

But now here's a question: what's the point of using AWTGLCanvas if the FrameBuffer's Graphics object will still be null (or useless, whichever it is)? I can no more use canvas.getGraphics()'s Graphics instance than I could a frame's (I can, but the screen will flicker). So is this a jPCT bug (I hope so)?

It's not a bug, it's by design. getGraphics() in FrameBuffer always refers to the Graphics instance of the software renderer's buffer.

The only option is to use the instance from canvas, but if that flickers...i don't know. I don't think that it's really meant to be used that way. Combining OpenGL and Swing/AWT in one canvas is questionable IMHO.

Looking at the AWTGLCanvas sources from LWJGL, it overrides both paint and update and let update call paint. There's also no call to super.paint() or something.

Edit: What exactly do you want to use the Graphics instance for? Maybe there's a more OpenGL friendly way for what you have in mind.

One way might be to load the GIF and draw each frame onto a BufferedImage of the proper dimensions (or do this via external software and save the result as a PNG image). Then you'd create a texture from that image and assign it to a quad overlay. You could animate the graphic by cycling through the proper sets of u/v coordinates for the quad's vertices.

I'm sure that isn't the best/easiest method, but it was the first idea that came to mind for animating a GIF on top the frame buffer.

Thanks to both of you again. I'm not sure the Overlay class would be my first choice, but I'll give it a try to see what happens. And Egon, a lot of my games use animated gifs. You load them as you would a static image, but with every iteration of the game loop Java2D draws a different frame (and loops them too).

You load them as you would a static image, but with every iteration of the game loop Java2D draws a different frame (and loops them too).

Yes, but you have no control about the animation, haven't you? Something that loads a gif, extracts the single images and the timing information and puts that into a texture and animates it would be a handy addon to jPCT. I would write such a thing if someones provides me with a proper way to extracts those information from the gif. The way in the given link seems to be quite strange to me...

I did this so far, but I have to do something else now. I might get back to it tonight. What I don't get about the Wikipedia article I found (http://en.wikipedia.org/wiki/Graphics_Interchange_Format) is whether I'm looking for a black (0, 0, 0) value and then a white (255, 255, 255) to determine the beginning and end of the color table or whether it's something else. This approach might be overkill anyway. There might be a cleverer way to find the individual frames with the provided Gif loaders.

And here's the cleverer approach by Alexander Hristov under the lesser general public license (which probably means you can use on jPCT but I haven't read it). The first is the tester I wrote (ArrayIndexOutOfBoundsException will be thrown if your gif doesn't have at least 4 frames), and the second is his FrameReader.

And here's the cleverer approach by Alexander Hristov under the lesser general public license (which probably means you can use on jPCT but I haven't read it).

Using it in jPCT would require one of two things:

1) jPCT be licensed by LGPL (i.e. source code release, i.e. no go)OR:2) A method be provided for swapping out Hristov's work for other versions (i.e. a seperate JAR from jpct.jar)

Niether of those options sounds ideal. I have had some experience with the GIF format (I wrote an ad rotator in c++ a few years ago for a company I was working for). I'll look into the format again and see if I can come up with a GIF loader class.

I have no problem with a dedicated Math-class in the core...it's just that i don't know what to put in there that doesn't fit into other Matrix or SimpleVector. But i admit that i forgot about adding the calcAngle-method to SimpleVector. It will surface in the next release.Any other suggestions on what to add math wise?

Thanks. And well, I would add generally-useful trigonometric functions. The difference between SimpleVector and Math would be that Math doesn't assume specific use. You can create a SimpleVector instance just to get the result of a function and apply as you will to your object, but that's counter-intuitive. With Math, you can have your objects oriented however you want to, for instance, and all you're really doing is calculating the product of your input (as opposed to necessarily applying a certain way).