Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5 6
  ignore  |  Print  
  Quake3 level loader - Benchmarks  (Read 30388 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #90 - Posted 2006-09-30 13:16:57 »

OK ok I'm not gonna run the old path one more time but phew I think "optimizations" had made the FPS go down..

Apparently the vecmath_kh library isn't any better.. I don't get perf boost when I use it.

What about the GC concerning Iterators? Has it become better? I converted several advanced-loops to classic ones. This should at least have effected this kind of GC.
Don't know, will re-bench it soon.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #91 - Posted 2006-09-30 13:17:10 »

Perf boost isn't important in that context... what matter is reducing full GC pauses as they are visible (and annoying) for the player...

Profiling and cleaning up vecmaths was my first task when I selected Xith for my game. now I have full gcs only on level loading, which isn't annoying at all

Well, however, I wouldn't mind gaining 50% frame rate : that would give much time for everything else (game logic and music especially)

Are you using HK's vecmath lib? Have you modified it (except adding the TexCoord4f class like I had to do)? If you did, could you please commit it?

Marvin
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #92 - Posted 2006-09-30 14:07:28 »


Are you using HK's vecmath lib? Have you modified it (except adding the TexCoord4f class like I had to do)? If you did, could you please commit it?

Marvin

No, I've patched the official vecmaths. But i can't commit it as the updates aren't thread safe and thus, not compatible with java3d.

Lilian Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #93 - Posted 2006-09-30 14:59:14 »


Are you using HK's vecmath lib? Have you modified it (except adding the TexCoord4f class like I had to do)? If you did, could you please commit it?

Marvin

No, I've patched the official vecmaths. But i can't commit it as the updates aren't thread safe and thus, not compatible with java3d.

Lilian Smiley
What major changes did you do ? I'm actually trying to have a GC-correct vecmath version from Sun sources. (Kenji Hiranabe's one does not use Sun's sources, right?)

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #94 - Posted 2006-09-30 16:03:28 »

Please also see if you can get the color blending working on the flames. Smiley

Renanse  (ruh-NON-say)
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #95 - Posted 2006-09-30 16:26:42 »

Please also see if you can get the color blending working on the flames. Smiley
yeah, yeah one thing at a time.

wrong atom sorting, I bet. c_lilian, could your quicksort change have broken something ? not accusing you just trying to gather info about that issue. did you test extensively your patch ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #96 - Posted 2006-09-30 16:37:40 »

well, it's rather straightforward, so it shouldn't be a problem... the algorithm is direct from sir Gosling...

I'll have a look at it again tomorrow just in case.

Lilian Smiley

Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #97 - Posted 2006-09-30 16:40:36 »

well, it's rather straightforward, so it shouldn't be a problem... the algorithm is direct from sir Gosling...

I really hope it has nothing to do with the fact, that I removed the RenderBucket class.But I really believe it hasn't. It should just be more efficient.

Marvin
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #98 - Posted 2006-10-01 16:39:56 »

well, it's rather straightforward, so it shouldn't be a problem... the algorithm is direct from sir Gosling...

I really hope it has nothing to do with the fact, that I removed the RenderBucket class.But I really believe it hasn't. It should just be more efficient.

Marvin
What was it used to ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #99 - Posted 2006-10-01 16:47:38 »

What was it used to ?

I don't know the initial thought behind it. But what remained is the class RenderBucket, of which any instance held an instance of RenderAtom. And instead of directly using the RenderAtom (with the additional attributes of RenderBucket) a RenderBucket instance was used accessing the RenderAtom instance through it.

So the RenderBucket class was simply useless as far as I understood it.

Marvin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #100 - Posted 2006-10-01 16:51:05 »

I've just converted the "old" flight path to the new format and recommited it.

Marvin
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #101 - Posted 2006-10-01 17:04:27 »

Great, that will make future benchmark results a lot easier to do comparisons with.

Renanse  (ruh-NON-say)
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #102 - Posted 2006-10-01 17:07:56 »

@renanse: please look into your PMs.
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #103 - Posted 2006-10-01 17:47:49 »

nod, I'll get that flight file changed here shortly.

In the meantime, could you apply these two code changes?  They will bring your visual look up to par with the other versions of the test (aside from the flame transparency issue.)

In com.xith3d.loaders.texture.TextureLoader's constructor, change the last line to:
1  
2  
3  
      this.defectTexture.setImage(0, new ImageComponent2D(
            ImageComponent.RGB, 2, 2, new byte[] { 127, 127, 127,  127, 127, 127,
                        127, 127, 127, 127, 127, 127}));



In org.xith3d.loaders.bsp.BSPConverter.convertTextures(String[]) at line 353, add the following else to if ((textures == TextureLoader.getInstance().getDefectTexture()):
1  
2  
3  
            } else {
                textures[i].setMagFilter(Texture.BASE_LEVEL_LINEAR);
                textures[i].setMinFilter(Texture.MULTI_LEVEL_LINEAR);

Renanse  (ruh-NON-say)
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #104 - Posted 2006-10-01 17:59:02 »

Thanks for attaching the flight path Smiley.

I've changed an committed the BSPConverter as you said. But I didn't change the TextureLoader in that way, since just gray is not a good defect texture. You won't possibly see, that it's a defect one. And it won't do anything to the performance.

Maybe we can find an alternative texture to use for the sky, if you can't get the original Q3 base texture.

Marvin
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #105 - Posted 2006-10-01 18:20:04 »

Grey is what everyone else uses and you see that default all over the place (for example, several lightmaps)  At least try it and do a comparison.

Renanse  (ruh-NON-say)
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #106 - Posted 2006-10-01 18:57:42 »

Grey is what everyone else uses and you see that default all over the place (for example, several lightmaps)  At least try it and do a comparison.

Well, of course I tried it and found it a bit nicer. But I think better seeing that a texture is missing somewhere is better than having a nicer scene and maybe not recognizing that a texture is missing.

Marvin
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #107 - Posted 2006-10-02 03:26:26 »

Latest version of your code seems to have all of the textures upside down.   Huh

The better news though...  Did some detective work on my own and discovered your transparency issue...  as I thought previously, the draw order is wrong.  If you draw your opaque bin before the transparent bin (as it should be) your problems go away.  Simply swap the two lines in CanvasPeerImpl.renderMain(RenderBinProvider) so they look like this:

1  
2  
        drawBin(binProvider.getOpaqueBin());
        drawBin(binProvider.getTransparentBin());


Make sure to do it in lwjgl and jsr231.  Now you can't say us jME guys never do anything nice.  Wink

Renanse  (ruh-NON-say)
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #108 - Posted 2006-10-02 03:35:45 »

Latest version of your code seems to have all of the textures upside down.   Huh

The better news though...  Did some detective work on my own and discovered your transparency issue...  as I thought previously, the draw order is wrong.  If you draw your opaque bin before the transparent bin (as it should be) your problems go away.  Simply swap the two lines in CanvasPeerImpl.renderMain(RenderBinProvider) so they look like this:

1  
2  
        drawBin(binProvider.getOpaqueBin());
        drawBin(binProvider.getTransparentBin());


Make sure to do it in lwjgl and jsr231.  Now you can't say us jME guys never do anything nice.  Wink

I'm very impressed. Thenk you very, very much Grin It did the trick.

Marvin
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #109 - Posted 2006-10-02 03:43:39 »

Latest version of your code seems to have all of the textures upside down.   Huh

Hmm... No, just the flames are upside down. Let's wait for Amos. He'll certainly have an answer... I'm too tired now.

Marvin
Offline cylab

JGO Ninja


Medals: 50



« Reply #110 - Posted 2006-10-02 11:26:57 »

Latest version of your code seems to have all of the textures upside down.   Huh
Hmm... No, just the flames are upside down. Let's wait for Amos. He'll certainly have an answer... I'm too tired now.

It seems renanse is right and all textures are upside down...  Undecided

Mathias - I Know What [you] Did Last Summer!
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #111 - Posted 2006-10-02 12:58:52 »

I'll be putting together the final performance tests and webstarts tonight or maybe tomorrow.  Is there anything further coming from the xith team I should be aware of (aside from bug fixes)?

Renanse  (ruh-NON-say)
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #112 - Posted 2006-10-02 13:02:08 »

btw, regarding textures being upside down...   Q3 maps seem to rely on *not* flipping the textures, which is different than most things out there.  I couldn't find a flag in Xith to tell the texture loading process to flip/not flip textures, but maybe you guys know better where to look.  That would be my first guess as to where something might be broken....  That or somebody hardcoded to always flip.  Smiley

Renanse  (ruh-NON-say)
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #113 - Posted 2006-10-02 15:02:20 »

I'll be putting together the final performance tests and webstarts tonight or maybe tomorrow.  Is there anything further coming from the xith team I should be aware of (aside from bug fixes)?

It would be very nice if you'd wait until wednesday. There's a huge performance regarding update I'm currently working on. It's more work than I expected and I'll need this day and tomorrow. Is this ok for you?

Marvin
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #114 - Posted 2006-10-02 15:37:24 »

Sure, just so long as it doesn't drag out forever. Wink

Renanse  (ruh-NON-say)
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #115 - Posted 2006-10-02 16:39:29 »

Latest version of your code seems to have all of the textures upside down.   Huh

The better news though...  Did some detective work on my own and discovered your transparency issue...  as I thought previously, the draw order is wrong.  If you draw your opaque bin before the transparent bin (as it should be) your problems go away.  Simply swap the two lines in CanvasPeerImpl.renderMain(RenderBinProvider) so they look like this:

1  
2  
        drawBin(binProvider.getOpaqueBin());
        drawBin(binProvider.getTransparentBin());


Make sure to do it in lwjgl and jsr231.  Now you can't say us jME guys never do anything nice.  Wink
Thank you very, very much.

Yeah I'm impressed, you jME guys often do some nice things.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #116 - Posted 2006-10-03 15:21:53 »

The Textures are now flipped top-up Smiley.

I douplicated all the getTexture() and createTexture() methods of the TextureLoader class and added a parameter to the duplicates telling, if the image is to be flipped. The default is FLIPPED_VERTICALLY, like OpenGL needs it. I had to use an enum instead of a simple boolean, since otherwise we had ambiguous interfaces.

Well... enjoy Grin

Marvin
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #117 - Posted 2006-10-03 16:14:18 »

The Textures are now flipped top-up Smiley.

I douplicated all the getTexture() and createTexture() methods of the TextureLoader class and added a parameter to the duplicates telling, if the image is to be flipped. The default is FLIPPED_VERTICALLY, like OpenGL needs it. I had to use an enum instead of a simple boolean, since otherwise we had ambiguous interfaces.

Well... enjoy Grin

Marvin
Good job !

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #118 - Posted 2006-10-03 16:49:49 »

Great.  I also contacted the author of the quake map we are using and got a better understanding of the missing textures.  Basically they are all defined in .shader files.  I'll be writing a .shader interpreter for jME at some point (hopefully this week) which you are welcome to port across to Xith.

Renanse  (ruh-NON-say)
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #119 - Posted 2006-10-03 16:52:59 »

Great.  I also contacted the author of the quake map we are using and got a better understanding of the missing textures.  Basically they are all defined in .shader files.

Hmm... I don't think this is true for all of them. For some it might be. But most of them reside in the base folder of the Quake3 install path (well known by us old Quake3 gamers). They're reused by many Q3 maps just as in this case.

I'll be writing a .shader interpreter for jME at some point (hopefully this week) which you are welcome to port across to Xith.

Thanks Smiley.

Marvin
Pages: 1 2 3 [4] 5 6
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (37 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (42 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (61 views)
2014-09-21 02:42:18

BurntPizza (30 views)
2014-09-21 01:30:30

moogie (36 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (52 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!