[SDL] pixels getting set to NULL
john at johnnypops.demon.co.uk
Tue Dec 9 13:58:01 PST 2003
On Tuesday 09 December 2003 12:43 pm, Warren Schwader wrote:
> OK, Sorry for the recent floods of emails, but for those interested I
> think I fixed my problem,
> If I use SDL_RLEACCEL when I create the doneImageSurface (one of the dialog
> items) then I get the null pixels pointer after blitting the dialog surface
> to the main surface. I can still use RLE on the dialog surface though
> which is good.
> I guess the only thing still that I need explained is why this is so?
> --Warren Schwader
In a nut-shell, dialogSurface->pixels isn't guaranteed to be valid *except*
when you are inside a Lock<->Unlock block:
// dialogSurface->pixels valid inside here
// dialogSurface->pixels no longer valid
RLE surfaces are a good example of why this is so. When you do this:
SDL_SetColorKey(dialogSurface, SDL_SRCCOLORKEY|SDL_RLEACCEL, color);
the memory representing the pixels is compresed into a series of runs of
non-transparent pixels, which take up less space and are faster to render.
The original pixel memory is freed.
When you lock an RLE surface, you are requesting access to the original pixels
that no longer exist. SDL_LockSurface() knows this and kindly regenerates the
original surface for you from the RLE version, fills in dialogSurface->pixels
with a pointer to this temporary surface, and lets you fiddle with the
When you call SDL_UnlockSurface() you are indicating that you have finished
fiddling and SDL_UnlockSurface() RLE encodes the modified pixels, destroys
the temporary surface, and sets dialogSurface->pixels to NULL to prevent
Some hardware-surface systems e.g. DirectX are capable of copying surface data
between system memory and video memory transparently using the same
Hope that helps,
PS calling SDL_SetColorKey() or SDL_BlitSurface() whilst a surface is locked
(as you seem to) is a bad idea - see the docs.
More information about the SDL