Display list problem with new nVidia drivers

Following code is not rendering triangles with latest nvidia drivers. But, older nVidia drivers were able to render them. Am I not following OpenGL standards?

Thanks for the help.

glNewList( 1, GL_COMPILE );
glBegin(GL_TRIANGLES);
glVertex2f(1.0f, 1.0f);
glVertex2f(0.0f, 0.0f);
glVertex2f(-1.0f, 1.0f);
glEnd();
glBegin(GL_TRIANGLES);
glVertex2f(1.0f, -1.0f);
glEndList()

glNewList( 2, GL_COMPILE );
glVertex2f(0.0f, 0.0f);
glVertex2f(-1.0f, -1.0f);
glEnd();
glEndList()
….
………
glCallList (1);
glCallList (2);

Heheheeeeeeee

This question is too advanced for me … Anyway …

1/ RTFM
2/ RTFMSDN
3/ RTFRedBook

or simply google “glNewList sample”.

SeskaPeel.

Hey I know the following code will work.

glNewList( 1, GL_COMPILE ); // Create display list for triangle 1
glBegin(GL_TRIANGLES);
glVertex2f(1.0f, 1.0f);
glVertex2f(0.0f, 0.0f);
glVertex2f(-1.0f, 1.0f);
glEnd();
glEndList()
glNewList( 2, GL_COMPILE ); // // Create display list for triangle 2
glBegin(GL_TRIANGLES);
glVertex2f(1.0f, -1.0f);
glVertex2f(0.0f, 0.0f);
glVertex2f(-1.0f, -1.0f);
glEnd();
glEndList()
….
………
glCallList (1); // Draw the Triangle 1
glCallList (2); // Draw the Triangle 2

But, we have some software which is using code similar to the one I have mentioned before. Do you think this not according to OpenGL specification?

You are completely misunderstanding the way glNewList works.

Why don’t you follow my advice and RTFM ?

SeskaPeel.

Hey I know the following code will work.

glNewList( 1, GL_COMPILE ); // Create display list for triangle 1
glBegin(GL_TRIANGLES);
glVertex2f(1.0f, 1.0f);
glVertex2f(0.0f, 0.0f);
glVertex2f(-1.0f, 1.0f);
glEnd();
glEndList()
glNewList( 2, GL_COMPILE ); // // Create display list for triangle 2
glBegin(GL_TRIANGLES);
glVertex2f(1.0f, -1.0f);
glVertex2f(0.0f, 0.0f);
glVertex2f(-1.0f, -1.0f);
glEnd();
glEndList()
….
………
glCallList (1); // Draw the Triangle 1
glCallList (2); // Draw the Triangle 2

But, we have some software which is using code similar to the one I have mentioned before. Do you think this not according to OpenGL specification?

Originally posted by SeskaPeel:
[b]You are completely misunderstanding the way glNewList works.

Why don’t you follow my advice and RTFM ?

SeskaPeel.[/b]
No, the code in the first post is valid.
Every command which is able to be compiled into a display list should just be played back if called this way.
In this example replace the CallList calls with the commands inside the display list and see what you get? Two triangles.

Ok, if this worked before the “latest”(?) driver whatever that is for you, has a bug.

Prabuva’s list example is not valid. Page 268 of the OpenGl Reference Manual, Second Edition, states in the ERRORS section:

GL_INVALID_OPERATION is generated if glNewList or glEndList is executed between the execution of glBegin and the corresponding execution of glEnd.

The first display list example should return GL_INVALID_OPERATION because you are calling glEndList after a glBegin, but before the corresponding glEnd. This means that previous driver versions were in error with respect to the OpenGL specifications and the latest driver is behaving correctly.

Wrong, the display list is generated with GL_COMPILE, the glBegin and glEnd calls are not executed. :rolleyes:

The error conditions supported by glNewList and glEndList are specifically geared towards compilation. I don’t see much use for them if they only apply to compile-and-execute mode. For one thing, having a glEndList in the middle of a glBegin/glEnd pair would be no more difficult to handle than any other state-saving code. During execution, the pipeline always knows the current state so if the list compiler needed to save some internal “in-the-middle-of-a-primitive” state, it would certainly be able to do so. Yet this is not the case, and the specs state that a GL_INVALID_OPERATION will be returned. This implies to me that attempting to compile a list in the middle of a primitive is not allowed due to the pipeline not saving intermediate states or so that the pipeline can assume that glCallList can reset the primitive state.

You can use roll-eyes smileys all you want, but unless the specs explicitly state that lists must be able to end in arbitrary positions, then a “it worked before, and it doesn’t work now, so it must be a bug” hypothesis is no better than the explanation I am suggesting. You need to take the stance that anything not explicitly stated in the specification is considered undefined and that anything undefined is considered “your mileage may vary,” where behavior may not be consistent between driver releases, even if by the same vendor.

You might as well just email nvidia developer relations and ask them directly. It seems like that would be an official answer and be a lot more productive than arguing about undefined behavior.

Ok I don’t know what SeskaPeel’s deal is, but that first code posting should work just fine. Looks like a bug to me! :slight_smile:

-SirKnight

@Riff: You looked up the spec, which is good, but you cited the wrong error case.

The error you mention is this
// E.g. while not in display list compile mode
glBegin
glNewList => INVALID_OPERATION

The case here is clearly outlined in the spec Chapter 5 “NewList”:

“If mode is COMPILE, then commands are not executed as they are placed in the display list.

After calling NewList all subsequent GL commands are placed in the display list (in the order the commands are issued) until a call to
void EndList( void );
occurs, after which the GL returns to its normal command execution state.

Once defined, a display list is executed by calling
void CallList( uint n );
n gives the index of the display list to be called. This causes the commands saved
in the display list to be executed, in order, just as if they were issued without using
a display list.”

The code is correct, I’ve seen something like this running before. Agreed, it’s weird and I wouldn’t program that way either. Ok, I’m out of here.

@prabuva: What’s your “latest” driver and hardware.

The sample code has an endlist call between a glBegin glEnd pair.

Technically it is illegal code IMHO section 2.6.3 “GL Commands Within Begin/End” states you may invoke a calllist between begin end pair but does not say endlist is permitted.

Whether the mode is COMPILE or COMPILE & EXECUTE does not affect the legality of this although it may affect the execution in practice IMHO (it’s an imperfect world). It makes some sense that this would work on some implementations and not on others.

You should see an INVALID_OPERATION error immediately after you issue the endlist call.

But only if the glBegin had been executed. If your build a display list GL_COMPILE the glBegin has not been executed. The error you cite is true for an immediate mode or display list compile_and_execute glBegin-glEnd pair. Read the specs in my previous post.

>>@prabuva: What’s your “latest” driver and >>hardware.

Driver version: NVIDIA 5.6.7.2 (Not working)
Driver version: NVIDIA 4.5.2.3 (Working)

Chipset: NVIDIA GeForce4 Ti 4600.

Thanks for the response.

You see, “latest” means nothing, it’s already outdated by 61.76. Might give it a try.

>>You see, “latest” means nothing, it’s already >>outdated by 61.76. Might give it a try.

I have tried it. It did not work:-(

Originally posted by Relic:
But only if the glBegin had been executed. If your build a display list GL_COMPILE the glBegin has not been executed. The error you cite is true for an immediate mode or display list compile_and_execute glBegin-glEnd pair. Read the specs in my previous post.
I think Dorbie is right.

Calling glBegin counts as executing.
The word “COMPILE_AND_EXECUTE” that you pass to glNewList has nothing to do with it.

If one does

glNewList(ID, GL_COMPILE);
glColor3f(…);
glBegin(…);
glVertex(…);
glVertex(…);
glVertex(…);
glVertex(…);
glEnd();
glEndList();

If I understood it right, the current color comes from the call to glColor3f in the display list, even though nothing is getting rendered.

When I executed the code in my first post with the recent drivers, no error occured. The glGetError returned GL_NO_ERROR instead of GL_INVALID_OPERATION error as mentioned by Dorbie. But, I could not see the triangles.

The sample code is correct. Relic was spot on in his explanation: when you are in COMPILE mode, the commands are not executed, they are just stored inside the display list.

In fact, this means that if a command compiled inside a display list would give an error if executed, the error won’t be detected at compile time, but at display list execution time. But then at execution time, there’s no glEndList, so in the sample’s case, no error should occur.

This is supported by the fact that glCallList/s is valid inside begin/end. So it’s perfectly valid to do

Display lists require one bit of state to indicate whether a GL command should be executed immediately or placed in a display list. In the initial state, commands are executed immediately.

(OpenGL spec 1.5 pg 210)

Just take a look at SGI's sample implementation's _gllc* (list compile) and glle* (list execute) functions (normally dl* files).
You will see that __gllc_Begin (the function called when a begin is compiled inside a display list) doesn’t set the flag of “inside begin/end”, so when __glim_EndList is called it doesn’t fail the begin/end check.

For example, one of the curious things SGI’s implementation does is, when an OpenGL command compiled inside a display list would return an error if executed, it stores the error directly inside the display list instead of storing the OpenGL command.
As cited earlier, that’s not the case when glEndList is called inside begin/end - when in COMPILE mode - it’s not an error so no error is placed in the display list.

I don’t know display lists very well, and i might be wrong, but doesn’t someone has to call glNewLists before compiling a display list?