I get what the new code is trying to do - but my point was that at some point a surface is written out to a file - I was specifically asking how that is accomplished, possibly deep in SDL land. If SDL was able to lock the GL display surface, and get a * to the pixels, then wouldn't you be able to treat saving the screen exactly the same as all other surfaces?
what happens when you try to save a HWSURFACE DOUBLEBUF display surface and you're not in GL mode, for instance? Why is GL any different at all? On Tue, Jun 10, 2008 at 8:19 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > No, it only retrieves the display surface to get the size. It creates a new > SDL surface, retieves a copy of the display using an opengl routine, then > copies this to the surface. The surface is then written out to the file. > > Lenard. > > > Brian Fisher wrote: > >> I assume the save routine locks the display surface, and then uses the >> buffer from the lock, yeah? so if locking an opengl display surface worked, >> then wouldn't save work too? >> >> On Tue, Jun 10, 2008 at 4:25 PM, Lenard Lindstrom <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> wrote: >> >> Current (lack of) progress report. All I can determine for sure is >> that setting the screen mode to OPENGL causes pygame.image.save to >> segfault. It doesn't matter what file extension the output file >> has. I have been unable to pin down the exact point where this >> happens since commenting out code moves the location of the >> segfault. Replacing the opengltosdl call with a simple >> SDL_CreateRGBSurface call also segfaults. Two locations where >> sefaults happen are when opengltosdl returns and the >> PyObject_CallObject call to save_extended in imageext. I will play >> around with it some more later. I will also try gdb again. Maybe >> the problem is in set_mode itself. I will have a look at it as well. >> >> >> >
