Mercurial > sdl-ios-xcode
view docs/man3/SDL_SetColors.3 @ 1544:ab1e4c41ab71
Fixed bug #33
Mike Frysinger wrote:
> with libsdl-1.2.9, some games (like bomberclone) started
> segfaulting in Gentoo
[...snip...]
> the last change in the last hunk:
[...snip...]
> if i change the statement to read:
> (table[which].blit_features & GetBlitFeatures()) == GetBlitFeatures()
> bomberclone no longer segfaults on my box
Alex Volkov wrote:
> The test "(table[which].blit_features & GetBlitFeatures()) ==
> table[which].blit_features)" is correct, and the previous
> "(table[which].cpu_mmx == SDL_HasMMX())" was actually broken.
I think there is potentially a slightly different cause of the above problem.
During the introduction of the Altivec code, the blit_table struct field
'alpha' got changed from a straightforward enum to a bitmask, which makes
perfect sense by itself. However, now the table driven blitter selection code
in SDL_CalculateBlitN() can choose the wrong blitters when searching for a
NO_ALPHA blitter because of the following code:
int a_need = 0;
...
(a_need & table[which].alpha) == a_need &&
When searching through the normal_blit_2[] table, a SET_ALPHA blitter (like
Blit_RGB565_ARGB8888) can now be selected instead of a NO_ALPHA one, causing
alpha channel bits to appear in a non-alpha destination surface. I suppose this
could theoretically be an indirect cause of the segfault mentioned above.
I *think* this can be fixed by changing to
int a_need = NO_ALPHA;
author | Sam Lantinga <slouken@libsdl.org> |
---|---|
date | Wed, 15 Mar 2006 15:47:49 +0000 |
parents | e5bc29de3f0a |
children | 546f7c1eb755 |
line wrap: on
line source
.TH "SDL_SetColors" "3" "Tue 11 Sep 2001, 23:01" "SDL" "SDL API Reference" .SH "NAME" SDL_SetColors\- Sets a portion of the colormap for the given 8-bit surface\&. .SH "SYNOPSIS" .PP \fB#include "SDL\&.h" .sp \fBint \fBSDL_SetColors\fP\fR(\fBSDL_Surface *surface, SDL_Color *colors, int firstcolor, int ncolors\fR); .SH "DESCRIPTION" .PP Sets a portion of the colormap for the given 8-bit surface\&. .PP When \fBsurface\fR is the surface associated with the current display, the display colormap will be updated with the requested colors\&. If \fBSDL_HWPALETTE\fP was set in \fISDL_SetVideoMode\fR flags, \fBSDL_SetColors\fP will always return \fB1\fR, and the palette is guaranteed to be set the way you desire, even if the window colormap has to be warped or run under emulation\&. .PP The color components of a \fI\fBSDL_Color\fR\fR structure are 8-bits in size, giving you a total of 256^3 =16777216 colors\&. .PP Palettized (8-bit) screen surfaces with the \fBSDL_HWPALETTE\fP flag have two palettes, a logical palette that is used for mapping blits to/from the surface and a physical palette (that determines how the hardware will map the colors to the display)\&. \fBSDL_SetColors\fP modifies both palettes (if present), and is equivalent to calling \fISDL_SetPalette\fR with the \fBflags\fR set to \fB(SDL_LOGPAL | SDL_PHYSPAL)\fP\&. .SH "RETURN VALUE" .PP If \fBsurface\fR is not a palettized surface, this function does nothing, returning \fB0\fR\&. If all of the colors were set as passed to \fBSDL_SetColors\fP, it will return \fB1\fR\&. If not all the color entries were set exactly as given, it will return \fB0\fR, and you should look at the surface palette to determine the actual color palette\&. .SH "EXAMPLE" .PP .nf \f(CW/* Create a display surface with a grayscale palette */ SDL_Surface *screen; SDL_Color colors[256]; int i; \&. \&. \&. /* Fill colors with color information */ for(i=0;i<256;i++){ colors[i]\&.r=i; colors[i]\&.g=i; colors[i]\&.b=i; } /* Create display */ screen=SDL_SetVideoMode(640, 480, 8, SDL_HWPALETTE); if(!screen){ printf("Couldn\&'t set video mode: %s ", SDL_GetError()); exit(-1); } /* Set palette */ SDL_SetColors(screen, colors, 0, 256); \&. \&. \&. \&.\fR .fi .PP .SH "SEE ALSO" .PP \fI\fBSDL_Color\fR\fR \fI\fBSDL_Surface\fR\fR, \fI\fBSDL_SetPalette\fP\fR, \fI\fBSDL_SetVideoMode\fP\fR ...\" created by instant / docbook-to-man, Tue 11 Sep 2001, 23:01