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

["René Dudfield" <renesd@xxxxxxxxx>]

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?
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>