PDA

View Full Version : glCallList fails to render



Trauma
04-20-2005, 10:37 PM
Greetings all.

Up until now, I've used display lists comfortably (including on my current hardware) with little trouble, but my newest project isn't behaving as expected. I'm modelling outdoor terrain which is broken up into several heightmaps (currently a 2x2 grid). Each heightmap is a seperate object with a load method that compiles a display list item (after initialising glfw and the window, of course) made of basic triangle strips (8450 triangles). The ID is stored within the object so it can be used when it comes time to rendering.

Tracing through the program, the height field certainly appears to successfully load, and consequently "draw" while defining the display list. But at render time, glCallList produces no visible output, and only non-display-list items appear on screen. The method correctly supplies the previously assigned ID (which is always >0), the item should definitely be in view and the display list has not been modified in the intervening time. Calling the original "draw" routine (instead of the display list) at this time provides exactly the desired results (except for being sluggish, obviously).

I'm wondering if there may be a known issue with display lists within glfw (nothing hinted on it's website), or when using a Radeon 9200SE (although display lists have worked well on it so far). The code in question almost seems too trivial to be the cause, which is another reason I suspect it is something beyond that.

The terrain class used to render properly on its own, but no longer does so now that I've incorporated it into a terrain manager class. I know this suggests the manager is at fault, but tracing throught the program, the code creating and calling the display lists is exactly the same and is being presented with exactly the same data. Previous experiments with much larger heightfields (about 33000 triangles) also have no problems. glIsError has nothing to report either.

Here is the DL creation code that follows loading the data in from file. The draw() function is little more than a series of (textured) GL_TRIANGLE_STRIPs. listID is the private variable for storing the display list ID...

...
glPushMatrix();
glLoadIdentity();
listID = glGenLists(1);
glNewList(listID,GL_COMPILE);
draw();
glEndList();
glPopMatrix();
...

Here's the render code (for what it's worth)...
void terrain::render()
{
glCallList(listID);
//draw(); // Renders as expected when this is uncommented
}

Any suggestions would be greatly appreciated.

Cheers.

ZbuffeR
04-21-2005, 12:50 AM
listID is the private variable for storing the display list ID Maybe too easy : are you sure that this private value is the same in the compile an in the render part ? print it.

Trauma
04-21-2005, 01:56 AM
Sorry - yeah it is the same one. I meant private to the class (which contains the named functions), not private to each function. Debugging during rendering shows that glCallList is being given the appropriate IDs for each of the heightmaps, it just doesn't seem to do anything with them. Frame rates are very high (compared to where they should be), suggesting its not even trying to render. All that is visible is the dinky animated md2 that is supposed to be standing on the terrain.