Attached, although it’s just the flight you had checked into cvs. 
FYI, today at work I discovered a couple things we were doing more often then needed in our scenegraph related to static objects and also in our texture state system which, when corrected, had a fairly dramatic effect on jme’s showing in this test. The average fps I’m getting on the flythrough is now around 310 or so!
Btw, with the gc fixes to the new xith test I talked about making in the other thread, the new xith is getting about 150 on the new path (the latest in xith-tk), vs 146 before the gc fixes. Before you panic, the 310 I mentioned in the previous post is using the old flight path, which was less intense.
What were these ? All optimizations interest me.
hum… Marvin, did you change the flight path ?
Yes, sorry. I switched from Quad4f to Matrix3f to get rid of these lazy hicks. You can download the old path from remanses test result post and convert the quad4f lines to Matrix3f ones.
Read a line like this:
read the three lines and convert the the Quad4f to a Matrix3f. Then write the block into the output file:
This way you can convert the old path to the new file format. I would do that for you, if I could compile the source, which I cannot do at the moment, since I’m currently doing the optimizations ;).
Marvin
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.
btw. When you’ve converted the “old” flight path please give it a good name like “benchmark-2006-09-29.cflt” and commit it to CVS. Additionally please PM remanse, so that he can reattach it to the test results post. OK?
Marvin
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)
Lilian
Don’t know, will re-bench it soon.
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
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?)
Please also see if you can get the color blending working on the flames.
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 ?
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
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 ?
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