Ok, also in Deutsch:

Stimmt schon, dass die Beispiele uneinheitlich sind. Das liegt primär daran, dass sie zu völlig unterschiedlichen Zeitpunkten entstanden sind und ich jetzt manche Dinge nicht mehr so machen würde, die ich z.B. in Bounce so gemacht habe. Das "fortstrittlichste" ist somit sicher das fps-Beispiel. Es sieht so aus, wie ich jPCT momentan benutze.
C++-Stylisch kann ich nicht nachvollziehen. Ich habe nie viel C++ gemacht, also sollte mich das wirklich wundern. Sie sind sicher nicht sehr OOisch, aber das ist Absicht, damit irgendwelche wilden Objektkonstruktionen nicht vom eigentliichen Inhalt ablenken. Oder was meinst du jetzt genau?

Edit: Wenn du Tutorials schreiben möchtest, fände ich das großartig. Ich kann mich ja leider auch nicht zerteilen, weswegen es eine große Hilfe wäre.

Changes are documented here: http://www.jpct.net/changes.html

In addition, i finally replaced the jPCT-demo from the stoneage with a more current version. To be precise, the new jPCT-demo is simply the fps-demo from the examples-dir of the API-distribution bundled with LWJGL 0.7.

Have fun!

Another method we were thinking about using is loading pre made (serialized) texture objects instead of loading jpg and turning them into textures. Also we were thinking evenuatlly we would like to manipulate the textures on a pixel level.

Anyway, we are just trying to find something that will help us get the game built faster instead of f**king about with the engine - which we seem to suck at and you do not

Serialization is supported by jPCT, but the serialized output can be quite large...at least if you serialize the whole world. Manipulating textures on the pixel level is also possible by implementing the ITextureEffect interface. However, this can't be used to create textures. If it's a showstopper for you that you don`t have a constructor for textures that takes an int[] as parameter, i'll possibly add this.

I like your Doom-engine...what's wrong with it? (Except for the limitations these engines always have).

...i've managed to upload an updated version of it. Finally!
The new version uses jPCT 0.95 instead of the ancient 0.79 the old version was using.

Please send me the model then, so i can verify the problem myself. It should work...

Changes/fixes are documented here: http://www.jpct.net/changes.html

Have fun!

I'm not quite sure what you mean with "level-format"...you can basically use any supported format (well, except MD2) for storing your level. The demos are using the 3DS-format. It's quite small (at least compared to the ASCII-based formats) and a lot of tools are available for conversion from and to 3DS.
The XML-format was an attempt to create something that's easy to read/write, extendable and that supports portals. You may use it, but you have to do the conversion into jPCT's XML-format yourself.

About the final-thing: There are two reasons for this. Older VMs like it performance wise and there's not much encapsulation used within jPCT, so it would be quite hard to extend Texture (for example) without knowing something about the inner workings. I did this to keep the API small and fast...the price you pay for this is, that it's not easy for others to extend it. I can remove the final and see how it works out performance wise, but i doubt that you'll be very happy with it. What exactly do you have in mind? Using an int[](byte[])-array from an instance of your Image-object as a texture instead of loading it from somewhere else?