Hi, I'm having a spat with trying to get some older code working: The code generates OpenGL textures from PyGame surfaces. The first texture generates, but then the next one dies, and a PyGame parachute happens.
After much testing, I tracked the crash down to a call in my texturing library. The section of code transforms a surface in preparation for being loaded into a texture. The operation is "Surface.subsurface()". Printing the value of the surface immediately before the call (on the faulty run-through) gives: <Surface (Dead Display)>. I was unable to figure out what's wrong from the C. After more examination, I realized that the surface was *already* a "Dead Display" *before* that section of code. I went all the way back up to the calling function, and didn't find it there. It turned out that the corruption happened in a different subfunction of the same texture class where I was doing: self.data = copy.deepcopy(data) So, it also occurs to me that a "Dead Surface" should pretty much just raise a Python exception. If it had been, I would have discovered the problem immediately. As it happened, it took me about 30 minutes to track it down with print statements . . . One of the great things about interpreted languages versus compiled languages is that it's much easier to put error checking functionality that tells you about an error almost exactly where it happens--it's no better if it just runs until you get a hard operating system failure that terminates the program. I heartily suggest such a measure for this case. Anyway, "data", in this case, is a surface, but, consistent with Python's duck-typing awesomeness, it can be a string or NumPy array, and maybe a few other things too. Now that I know what the problem is, I need to fix it. "self.data" really can't be linked in any way to the input data "data". How do I do this (consistent for several data types, but, chiefly, surfaces)? Thanks, Ian
