|
Size: 4164
Comment: update formatting - categories
|
Size: 4441
Comment: update content - table sections
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| ||<-3>''Application data associated with the surface''|| | ||<bgcolor="#EDEDED"-3>''Application data associated with the surface''|| |
| Line 18: | Line 18: |
| ||<-3>''Information needed for surfaces requiring locks''|| | ||<bgcolor="#EDEDED"-3>''Information needed for surfaces requiring locks''|| |
| Line 21: | Line 21: |
| ||<-3>''Clipping information''|| | ||<bgcolor="#EDEDED"-3>''Clipping information''|| |
| Line 23: | Line 23: |
| ||<-3>''Info for fast blit mapping to other surfaces''|| | ||<bgcolor="#EDEDED"-3>''Info for fast blit mapping to other surfaces''|| |
| Line 25: | Line 25: |
| ||<-3>''Format version, bumped at every change to invalidate blit maps''|| | ||<bgcolor="#EDEDED"-3>''Format version, bumped at every change to invalidate blit maps''|| |
| Line 27: | Line 27: |
| ||<-3>''Reference count -- used when freeing surface''|| | ||<bgcolor="#EDEDED"-3>''Reference count -- used when freeing surface''|| |
| Line 29: | Line 29: |
| <<Color2(green,Should map and format_version be gray because they're private? Should SDL_!BlitMap have a page or have the link removed? There are more descriptions in the old wiki such as "the length of a surface scanline in bytes" for '''pitch'''. Should any of those be moved here to clarify the information that this struct holds even though it's mostly read-only?)>> | <<Color2(green,Should the gray rows be centered or leave them like this since they are a little different? Would it be more consistent to move the italics text into the description cells? Should map and format_version be gray because they're private? Should SDL_!BlitMap have a page or have the link removed? There are more descriptions in the old wiki such as "the length of a surface scanline in bytes" for '''pitch'''. Should any of those be moved here to clarify the information that this struct holds even though it's mostly read-only?)>> |
DRAFT |
SDL_Surface
A structure that contains a collection of pixels used in software blitting.
Data Fields
Uint32 |
flags |
internal, read-only; see Remarks for details |
format |
read-only |
|
int |
w, h |
read-only |
int |
pitch |
read-only |
void* |
pixels |
read-write |
Application data associated with the surface |
||
void* |
userdata |
read-write |
Information needed for surfaces requiring locks |
||
int |
locked |
read-only |
void* |
lock_data |
read-only |
Clipping information |
||
clip_rect |
read-only |
|
Info for fast blit mapping to other surfaces |
||
map |
private (struct) |
|
Format version, bumped at every change to invalidate blit maps |
||
unsigned int Uint? |
format_version |
private |
Reference count -- used when freeing surface |
||
int |
refcount |
read-mostly |
green
Code Examples
You can add your code example here
Remarks
This structure should be treated as read-only, except for pixels, which, if not NULL, contains the raw pixel data for the surface.
The currently supported flags for SDL_Surface are:
or
flags may be 0 or any of the following OR'd together:
SDL_PREALLOC |
surface uses preallocated memory |
SDL_RLEACCEL |
surface is RLE encoded |
green
The following Evaluates to true if the surface needs to be locked before access.
#define SDL_MUSTLOCK(S) (((S)->flags & SDL_RLEACCEL) != 0)
green
*
An SDL_Surface represents an area of graphical memory that can be drawn to. The video framebuffer is returned as an SDL_Surface by SDL_SetVideoMode() and SDL_GetVideoSurface().
green
*
Related Structures
