[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
I tried altering surface.c to lock a pyagme.OPENGL source surface before
blitting. SDL_BlitSurface returns error "Surfaces must not be locked
during blit". Drawing a circle to an opengl video surface does nothing,
even when locked [*]. Surface.mustlock() is false for an opengl surface.
The evidence is an SDL_OPENGL video surface has no pixel data. If there
are SDL examples to the contrary I am curious to see them. Even if it is
an SDL problem Pygame still crashes. Python is not C, so when something
is not supported it should raise a meaningful exception, not segfault or
quietly do nothing. In my opinion an opengl video surface is an
incomplete surface, so is not a Pygame Surface. If SDL is fixed in a
future date then an opengl video surface can become a Surface. That is
the nice thing about duck typing.
Lenard
[*] draw test program.
import pygame
from pygame.locals import *
screen = pygame.display.set_mode((640,480), OPENGL|DOUBLEBUF)
if screen.mustlock():
print "The screen needs locking."
else:
print "The screen needs no lock."
pygame.display.flip()
screen.lock()
pygame.draw.circle(screen, (255, 255, 255), (200, 200), 50)
screen.unlock()
pygame.display.flip()
while 1:
evt = pygame.event.wait()
if (evt.type == QUIT):
break
pygame.quit()
Brian Fisher wrote:
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.
- References:
- gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)
- Re: gl, image.save crash... was (Re: [pygame] Automated Builds)