After much wrangling, bug solving and repeated profiling from the earlier thread I've made what I thought would be some major speed ups - Some accurate view & light culling as well as switching everything to use indexed vertex arrays.

Unfortunatly i've not actually seen *any* difference in speed After the latest bout I found that its not my raw memory copying, or sheer volume of calculations (not now, at any rate) but just the actual rendering - the calls to glDrawElements are just too damn slow.

On a whim I reduced the viewport size, and lo! the fps shot right up to ~75fps once again. So on my GeForce2 GTS I seem to be fill limited at only seven lights I'd like others to give the app a quick whirl so i can see what kind of fps is common - my GeForce used to be pretty good, but by todays standards is probably lagging somewhat on raw fill rate.

App is here: http://studenti.lboro.ac.uk/~cojc5/Vecript/VecriptDist02-09-2003.zip

Readme includes instructions (simple!) to load and view the test scene. I've not included Jogl since that would add ~2Mb that people might already have. Tested on the latest nightly build of Jogl without a hitch, so you can set up your jogl jar & dll how ever you like it on your system.

All comments welcome And if anyones got any suggestions for general UI / usability i'm all ears..

Hi
 I just tried it, and got a nice big stack trace for ya here, I got what looked like 66fps roughly, Geforce 4 4200 Athlon xp 2100

HTH

Endolf

Thanks to everyone that gave it a try I guess I should explain about the lights - regular GL lighting isn't being used (well, one ambient is but that doesn't count) it's all done by building the light intensity up in the alpha buffer, before modulating this by the geometry.

Since this requires (per light!):

• Clear alpha buffer
  
• Load alpha buffer with light intensity
  
• Mask off shadow hulls and fins
  
• Modulate with scene geometry
  

Obviously this means that more lights need vastly more activity going on in the framebuffer And i've already reduced the geometry rendered per pass by limiting it to the objects within the light bounds.

I think that using the scissor test could gain me some speed by limiting the screen update to the lights bounds - how much fill rate this saves is another matter though.

Note that the test level is a pretty bad case - i'm profiling with the entire level in view, and most of the lights overlap by quite a bit.

Endolf: Thanks for the trace, it seems like the texture files arn't being found (no big deal really, I broke texturing while optimising). The textures loaded are controlled by a text file in ./Data/Textures/TestSet.txt - I stripped out a lot of the entries to reduce the redundant textures in the zip. You can either check the txt file and fix the entries (should be something like:
Detail            Detail.png
on every line. Perhaps I missed the file extensions on the second collumn?

Or you can just delete the entire contents of the file, textures arn't needed anyway. Did the app continue after these exceptions (should have done!) or did it die a death?

Well if you look at some of the profiler outputs from the other thread, you'll see some substancial decreases in the time spent in several key methods. I think i shifted my bottleneak from geometry to fill rate and didn't notice when it switched

Although if you know of a profiler that can give useful information about whats happening down the graphics pipeline i'm more than willing to (ab)use it

Well if you've got a mac you can just run the Open Graphics Profiler and it will tell you what you want to know. Intel used to make a rendering pipeline profiler some years back but I don't know if its still supported.

You would think people would be tripping over each other to sell this sort of thing considering the large number of game studios there are in the world.

FYI: I got around 21fps using W2K - GF4 Ti4600 - Dual Athlon MP1800+  (5% processor)

Peter