Marvin Fröhlich
|
 |
«
Posted
2006-09-22 19:47:25 » |
|
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.
|
|
|
|
|
Amos Wenger
|
 |
«
Reply #2 - Posted
2006-09-23 10:11:58 » |
|
It's really a good idea to renovate this quake3 level loader : it will provide an excellent testcase for the not-refilling-renderbins-each-frame performance improvement.
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
Games published by our own members! Check 'em out!
|
|
Marvin Fröhlich
|
 |
«
Reply #3 - Posted
2006-09-23 10:52:58 » |
|
It's really a good idea to renovate this quake3 level loader : it will provide an excellent testcase for the not-refilling-renderbins-each-frame performance improvement.
Exactly that is the plan  . The MultiCubeBenchmark will probably be a too small test (too few Atoms) to see the real effort of this modification (well, whan it is done). That's why I asked for it. Thanks for the links.
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #4 - Posted
2006-09-23 23:35:13 » |
|
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. Marvin
|
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #6 - Posted
2006-09-24 01:01:28 » |
|
First, great work Qudus! Good to see something useful coming out.
hehe  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  . with respect to the new display list stuff?
Thanks Marvin
|
|
|
|
cylab
|
 |
«
Reply #7 - Posted
2006-09-24 19:26:28 » |
|
...(and it seems like the textures are not properly loaded. They look rather odd.)...
Could this be the same problem in the MD3 model loader demo by java cool dude? BTW. there are a lot of broken links/dead ends in the demo and GSG section of the Xith website.
|
Mathias - I Know What [you] Did Last Summer!
|
|
|
Marvin Fröhlich
|
 |
«
Reply #8 - Posted
2006-09-24 19:47:44 » |
|
Yes. Looks like the same problem. 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. Marvin
|
|
|
|
cylab
|
 |
«
Reply #9 - Posted
2006-09-24 20:04:24 » |
|
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?
|
Mathias - I Know What [you] Did Last Summer!
|
|
|
Games published by our own members! Check 'em out!
|
|
hawkwind
Junior Devvie  
Java games rock!
|
 |
«
Reply #10 - Posted
2006-09-24 21:34:09 » |
|
Drop consideration of FileInputStream...
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.
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #11 - Posted
2006-09-24 22:17:52 » |
|
Drop consideration of FileInputStream...
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.
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #12 - Posted
2006-09-25 00:43:06 » |
|
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).
Marvin
|
|
|
|
c_lilian
Senior Devvie    Projects: 1
Java games will probably rock someday...
|
 |
«
Reply #13 - Posted
2006-09-25 05:52:57 » |
|
Drop consideration of FileInputStream...
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) Lilian 
|
|
|
|
Amos Wenger
|
 |
«
Reply #14 - Posted
2006-09-25 16:34:46 » |
|
...(and it seems like the textures are not properly loaded. They look rather odd.)...
Could this be the same problem in the MD3 model loader demo by java cool dude? BTW. there are a lot of broken links/dead ends in the demo and GSG section of the Xith website. (Probably same problem as with the MD3 loader) Wha wha what ? Lots of broken-dead-vampire links on Xith.org  ? Tell me where.. and I'll kill them. 
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
Amos Wenger
|
 |
«
Reply #15 - Posted
2006-09-25 16:39:20 » |
|
Wha wha what ? Lots of broken-dead-vampire links on Xith.org  ? Tell me where.. and I'll kill them.  Ahah now I see in the Demos page : these links are a pain in the ass. When 1.0 comes out I'll replace all of them by a single JNLP to the xith3d demo started (thanks Marvin).
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
Amos Wenger
|
 |
«
Reply #16 - Posted
2006-09-25 16:56:16 » |
|
View does not work very well here : i get a dX = -1 dY = -3 when I don't even move my mouse.. HIAL problem I guess..
But it runs at a smoothe 40FPS
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
Marvin Fröhlich
|
 |
«
Reply #17 - Posted
2006-09-25 17:30:44 » |
|
View does not work very well here : i get a dX = -1 dY = -3 when 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). But it runs at a smoothe 40FPS
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. Marvin
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #18 - Posted
2006-09-25 17:48:30 » |
|
Cool!. After I switched to STATIC Shape3Ds in the BSPConverter it runs about 16% faster and absolutely smooth  .
|
|
|
|
kevglass
|
 |
«
Reply #19 - Posted
2006-09-25 17:49:54 » |
|
What sort of hardware are you running on?
Kev
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #20 - Posted
2006-09-25 17:55:07 » |
|
What sort of hardware are you running on?
Athlon64 3000+, 1GB Dual Channel RAM, Radeon 9800 Pro 128MB.
|
|
|
|
renanse
Junior Devvie   Exp: 14 years
Intelligence is light to a dark world.
|
 |
«
Reply #21 - Posted
2006-09-25 22:20:31 » |
|
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.
|
Renanse (ruh-NON-say)
|
|
|
Marvin Fröhlich
|
 |
«
Reply #22 - Posted
2006-09-25 22:24:40 » |
|
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. Enjoy the demo  Marvin
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #23 - Posted
2006-09-25 22:25:54 » |
|
Cool, let us know where to get the latest when it's ready cause I'd love to redo the benchmarks.
Checkout your CVS. It's just become ready  . Marvin
|
|
|
|
kevglass
|
 |
«
Reply #24 - Posted
2006-09-25 22:28:14 » |
|
ust 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
Is that right? Xith out performs Java3D? And JME has less than half the framerate?  Kev
|
|
|
|
renanse
Junior Devvie   Exp: 14 years
Intelligence is light to a dark world.
|
 |
«
Reply #25 - Posted
2006-09-25 22:33:41 » |
|
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.
|
Renanse (ruh-NON-say)
|
|
|
kevglass
|
 |
«
Reply #26 - Posted
2006-09-25 22:36:57 » |
|
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?
Probably not a fair comparison if so.
Kev
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #27 - Posted
2006-09-25 22:40:41 » |
|
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)? Marvin
|
|
|
|
Marvin Fröhlich
|
 |
«
Reply #28 - Posted
2006-09-25 22:42:47 » |
|
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?
Marvin
|
|
|
|
kevglass
|
 |
«
Reply #29 - Posted
2006-09-25 22:46:40 » |
|
Looking at the numbers you were quoting compared to Renanse's I'm not convinced which version would be faster. It would seem Tom's was quicker. However, I think it'd be a clearer comparison of scenegraph core performance if the code bases were essentially pretty similar. The webstarts and related resources were referenced in this thread: http://www.java-gaming.org/forums/index.php?topic=11748.60Kev
|
|
|
|
|