CreateRBGSurfaceFrom and display surface

SDL Development
1

Hi all,

while playing around with CreateRGBSurfaceFrom and the display surface I
wonder, in what circumstances the pointer to the pixel data in the surface
returned by SetVideoMode will change, and make a sub-surface created with
CreateRGBSurfaceFrom invalid. I only have access to a linux/xfree3.3.6 machine,
to get results. Are there differences on other OSs/devices ?

Does it occur, if the user resizes or moves the window in windowed/wm mode ? Is
there a difference if the surface is dubble-buffered, in video memory, or a
shadow surface ?

Does a Flip ever change the pointer ? (in FullScreen)

Maybe other situations ???

Maybe it is a good idea, to make a note in the docs to clear this point.

More general, is it a appropriate way, creating sub-surfaces from the display
surface to build some kind of “windowing” ??

Greetings,
Oli

2

Oliver Burtchen wrote:

while playing around with CreateRGBSurfaceFrom and the display surface I
wonder, in what circumstances the pointer to the pixel data in the surface
returned by SetVideoMode will change, and make a sub-surface created with
CreateRGBSurfaceFrom invalid.

Assume that it will float around as long as it isn’t locked. You can only
reliably create sub-surfaces with CreateRGBSurfaceFrom on software surfaces,
and even then it’s somewhat risky (screen surfaces can be resized, and others
may be RLE-encoded).

More general, is it a appropriate way, creating sub-surfaces from the display
surface to build some kind of “windowing” ??

You can always keep track on the sub-rectangles yourself and use clip
rectangles instead of actually creating a sub-surface, so you never really
need to call CreateRGBSurfaceFrom on another surface

3

Oliver Burtchen <@Oliver_Burtchen> wrote:

But then, what is CreateRGBSurfaceFrom usefull for ? Was it a mistake ?? :wink:

It’s useful for making an SDL_surface out of a block of raw image data
that was created in another way---------- Forwarded Message ----------
Subject: Re: [SDL] CreateRBGSurfaceFrom and display surface
Date: Thu, 20 Sep 2001 11:55:22 +0200 (MET DST)
From: f91-men@nada.kth.se (Mattias Engdegard)

4

Thanks, that is a clear answer.
But then, what is CreateRGBSurfaceFrom usefull for ? Was it a mistake ?? :wink:
(okay, I see it?s usefull for non RLE-Encoded Software-Surfaces)

Greetings,
Oli

Am Don, 20 Sep 2001 schrieben Sie:> Oliver Burtchen <@Oliver_Burtchen> wrote:

while playing around with CreateRGBSurfaceFrom and the display surface I
wonder, in what circumstances the pointer to the pixel data in the surface
returned by SetVideoMode will change, and make a sub-surface created with
CreateRGBSurfaceFrom invalid.

Assume that it will float around as long as it isn’t locked. You can only
reliably create sub-surfaces with CreateRGBSurfaceFrom on software surfaces,
and even then it’s somewhat risky (screen surfaces can be resized, and others
may be RLE-encoded).

More general, is it a appropriate way, creating sub-surfaces from the display
surface to build some kind of “windowing” ??

You can always keep track on the sub-rectangles yourself and use clip
rectangles instead of actually creating a sub-surface, so you never really
need to call CreateRGBSurfaceFrom on another surface

5

Thanks, that is a clear answer.
But then, what is CreateRGBSurfaceFrom usefull for ? Was it a mistake ?? :wink:
(okay, I see it?s usefull for non RLE-Encoded Software-Surfaces)

you don’t need to use an existing surface for CreateRGBSurfaceFrom
to work. you can point it to any block of memory. you could generate
your own raw image data (say, loaded from a file) and then use
that for CreateRGB.

remember, its CreateRGBSurfaceFrom, not CreateRGBFromSurface