jPCT benchmark?

[fireside]

I put an Nvidia 7600 gt in my system yesterday and the car program went from 8 frames to 90. I had an onboard Nvidia 6100, which actually is still quite a bit better than an onboard intel chip.  That's always been a problem with computers, there's such a huge difference in game speed depending on the hardware.  I prefer to write to low end hardware myself since I'm an amateur and I need every eyeball I can get to even get someone to play them, but a few of the games I've been playing were getting too much like slide shows.  I'll still be able to switch sockets and test with the 6100 easily.

As far as the tests go, those are all respectable scores so I think it says a lot for java as a gaming platform.  When you consider ease of use and ease of making an internet game, plus complete cross platform without recompile, it's hard to beat.

[C3R14L.K1L4]

I'm very happy to see this jump on jpct. Some months ago I studied almost all 3D game engines / APIs in java (for my AI project) and got divided between jpct and jme.
For the first one I had the impression of simplicity but at the same time of missing features, when compared to jme. I also had the impression jme was faster but seeing this now... it's always nice to know the API you know the most is improving a lot.

I just did not understood this compiled thingy...
I've played with very detailed models in jpct and saw java's process cpu go way up... yeah, the engine was doing some kind of hidden surface removal in software (else the java's process was stalled quite probably at some SwapBuffers() or glFlush() methods) so what does this Model3D.compile() do, exactly?

[EgonOlsen]

I just did not understood this compiled thingy...
I've played with very detailed models in jpct and saw java's process cpu go way up... yeah, the engine was doing some kind of hidden surface removal in software (else the java's process was stalled quite probably at some SwapBuffers() or glFlush() methods) so what does this Model3D.compile() do, exactly?

It restructures the Object3D for optimized rendering and, depending on the compile-mode, puts the result into vertex arrays or display lists. As long as you are not artificially limiting the frame rate by using a sleep or at least Vsync, any engine will consume 100% of at least one CPU because it will pump out data as fast as possible. It's a myth that the cpu sits there doing nothing while the gpu does all the work.

[C3R14L.K1L4]

It restructures the Object3D for optimized rendering and, depending on the compile-mode, puts the result into vertex arrays or display lists.

Humm... I thought that was done already...
Then it's obviously that caching the geometry on the gpu (or using DLs which also stores more data and optimizes it) is faster than before, as the api was sending the commands in realtime

I've coded in OpenGL before and I can tell (by personal experience, using nVidia drivers ) that DLs are faster than compiled vertex arrays and vertex buffer objects (VBOs), but that depends on the driver. As you know, a DL is created once and can't be changed anymore, so the driver can optimize it's data and command as it sees best. In the extreme, it can even issue the gl commands in a total different order.

As long as you are not artificially limiting the frame rate by using a sleep or at least Vsync, any engine will consume 100% of at least one CPU because it will pump out data as fast as possible. It's a myth that the cpu sits there doing nothing while the gpu does all the work.

I forgot that detail... OOPS

[EgonOlsen]

Humm... I thought that was done already...

Not exactly. The former/default pipeline is a hardware/software hybrid pipeline. It does these things, but at runtime and on the CPU.

I've coded in OpenGL before and I can tell (by personal experience, using nVidia drivers ) that DLs are faster than compiled vertex arrays and vertex buffer objects (VBOs), but that depends on the driver. As you know, a DL is created once and can't be changed anymore, so the driver can optimize it's data and command as it sees best. In the extreme, it can even issue the gl commands in a total different order.

I'm using DL for static geometry and VA for dynamic. There's no support for VBO yet. I'm using indexed or not indexed geometry depending on what you choose when compiling the object. Default is indexed for static and not indexed for dynamic.