I remember when I first came to xith there was a Quake3 level loader (with example) available. I think this would be an excellent test for the current performance of the engine. Unfortunately I cannot find it. Does anyone know where it is or if it even still exists?

Marvin

EDIT: I changed the thread title to better fit the topic, that's talked about here.

I remember when I first came to xith there was a Quake3 level loader (with example) available. I think this would be an excellent test for the current performance of the engine. Unfortunately I cannot find it. Does anyone know where it is or if it even still exists?

I've made a first "naive" port of the loader agains the current CVS. Have a look at org.xith3d.test.loaders.BSPLoaderTest .

I'll check the whole code to make it better and more intuively usable. It uses e.g. a RandomAccessFile, which is not the most high performance one when you're just reading a file. Maybe I can switch to a FileInputStream.

And the whole loader is hardcodedly linked with the Xith collision system, which will certainly make it quite slow. Maybe this is the first case, where we need JOODE integration in xith-tk.

Yes, of course. But first I need to clean-up the loader (and it seems like the textures are not properly loaded. They look rather odd.). And the recently planned RenderBin concerned optimizations should be done before. We wan't to gather as much "points" as possible, don't we .

BTW. there are a lot of broken links/dead ends in the demo and GSG section of the Xith website.

The GSG is totally outdated. You should not use it at all.

I know, but neverless the links should not be broken on the website. As well as the library link of the java cool dudes should not point to the outdated forum, since there is only a maintainance site present.

Also the whole xith3d website is unstable (broken images) and slow from time to time. Where is it hosted?

today/monday I will drop a copy of my fast NIO based file readers. For me buffer I?O from File handle is substantially faster.

Thanks for the hint. But I've already dropped this consideration, but for some other reason. The bsp file needs RandomAccess! In the first bytes there is some kind of dictionary, where all the byte offsets are listed. When you want to read the vertex data for example, you'll have to seek to the position listed in this dictionary. This is only possible in RandomAccessFile.

The BSPLoader is quite clean now. The only remaining problem is the one with the Textures. Amos could you have a look at them, please? I think, you're a bit more familiar with the TextureLoader than I am.

But ieven if I detached the scene from the collision system, the whole thing isn't very efficient. Have a look at org.xith3d.test.loaders.BSPLoaderTest (you can now move around with the mouse and keyboard).

today/monday I will drop a copy of my fast NIO based file readers. For me buffer I?O from File handle is substantially faster.

Thanks for the hint. But I've already dropped this consideration, but for some other reason. The bsp file needs RandomAccess! In the first bytes there is some kind of dictionary, where all the byte offsets are listed. When you want to read the vertex data for example, you'll have to seek to the position listed in this dictionary. This is only possible in RandomAccessFile.

Just a thought, what about NIO and memory mapped files ?

(oh by the way, thanks for adding so many improvements to Xith, I can't wait to test them... if only I had more time)

View does not work very well here : i get adX = -1dY = -3when I don't even move my mouse.. HIAL problem I guess..

Yes. It is a HIAL problem. I fixed HIAL yesterday, since the exclisive mouse for AWT mouse wasn't working properly (after the Robot repositioned the mouse the moved event was fired, which caused an infinite loop). Well, I ran on a problem: In non-fullscreen mode the component.getLocationOnScreen() method returns wrong values, which I fixed by constant +1 for x and +3 for y. I guess, this is window manager / theme dependand. And your problem ensure me in this suspection. I'll try to figure out a way to automatically calculate these values.

But there shouldn't be such a problem in fullscreen mode (undecorated frame).

Well, it runs absolutely smooth an my machine (50 - 250 FPS), when you're movin inside the same room (cluster). But when you're passing the borderline between two clusters, the movement stucks for up to a second or so.

What about the textures. Do you have a clue for them? There're two TODOs in the BSPConverter class. This is where the textures are loaded. I guess, I've just used a wrong parameter. The old (now incompatible) way the textures were loaded is still there (commented) so you can compare them. Please have a look at it, and tell me, if you can do something about it.

Cool, let us know where to get the latest when it's ready cause I'd love to redo the benchmarks. Currently, just pulling up the Java3d, Xith and jME versions I have on at 800x600 my work machine (P4 3.2 with a 9800 XT card) gets me 343, 345 and 165 FPS respectively after a 30 sec burn-in at the initial spawn point.

I found the problem with the textures . It was a problem with the parameters, but with the filename parameter . The textures are expected to be in a certain folder structure, which was not the case. So I searched the filenames in the bsp file and recreated the folder structure. e voila... the level looks just great, even if there're still some textures missing. the biggest missing texture is the sky. Maybe someone has this texture or another matching one, then he could commit it to CVS please.

I proceeded to code the org.xith3d.util.EgoInputAdapter and now I find it could be useful for many people writing FPS shooters. Please have a look at it and tell me, if there's anything missing to have a common tool for this purpose.

Sigh, my brain is on ice in this freezing cold office... it's jme: 345 java3d: 343 xith: 165... Java3d does better than jME though if you go to the top of the scene and look down at everything at once.

I'll have a look tomorrow at CVS when I thaw out... Memory footprint, CPU usage and FPS are what I look at for the testing.

Just to check, the version of the BSP viewer that Qudus checked in is based from David Yazel's original stuff right? It's not based off the Tom's benchmark code which is almost certainly what Renanse is running?

Just to check, the version of the BSP viewer that Qudos checked in is based from David Yazel's original stuff right? It's not based off the Tom's benchmark code which is almost certainly what Renanse is running?

Probably not a fair comparison if so.

Yes, it's based on David's code. Is the Tom's benchmark code faster (I mean after the level has loaded)?

About the missing textures. I tried another map and basically there were the same textures missing. It seems like we need some kind of "Quake 3 map kit", where all the base textures are located in. Or if I remember right, they were in the base folder in a Quake 3 installation. Are they freely available somewhere?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org