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?

Are you limiting the hw renderer's featureset because the current jPCT is designed as a software renderer or is it a design goal that both hw and sw renderers have identical features?

A little bit of both... :wink: jPCT's basic idea was to provide fast software rendering. I never even thought about hardware support before LWJGL surfaced and even then, it took me some time (and some requests by others...) to convince myself to try it. I wanted to stay compatible with 1.1. and be able to run jPCT in applets. Applets are quite pissy about imported classes that aren't there even if you don't use them, so you have to hide Java2 class-usage from 1.1 by using the plugin-approach the FrameBuffer and the IRenderer are offering. This limits the knowledge about LJWGL/OpenGL to the GLRenderer and it requires some "tricks" to get things working. Blitting and RGBScaling are examples of this. So even if it's possible to add hardware features regardless of the software renderer, the current design makes it difficult to do that in a convenient way sometimes. On the other hand, i really don't want to change the API everytime and force people to refactor their applications every month. That's something i really hate to do myself, so i'm trying to avoid it...
jPCT's hardware support is quite separated from the rest of the engine. If it weren't, i would have to maintain two completely different rendering pipelines making the code/API a mess and the size would grow. That's the reason why jPCT isn't a polygon pusher...hardware T&L is used somehow, but not to an extent. HW and SW are basically using the same pipeline until drawing of the actual polygons starts.
And finally, i want sw and hw to behave as equal as possible. That's because i think that it's usefull for pushing 3D into the Java-world, like it was usefull for Unreal to offer a software mode. Aside from javagaming.org and similar communities, 3D in Java is not taking place IMO, so i think it's important to make is accessible for as much people as possible to show that it could be done and to show them how they may benefit from using it. When this is achieved, you can think about adding all the fancy features...but maybe in another engine...(jPCT2.0+  :wink: )

You may ignore the problem...the culling won't be performed using the octree nodes then but the objects' bounding boxes. If we aren't talking about zillions of objects here, this should be fast enough...
If not, you may have a look at Object3D.translateMesh(). This does a physical translation of the object in object space, so you may setup the translation for each object, call translateMesh() for each and merge them afterwards. This way, you should get one large object with the cubes at the correct positions.

Hope this helps.