Persistent surfaces

SDL Development
1

Hello hey, I have this situation/question,
I’m locking a surface and then working on it much in the following way (I
included the basic calls I’m making for differnt systems). The question is:
once I’ve modified the surface (via pixels), and unlocked,
flipped/swapped/displayed to the screen, the next time I get the pointer
pixels to the surface, will the surface still contain the modifications I
did the last time (before the flip/display)?

I have tried doing it and it seems the things I “painted” are still there
the next time, but I want to know if this behavior is expected and
guaranteed, or if it’s just a coincidence. And if it’s expected on some but
not on other systems I’m using (opengl, ddraw, etc.) please let me know on
which ones that behavior is guaranteed.

The calls I’m using:

SDL_Block sdl;

SCREEN_SURFACE:
SDL_LockSurface(sdl.surface)
pixels=(Bit8u *)sdl.surface->pixels;
work with pixels
SDL_UnlockSurface(sdl.surface);
SDL_Flip(sdl.surface);

SCREEN_SURFACE_DDRAW:
SDL_LockSurface(sdl.blit.surface)
pixels=(Bit8u *)sdl.blit.surface->pixels;
work with pixels
SDL_UnlockSurface(sdl.blit.surface);
IDirectDrawSurface3_Blt(
sdl.surface->hwdata->dd_writebuf,&sdl.blit.rect,
sdl.blit.surface->hwdata->dd_surface,0,
DDBLT_WAIT, NULL);

SCREEN_OVERLAY:
SDL_LockYUVOverlay(sdl.overlay);
pixels=(Bit8u )(sdl.overlay->pixels);
work with pixels
SDL_UnlockYUVOverlay(sdl.overlay);
SDL_DisplayYUVOverlay(sdl.overlay,&sdl.clip);

SCREEN_OPENGL:
pixels=(Bit8u *)sdl.opengl.framebuf;
work with pixels
glBindTexture(GL_TEXTURE_2D, sdl.opengl.texture);
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0,
sdl.draw.width, sdl.draw.height, GL_BGRA_EXT,
GL_UNSIGNED_INT_8_8_8_8_REV, sdl.opengl.framebuf);
SDL_GL_SwapBuffers();

Thanks.
Kronuz.

“Fools rush in where fools have been before” - Unknown

2

I have tried doing it and it seems the things I “painted” are still there
the next time, but I want to know if this behavior is expected and
guaranteed, or if it’s just a coincidence. And if it’s expected on some but
not on other systems I’m using (opengl, ddraw, etc.) please let me know on
which ones that behavior is guaranteed.

Hardware surfaces, generally speaking, can be lost at any
time…especially on Windows. However, assuming that you don’t lose the
surfaces through a system event (such as switching out of fullscreen
mode, etc), their contents shouldn’t change.

Also, they are very slow if you are modifying them a lot…if you need
direct pixel access every frame, use a software surface…they don’t
need locking, they never lose their data, and if you need to modify them
frequently, will actually be faster.

Generally hardware surface locking is intended for surfaces that need to
be locked once for initialization, or only need occasional changes. You
need to be prepared to reload their contents, though, since they can be
lost through various system events that are beyond your control at any time.

–ryan.

3

I have tried doing it and it seems the things I “painted” are still there
the next time, but I want to know if this behavior is expected and
guaranteed, or if it’s just a coincidence. And if it’s expected on some
but not on other systems I’m using (opengl, ddraw, etc.) please let me
know on which ones that behavior is guaranteed.

Hardware surfaces, generally speaking, can be lost at any time…especially
on Windows. However, assuming that you don’t lose the surfaces through a
system event (such as switching out of fullscreen mode, etc), their
contents shouldn’t change.

Also, they are very slow if you are modifying them a lot…if you need
direct pixel access every frame, use a software surface…they don’t need
locking, they never lose their data, and if you need to modify them
frequently, will actually be faster.

Generally hardware surface locking is intended for surfaces that need to be
locked once for initialization, or only need occasional changes. You need
to be prepared to reload their contents, though, since they can be lost
through various system events that are beyond your control at any time.

Those are great news, I thought it was just a mere coincidence that the
content remained after subsequent calls. So then it looks like all I need to
check for is the lose of the surface to assure it’s content remains intact.
However, I was thinking, shortly after my first message, what about double
or triple buffered? will I still get the same content (if no surface is
lost) even when the memory has switched from the back buffer to the display?
or how does it work, I’m not sure how all this works, and it’s vital for my
project to be 100% sure the content in the surface won’t be lost (or when
exactly is going to be lost)

I’d appreciate if you could share your views on this subject.

Greetings,
Kronuz.

“Fools rush in where fools have been before” - Unknown

4

[…]

However, I was thinking, shortly after my first message, what about
double or triple buffered?

This affects only the display surface.

will I still get the same content (if no surface is
lost) even when the memory has switched from the back buffer to the
display?

Yes, as long as you’re dealing with other surfaces than the display
surface.

Now, the display surface OTOH, is problematic! Basically, what happens
with the display surface buffer when you Flip() depends on a lot of
stuff, such as OS, hardware, driver, video mode and possibly other
things.

What’s even worse is that you cannot reliably tell what kind of setup
you have, since some APIs are basically ignoring the problem and just
have the drivers do it any way they like.

Unless you’re building turn-key systems, the best you can do is ask
the user (ie set up a double buffered display with potentially out of
sync buffers, flip some and ask “Do you see any flickering on the
screen right now? [Yes/No]”). The easiest way is to work around the
problem by assuming that the behavior is undefined and always repaint
the whole screen before flipping.

or how does it work, I’m not sure how all this works, and it’s vital
for my project to be 100% sure the content in the surface won’t be
lost (or when exactly is going to be lost)

If it’s vital that you know in advance when it may happen, I think
you’re in some serious trouble… It’s beyond your control, and all
you can do is deal with it when you discover that SDL_BlitSurface()
fails. It doesn’t necessarily happen as a result of something the
application does, but can happen when the user switches to another
application, for example.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 22 November 2005 17.39, Jeremy Kronuz wrote: