[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gl, image.save crash... was (Re: [pygame] Automated Builds)



Looking over this whole thread, I can't help but think a lot of the thinking towards opengl display surfaces is wrong with respect to the way SDL is meant to work - the whole idea of locking surfaces with SDL is that the pixels member is invalid unless the surface is locked. As long as a routine respects that when it needs to access the pixels, and as long as an OpenGL display surface supports being locked in order to get a valid pixels pointer, it should all work (albeit super slow). Image saving and draw routines in particular should all work in that case as well.

If the problem is that locking doesn't work for an OpenGL display surface, then it seems that would be an SDL problem, and any pygame fix would be working around an SDL problem in a clugey way.


On Thu, Jun 12, 2008 at 8:06 PM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
The more that I look at this the more it becomes apparent that an opengl screen should not be a Surface, but its own type. There are not just pixel arrays and buffers. There are also the draw and transform modules. These are a lot of places where explicit tests must be added, while they already check for a surface. The Surface methods would also become more streamlined as SDL_OPENGL flag checks would be unnecessary.

Lenard



Lenard Lindstrom wrote:
OK, I will add the NULL tests to PySurface_Blit, _numericsurfarray, Surface.get_buffer() and PixelArray. That way the errors will be consistent.

Lenard


René Dudfield wrote:
hi,

I think that should raise an exception too - because it's never been
expected to work.

I think mostly opengl stuff should be kept separate for now except for
the existing screenshot use case.  SDL 1.3+ has more direct opengl
mode stuff - so I think we should probably wait until then before
adding more opengl features.

cheers,

On Fri, Jun 13, 2008 at 9:36 AM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
 
The array stuff should raise an exception as currently an opengl surface
cannot be directly altered. But what about blitting an opengl surface to
another surface?

Lenard


René Dudfield wrote:
 
I think they should just check:
if (surf->pixels == NULL) {
  handle_error();
}


On Fri, Jun 13, 2008 at 9:22 AM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:

   
What I see is an opengl SDL screen surface has a NULL pixels pointer
while a
HWSURFACE surface (screen or otherwise) does not. Beyond that I have no
explanation. What it means is that PixelArray and surfarray will also
fail
on opengl surfaces.

Lenard


Brian Fisher wrote:

     
So isn't that the same as a HWSURFACE display surface when you're not
using openGL?

On Thu, Jun 12, 2008 at 9:57 AM, Lenard Lindstrom <len-l@xxxxxxxxx
<mailto:len-l@xxxxxxxxx>> wrote:

 Further testing shows that the pixels pointer for an opengl SDL
 surface is NULL.

 Lenard


 Lenard Lindstrom wrote:

     I have no idea why an opengl surface save is handled in such a
     convoluted way.


     Brian Fisher wrote:

         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?