Ahm I see. Anyway, is it possible that display lists are slower than immediate mode/vertex arrays ???
Yeah sure, not is fault for sure. “Say Thanks -Thanks -Thanks who ? -Thanks renanse”.
Anyway, would be interesting to be able to run the test on others computers, just to see if the difference is so great (not pretending anything here).
I can understand the frustration, but honestly, NCsoft doesn’t care if Xith or jME looks better to the community, they just wanted, and got, a Java game base to build from. 
Anyhow, as has been pointed out, the code I am using to run Xith/Q3 is the same code I was using on the last benchmark, just tweaked (very quickly) by me to run with the changes in the latest cvs… things like how you guys split TextureLoader up into utility classes and locator classes, etc. Unless display lists “just happen” under the covers, I’m sure they aren’t turned on, and who knows what other things might need to be turned on in the test to make most optimal use of the engine. So, if someone could take the original joint test code from the beginning of this year and tune it to work with your latest xith changes, I’ll be happy to redo the stats as before (plus post web starts and source code if that’s desired.)
I suppose it depends how they’re being used. If the display lists get built incorrectly it could be rendering more of the scene that it used - i.e. preventing culling or something?
Or I suppose it’s possible there might have been some error in the display list code making it recreate every frame, or possibly killing a wierd driver implementation.
Or possibly, it’s just not Qudus’ latest cut of code - which turns out to be ultra fast! ;D
Never know until you benchmark and profile
Kev
Yeah, and that’s the worth of it : it’s nobody’s fault 
… :’( Anyway, thanks not bugging as easily as me.
Ah ok display lists aren’t turned on. Maybe FPS will go up then.
Well surely display lists implementation as now aren’t the most efficient solution, I bet. But it do work for now.
Cool… so, can any volunteers for updating the xith q3 test?
Sure, I’m giving it a try.
This image sum it up pretty well.
I had the display lists enabled, noticeable perf boost.
Great! Source?
On CVS, why ? ;D
com.xithtk packages and trb.timer ones.
You put the joint quake test in your main cvs? Sorry if I didn’t expect that. 
Ah, didn’t see xith-tk before.
Hey, nice job, definitely much faster, just a couple texture issues you noted before. Runs at about 242 FPS now.
edit: Let me know when you finish working on it and I’ll redo the full set of tests and put together web starts.
I’ve now updated the loader (in org.xith3d.loaders.bsp) to use renase’s texture code. The textures are fine now (apart from the missing ones) and lighting is better, since I took renase’s lightmap code.
I also took the setVisibility() code, which was slightly different (espeacially concerning usePVS parameter). Now I don’t see any reason, why my port should be slower than the other one. The only thing could be input or timer. Please have a look and tell me, if you see any differences in FPS (I don’t).
Marvin
EDIT: btw. These wyred key settings in Quake3Renderer are driving me mad ;).
Solved the problem. ;D
In non-fullscreen (decorated) mode the method getLocationOnScreen() of the Component class returns other values than it will do after the first rendered frame, which are the correct ones. So the method updateCenters() of the AWTMouse class needs to be called once more after the first frame. Another option is to call mouse.setExclusive(true) after the first frame.
Well, anyway, I’ve added a fix to the RenderLoop class, which calls updateCenters() for all registered, exclusive AWTMouse devices once exactly after the first frame. Now the mouse should work properly. Please tell me if it does for you, too.
Marvin
I have written a new utility called CameraFlight. It loads a camera flight previously recorded using the class CameraFlightRecorder (both in org.xith3d.util.view) and moves/rotates the View according to the loaded matrices and times.
I think this would be a good test to compare engines or optimizations. Since it is very important to have the exact same view positions to take FPS test, this is the best solution to be sure.
Take a look at BSPLoaderTest and find these lines (117 - 155):
switch (key)
{
case 120: // F9
if (flightRecorder == null)
{
flightRecorder = new CameraFlightRecorder(view, 100L);
this.addInterval( flightRecorder );
this.addIntervalListener( flightRecorder );
flightRecorder.startRecord(getGameTime(), "camflight.cflt");
}
else
{
flightRecorder.stopRecord();
this.removeIntervalListener( flightRecorder );
flightRecorder.kill();
flightRecorder = null;
}
break;
case 121: // F10
if (camFlight == null)
{
try
{
camFlight = new CameraFlight( "demo/levels/quake3/bdmq3duel5/camflight.cflt" );
camFlight.start( getGameTime() );
}
catch (IOException e)
{
e.printStackTrace();
}
}
else
{
camFlight = null;
}
break;
By pressing F9 you can record a new camera flight (press F9 again to finish). By pressing F10 you can replay a recorded one (in this case the one saved to demo/levels/quake3/bdmq3duel5/camflight.cflt) (press F10 again to get back mouse control).
It should be very straight forward to port the CameraFlight class to other engines to replay a flight recorded in xith.
On my machine this camera flight makes an average FPS of 96, which is printed to the console, when the flight is finished (and restarts from the beginning). This flight takes about a minute or so.
Unfortunately I currently have problems with the interpolation of the matrices (recorded one at 100ms), so I’m currently using uninterpolated flight. But this shouldn’t address the FPS too much, but just looks a bit ugly ;).
Maybe someone could help me with the interpolation. This is the code to be found in org.xith3d.util.CameraFlight:
// ip1 is the last interpolation point (matrix) and ip2 is the next one
float dt = (float)t0t - (float)t0i; // this is the time from the last interpolation point to the current time (between 0 and 100 ms)
float d;
for (int i = 0; i < 4; i++)
{
for (int j = 0; j < 4; j++)
{
d = ((ip2.matrix.getElement(i, j) - ip1.matrix.getElement(i, j)) * dt); // interpolated value for this element of the matrix
viewMatrix.setElement( i, j, ip1.matrix.getElement(i, j) + d );
}
}
view.getTransform().set( viewMatrix );
Thanks in advance.
Marvin
Average FPS : 22.
I deleted the com.xithtk packages. Your version now rules, Marvin.
Um, so then we’d have to report your new stuff to J3D and jME to be able to do a valid cross test?