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 <len-l@xxxxxxxxx
<mailto:len-l@xxxxxxxxx>> 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
<len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>
<mailto:len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>>> 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.