View Full Version : glBegin disables GL_TEXTURE_2D when it shouldn't?

12-08-2000, 08:12 PM
I'm having a problem with OpenGL,

I'm trying to get it to render a scene for me, it worked fine when I didn't try to optimise it with display lists. I'm using glNewList with GL_COMPILE_AND_EXCECUTE, because I rely on getting glIsEnabled for GL_TEXTURE_2D. Please don't tell me to cache the state, because I am popping and pushing stacks of states, and I don't want to have to pop and push stacks of states of the enable state for myself as well as OpenGL doing it.

So, I am using compile and execute in a display list. I enable texture2d, it enables fine (I checked explicitly with glIsEnabled), it stays fine all the way up to the command glBegin (I checked explicitly). then, after glBegin, the texture state is OFF!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


What is going wrong here? I don't understand this.

12-08-2000, 08:37 PM
check to be sure that you are doing the glEnable(GL_TEXTURE_2D) inside of the display list....

for example:

m_DisplayList = glGenLists(1);

do whatever ...

12-08-2000, 08:50 PM
Yes, glEnable GL_TEXTURE_2D *is* inside the glNewList command. http://www.opengl.org/discussion_boards/ubb/frown.gif

Any other ideas?

12-09-2000, 09:05 AM
According to the guide calling glIsEnabled between glBegin/glEnd is invalid and possibly generates an "queryable" error code. The value glIsEnabled returned is undefined. Since the return value is
undefined GL_TEXTURE_2D isn't necessarily off or on.

Further calling glIsEnabled between glNewList/glEndList results in the command being executed immediately. In other words glIsEnabled (and a bunch of other OpenGL commands) was left out of the display list when compiled. glIsEnabled got called the first time and then never again.

Here's what you do
You're better off breaking a giant display list down into smaller display lists that do not require runtime information. Create a new function to call your smaller display lists. If a display list is called based on runtime information then stick it in a conditional statement.
For example:
glCallList( background )
if glIsEnabled( GL_TEXTURE_2D )
glCallList( whatever )
glCallList( foreground )
You can still push and pop states, just do your checking outside of
display lists.

12-09-2000, 11:42 AM
Thanks a lot, but I want to put everything that doesn't move in one display list. I know glIsEnabled isn't including the the display list. That is why I used it, because it would lead to speedy lists. It lead to a 2x speed increase over many smaller ones, but also it lead to bugs.

I'll know not to call that function from inside a glBegin/glEnd block now, and be more careful about display lists like you suggested.

Do you have anymore very good suggestions (like the last ones) about making large display lists?

Thanks for everything!

12-09-2000, 04:11 PM
OK now I'm confused.

"I want to put everything that doesn't move in one display list" ==> I got it.

"I know glIsEnabled isn't including the the display list. That is why I used it, because it would lead to speedy lists." ==> You wanted to slow down list playback?

Anyways getting back to your original problem I found this at http://msdn.microsoft.com/library/default.asp under the description for function glTexImage2D:
"A texture image with zero height or width indicates the null texture. If the null texture is specified for level-of-detail 0, it is as if texturing were disabled."
Got anything that causes this in your code?

On the topic of display lists:
There isn't a whole I can say about display lists other than
1) display lists are not an opportunity to do general scripting because only a select group of commands are stored in display lists. Valid commands are stored. Invalid commands are executed immediately.
2) Like invalid commands, C/C++ (or whatever you're using) statements are also executed once. By once I mean when the list gets compiled.
3) Do as many pops as you do pushs. If you push states or alter flags in a list then restore them before glEndList.
4) Leave runtime conditional processing outside of lists.