Hi All This is a bit of an advanced question about display lists. I was contemplating whether to post this on the opengl.org advanced forum or here. I couldn't be arsed to setup an account on OpenGL.org so here we are. lol. Anyway the problem is that I have created a class that loads a Lightwave model. The model polygon and vertex data is stored in pointers within the class. Now I then load the model into my opengl app by created a pointer to the class: Lightwave *model = NULL; Then I initialise the model as normal and load the object into the memory. Now here is where display lists come in. The data is then passed to a display list using the array version of the opengl commands. I then delete the model data freeing up the memory it used and the model is display using the display list and it works fine. The problem is my program sometimes crashes and it is very annoying. The only time it doesn't crash is when I remove the display list code. The error message I recieve is always an unreferenced memory error. Is there something I should know about display lists that is going on behind the scenes?? Steve

could be various things. Could you post some of your code?

What you need to compile to the list are drawing codes. I think that compiling using vertex arrays within a display list still refers to the pointer's location, so by deleting it, you get that error. If you compile actual drawing commands to the list instead, you should get the same speed, but it won't be dynamic at all. I have been wrong before, and I'm not completly sure that the array calls go into the list this way, but I think so.

according to msdn:

Quote:
You can include the glDrawElements function in display lists. When glDrawElements is included in a display list, the necessary array data (determined by the array pointers and enables) is also entered into the display list. Because the array pointers and enables are client-side state variables, their values affect display lists when the lists are created, not when the lists are executed.

from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glfunc01_2q5w.asp

So all the data should be copied into memory when you create the display list, and it should be safe to delete it. You can try replacing the data with garbage before you delete it to test that this is the case. Even after you delete a block of memory, the data might be accessable and it might not be messed with. In MSVC, the debug heap replaces deallocated blocks with 0xcd of 0xeefe or something like that.

Sounds like the 'display list code' contains or gets passed an invalid pointer sometimes. Like Dyerseve says, the pointers are only used when creating the list, so it must be then.

Hi

Thanks for your replies. I might give the glDrawElements a bit of investigation and see what happens when I use that.
I'll just say that my program would not instantly crash. It would run for between 30 minutes to sometimes 3 or more hours before crashing with a memory error message.
Well my code is now pretty stable (but that's without display lists). It also seems to be more stable since I changed all the objects in my demo to use pointers...
For example I have a vector class which I used to create an object with.

Vector camera;

Set the code running and went off to work. By the time I got home (9 hours later) it had crashed. So I changed that new addition to my program to this:

Vector *camera;

Initialise the camera (allocate RAM for it) in my setup function and the program didn't crash and ran for over 9 hours. Maybe I'm barking up the wrong tree but this sort of thing affects my engine. I'm not sure why though. I didn't think there was anything wrong with using the first method. Which method does everyone else use for adding objects to your demos??

Steve-B

the thing about memory reference bugs is that they are very misleading about the cause. I once had a program that would crash at a line 1000 lines below the actual error.

basically, im saying that the problem may not be display lists, its just that when you remove the display list, you change the outputted exe to a state where the memory bug doesnt show up.