• Advertisement
Sign in to follow this  

SOLVED: Display Lists Don't Work On All PC's !?!

This topic is 3987 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a strange problem with display lists. I draw a textured polygon with lighting attributes in a display list. On some computers the rendering works fine when displaying the list, but on other computers none of the lighting effects work when displaying the list. I found on the machines where the DL doesnt display properly, if I render without the use of a DL everything works fine. (By the way it I have the same problem regardless of weather the polygon has a texure on it). Could anyone tell me how I fix this problem? Thanks. Here is the code examplifies the problem: // Setup Light 0 glLightfv(GL_LIGHT0, GL_AMBIENT, m_LightAmb); glLightfv(GL_LIGHT0, GL_DIFFUSE, m_LightDif); // Function to load DS { #define DBG_LIST 10 glNewList(DBG_LIST, GL_COMPILE); GLfloat MtrlAmbDif[4] = { 0.65f, 0.65f, 0.65f, 1.0f }; GLfloat MaterialSpec[4] = { 1.0f, 1.0f, 1.0f, 1.0f }; GLfloat MaterialShns[1] = { 228.0f }; glEnable(GL_LIGHT0); glEnable(GL_LIGHTING); glMaterialfv(GL_FRONT, GL_SPECULAR, MaterialSpec); glMaterialfv(GL_FRONT, GL_SHININESS, MaterialShns); glMaterialfv(GL_FRONT, GL_AMBIENT_AND_DIFFUSE, MtrlAmbDif); GLfloat X1 = 50.0f, X2 = 300.0f, Y1 = 50.0f, Y2 = 300.0f; glEnable(GL_TEXTURE_2D); glBindTexture(GL_TEXTURE_2D, m_OGL.m_Texture[TEX_WOOD]); glBegin(GL_POLYGON); glNormal3d(0.0, 0.0, 1.0); glTexCoord2f(0.0f, 0.0f); glVertex3f(X1, Y1, 24.0); glTexCoord2f(1.0f, 0.0f); glVertex3f(X2, Y1, 24.0); glTexCoord2f(1.0f, 1.0f); glVertex3f(X2, Y2, 24.0); glTexCoord2f(0.0f, 1.0f); glVertex3f(X1, Y2, 24.0); glEnd(); glDisable(GL_TEXTURE_2D); glDisable(GL_LIGHT0); glDisable(GL_LIGHTING); glEndList(); } // Another function to display DL, depending on glRotate ligthing will change (but doesnt on all machines). // ... glCallList etc etc etc // ... [Edited by - _Ducky on March 27, 2007 7:00:28 AM]

Share this post


Link to post
Share on other sites
Advertisement
Which graphics cards does this not run on? Looks fine to me from quickly skimming over it.

Share this post


Link to post
Share on other sites
Well both my computers have nVidia G-Force graphics cards, and it works fine on both of them. I tried it on another computer (quite high spec P4/2.8Ghz) which has no graphics card, just 'on board' graphics, and it doesnt work. Also tried it on a (low spec) laptop which had an 'ATI' sticker on the front, and it didn't work on it.

If your interested in seeing the actual application, its a pool game I wrote which can be downloaded from .(GONE).. The problem is the shading (lighting) on the balls doesn't work on all machines, on some the balls are just blobs of solid colour (plus the texture), the screen shots on the website show what the balls should look like.

[Edited by - _Ducky on June 24, 2007 5:31:40 PM]

Share this post


Link to post
Share on other sites
What about just letting openGL find a free list id for you
instead of you using id 10 all the time.

GLuint DBG_LIST = glGenLists(1);
glNewList(DBG_LIST, GL_COMPILE);

I am not completely sure about the underlying mechanism
but let us know if it works. Who knows, maybe id 10 is
reserved on that card.

Share this post


Link to post
Share on other sites
EDITED: To include tariqwaljis observation

Hmm, I'm not sure what the problem might be. But you probably shouldn't be making that many unnecessary state changes. I'm not sure though, so this is just a guess. How do you change the ball colour? By texture or material? Since looking at your current code it seems all the balls have the same colour, but in your screenshot they have different colours.
If you are applying the same material and texture to all balls, perhaps you should try only setting it once. For example:


// Function to load DS
{
GLuint DBG_LIST = glGenLists(1);
glNewList(DBG_LIST, GL_COMPILE);

GLfloat X1 = 50.0f, X2 = 300.0f, Y1 = 50.0f, Y2 = 300.0f;

glBegin(GL_POLYGON);
glNormal3d(0.0, 0.0, 1.0);
glTexCoord2f(0.0f, 0.0f); glVertex3f(X1, Y1, 24.0);
glTexCoord2f(1.0f, 0.0f); glVertex3f(X2, Y1, 24.0);
glTexCoord2f(1.0f, 1.0f); glVertex3f(X2, Y2, 24.0);
glTexCoord2f(0.0f, 1.0f); glVertex3f(X1, Y2, 24.0);
glEnd();

glEndList();
}




Then render:


GLfloat MtrlAmbDif[4] = { 0.65f, 0.65f, 0.65f, 1.0f };
GLfloat MaterialSpec[4] = { 1.0f, 1.0f, 1.0f, 1.0f };
GLfloat MaterialShns[1] = { 228.0f };

glEnable(GL_LIGHT0);
glEnable(GL_LIGHTING);

glMaterialfv(GL_FRONT, GL_SPECULAR, MaterialSpec);
glMaterialfv(GL_FRONT, GL_SHININESS, MaterialShns);
glMaterialfv(GL_FRONT, GL_AMBIENT_AND_DIFFUSE, MtrlAmbDif);

glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, m_OGL.m_Texture[TEX_WOOD]);

// Draw all balls with this material and texture
glCallList etc etc etc
...
...

glDisable(GL_TEXTURE_2D);
glDisable(GL_LIGHT0);
glDisable(GL_LIGHTING);





Don't know if it makes any difference though, might be worth a try however.

Share this post


Link to post
Share on other sites
Quote:
Original post by _Ducky
GLfloat MaterialShns[1] = { 228.0f };

glEnable(GL_LIGHT0);
glEnable(GL_LIGHTING);

glMaterialfv(GL_FRONT, GL_SPECULAR, MaterialSpec);
glMaterialfv(GL_FRONT, GL_SHININESS, MaterialShns);


I noticed that you're setting MaterialShns to 228, which is used in glMaterialfv(GL_FRONT, GL_SHININESS, MaterialShns). But GL_SHININESS only accept values from 0 to 128, and the default specular exponent is 0, so maybe (I haven't tried!) different card drivers interpret 228 differently, like one clamping it to 128 (shiny) and another keeping the default (not shiny).

See glMaterial for reference. There should also be some documentation for how non-accepted values are treated, anyone know of some?

Share this post


Link to post
Share on other sites
Thanks so much for the replies.

Omid Ghavami

Yes the balls colour is determined by the texture not the material, the material properties are the same for all balls. Therefore I'm as you say I don't need the glMaterialfv calls in the display list. I create 4 DL's one for each ball colour (4 different textures). I will take those glMaterialfv calls out the DL, (my first version of this app I did change material properties for each ball so therefore I think I've left in the calls mistakenly).

tariqwalji

Good point I will create the list ID's with glGenLists.

Dim_Yimma_H

GL_SHININESS. Thanks for pointing out the fact that my value is invalid! I will change it to an valid value (0-128). This sounds like a very likely cause to my problem!!

---

I will make the amendments and post back here weather it worked or not, I'm am quite hopefull! Thanks again. (It'll be Monday when I post back, because that will be the soonist I'll get to make the fixes on the non-working machine).

Share this post


Link to post
Share on other sites
yes, it all works fine now! Thanks all! I implemented all suggestion/corrections, the one that was causing the shading problem was the GL_SHININESS value.

Share this post


Link to post
Share on other sites
Good to hear that it was solvable. In a way, it's a relief that the problem actually was because of an unaccepted value, it feels more alright if different drivers behave inconsistently then. Otherwise, it would've been very close to seeming like a DLL bug!

Share this post


Link to post
Share on other sites
Quote:
Original post by Dim_Yimma_H
See glMaterial for reference. There should also be some documentation for how non-accepted values are treated, anyone know of some?
It says on the man page for glMaterial you linked to, it generates a GL_INVALID_VALUE error (there are updated man pages for OpenGL 2.1 on OpenGL.org). If you look in section 2.5 GL Errors of the OpenGL Specs (which is the documentation on the exact workings of core OpenGL in its entirety) you will notice that whenever any GL error is generated (except possibly GL_OUT_OF_MEMORY) the offending function is ignored.
Quote:
Original post by Dim_Yimma_H
Good to hear that it was solvable. In a way, it's a relief that the problem actually was because of an unaccepted value, it feels more alright if different drivers behave inconsistently then. Otherwise, it would've been very close to seeming like a DLL bug!
If setting the specular exponent to something out of range has any effect other than just generating a GL_INVALID_VALUE error than that is a driver bug.

If the drivers in these machines were anywhere near recent I doubt there would be such a simple bug in there, which is what makes me skeptical that that was the actual problem. But it's fixed now so whatever. [rolleyes]

Share this post


Link to post
Share on other sites
Quote:
Original post by Kalidor
It says on the man page for glMaterial you linked to, it generates a GL_INVALID_VALUE error (there are updated man pages for OpenGL 2.1 on OpenGL.org).

I was thinking about how the actual values were treated, like if 228 is clamped to 128 or ignored (keeping the default, 0) because it generates an error.
Quote:
Original post by Kalidor
If you look in section 2.5 GL Errors of the OpenGL Specs (which is the documentation on the exact workings of core OpenGL in its entirety) you will notice that whenever any GL error is generated (except possibly GL_OUT_OF_MEMORY) the offending function is ignored.

Thanks for pointing that out! It's spot-on what I wondered about, good to know that GL_INVALID_VALUE should cause the function to be ignored.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement