I like to get some straight , not "modern OpenGL " marketing smoke and mirrors from the group, if possible.
here is my test code
// create list
DisplayListIndex = glGenLists(MAX_LIST); // create 10 display lists
printf("\nDisplayListIndex %i function %s @line %d “, DisplayListIndex ,FUNCTION,
printf(”\nDisplayListIndex %i function %s @line %d ", DisplayListIndex ,FUNCTION,
- Here is the output
ENTER function OpenGL_DisplayList @line 173
DisplayListIndex 1 function OpenGL_DisplayList @line 181
DisplayListIndex 1 function OpenGL_DisplayList @line 187 > Blockquote
- I expect the DisplayListIndex = 0
What am I doing wrong ?
You’re expecting the wrong thing.
glGenLists could generate almost any value (which doesn’t already overlap with existing display list indices); there is no reason to expect it to spit out any particular integer.
In fact, expecting zero is wrong because
glGenLists will never return 0 unless producing the given number of list names is impossible. That is, returning 0 represents an error.
Zero is never a valid display list name.
To augment Alfonse’s reply, if you’re expecting glDelete* to zero out “DisplayListIndex”, then you’re expecting the wrong thing. That’s not how OpenGL objects work.
The uint returned by glGen* isn’t an “object” using a smart pointer or some automatic reference counting, like you might expect in an OOP language. It’s a 32 bit uint, period. It is an opaque name which identifies an object being managed by the GL, in the driver’s opaque data structure (e.g. a hash.) glGen* merely returns a name which can used to lookup (bind, modify, etc) an object, and glDelete* frees up that name (and, eventually, deletes the object in the opaque structure.)
If you want to know if “DisplayListIndex” is actually an object, see the glIs* functions (and read the documentation about when an object name is allocated vs when an object is allocated. The behavior is inconsistent for different types of object.)
Missed my point - I know the “value” being generated and zero is invalid.
I just cannot trust OpenGL to do what is advertising , period.
It states in so many fancy terms that I can reuse the list generated, it is not necessary to delete it.
I had too many “list indexes” floating around so I just wanted to verify if I actually deleted the list.
So the bottom line - delete list is bogus “feature” if it cannot be verified.
But I am getting used to OpenGL “terminology” - named int , OpenGL is not Object Oriented so we “have an object…types of object…”.
PS Linux uses “file descriptor”.
glGenLists allocates names, but does not create lists. Allocation simply provides you with names which aren’t already allocated.
glNewList creates a list. Most commands issued between the
glNewList and the next
glEndList are stored in the list. If the name already refers to a list, the existing definition will be overwritten. It isn’t strictly necessary to have allocated the name with
glGenLists, but doing so ensures that you create a new list rather than overwriting some existing list.
glDeleteLists deletes any definitions for the lists and makes the names available for subsequent allocations. You can “clear” a list without releasing the name for re-use simply by calling
glNewList immediately followed by
glEndList, overwriting any existing definition with an empty command sequence.
glIsList will tell you if a name refers to a list. This is true from the point that
glNewList is called to the point that the list is deleted with
glCallLists attempt to use a non-existent list (not allocated, allocated but not created, or deleted), nothing happens; no error is generated.