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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>> 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 <[EMAIL PROTECTED]>
>>>>> 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 <[EMAIL PROTECTED]
>>>>>>> <mailto:[EMAIL PROTECTED]>> 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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
