(tearing hair out while looking at fps count)

[NexusOne]

With all the problems I'm having in making a game, many of which i've posted about, I have to add more and more code to my game to solve them, which means it has more and more to do every time it goes through the display loop.. now the fps is down to an unbearable 11, yes that's right 11, for a world of about 50,000 polygons with lighting, about 10,000 of which are textured (almost all opaque). I'm using display lists wherever possible, in fact i would guess about 95% of my world is already drawn through display lists. I'm calling glBegin and glEnd only where necessary, texturing and untexturing only where necessary.. what else can I do? I've heard of something called index buffering and something call vertex buffering, but aren't display lists better?

[erikd]

Do you know what your bottleneck is (did you profile your code)? I mean, maybe display lists aren't your problem.

[Orangy Tang]

Yeah, you've got to pin down the bottleneck before you can start looking at optimising it.

The main thing to check is to see if you're geometry or fill limited. Try dropping the resolution to a fraction of what you're using at the moment, if that causes an increase then you're fill limited. If not then chances are you're geometry limited.

Then you can try and narrow it down further. If fill limited it might be caused by lots of overdraw. Or it might be lots of blending that mean you're hitting memory bandwidth problems.

If geometry limited then it could be that you've got a complex vertex shader slowing things down (or indeed a software vertex shader?) or your view culling isn't working as well as you think.

Games published by our own members! Check 'em out!

[NexusOne]

OK, I tried some tests.  When I took off vertex-lighting, I got no performance gain at all. When I took off all non-textured geometry, which makes up 80% or so of the world, I got only a slight increase. Then I tried not texturing the remaining objects either, and I got a 40% increase in performance. Finally I put everything back to normal but made the window 4 times smaller, and the fps rose 110%. So seems as if it is fill-limited, but I still am not sure this is the case, since the geometry of my world is pretty straightforward, I have a terrain and objects such as trees on the terrain, so I don't think there could be much overdraw. Interestingly transparent-textured objects seem to take as long to render as opaque-non-textured objects that have at least 100 times more polygons, and although I don't have many transparent objects in my world I do have 10,000 or so textured ones. I would guess texturing and geometry are both bottlenecks.

[princec]

So what card is this running on, anyway?

Cas

[Orangy Tang]

Possibly a silly question, but have you checked GL_RENDERER and GL_VENDOR to make sure you're not getting Microsofts software renderer for some reason?

[Yuri Vl. Gushchin]

In some cases also buffer format you are using slows down a lot: say, GeF 440 Go with 1600x1200, 32 bpp, 16 bit depth + 8 bit stencil buffer in some situations gives really slow performance (when stencil tests enabled, for ex.)

So, can you pls tell us resolution, color depth, buffer format?

And also the point - do you have VSYNC swap buffers synchronization turned on?

Yuri

[NexusOne]

I'm using XP, which I don't think has its own renderer, on a Radeon 7500 card, with a 1024 x 768 resolution and 32-bit color set on the monitor (does that matter?)... but how do I check my stencil buffer format? And sry but what is VSYNC swap buffers synchronization?

[Yuri Vl. Gushchin]

with a 1024 x 768 resolution and 32-bit color set on the monitor (does that matter?)

Definitely yes.

but how do I check my stencil buffer format?

Good question. In my case I have modified version of DefaultGLCapabilitiesChooser with DEBUG = true (check the source). If you don't want to rebuild JOGL, just make your own copy of GLCapabilitiesChooser similar to DefaultGLCapabilitiesChooser and pass it to JOGL when creating GLCanvas.

And sry but what is VSYNC swap buffers synchronization?

This functionality, if enabled, causes every call to SwapBuffers [performed internelly by JOGL just after display(...) call] to wait until next vertical retrace, so you can conly see complete frames on your screen.

Now imagine you have flat panel w/ 60Hz refresh and your app renders 58 fps. With VSYNC enabled you get exactly 30 fps just because of rendering is too slow to fit one frame period (1/60 s) and you are missing every second frame.

Yuri