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?