[SDL] Android SDL_RWops support for reading from .apk files

Tim Angus tim at ngus.net
Fri Jul 29 08:00:55 PDT 2011


On Sun, Jul 17, 2011 at 2:28 PM, Rob Probin <rob at lightsoft.co.uk> wrote:

> **
>  Anyone else see this? Am I just going a bit mad - entirely possible :-)
>
> If you are doing this:
>     SDL_FillRect(surface,&(surface->clip_rect),
> SDL_MapRGB(new_surface->format,r,g,b));    // (I know the second parameter
> could be NULL here)
>
> On a 24 bit pixel surface (e.g. SDL_PIXELFORMAT_BGR24 or
> SDL_PIXELFORMAT_RGB24)
>
> You get down to this routine (v1.3.0 build 5557 I think):
>
> static void
> SDL_FillRect3(Uint8 * pixels, int pitch, Uint32 color, int w, int h)
> {
>     Uint8 r = (Uint8) ((color >> 16) & 0xFF);
>     Uint8 g = (Uint8) ((color >> 8) & 0xFF);
>     Uint8 b = (Uint8) (color & 0xFF);
>
> If we abstract the idea of RGB and just treat them as 3 variables, say XYZ,
then:
X = bits 23:16
Y = bits 15:8
Z = bits 7:0

The upper 8 bits are then ignored. Then for each row of pixels, you find the
XYZ-XYZ-XYZ byte pattern. To make this work for RGB or BGR images, one would
need only ensure that XYZ are mapped to the correct components ahead of
time, which I assumed was the job of SDL_MapRGB(), i.e. X <- R,  Y <- G, Z
<- B for RGB, X <- B,  Y <- G, Z <- R.

Is this not what happens?




>     while (h--) {
>         int n = w;
>         Uint8 *p = pixels;
>
>         while (n--) {
>             *p++ = r;
>             *p++ = g;
>             *p++ = b;
>         }
>         pixels += pitch;
>     }
> }
>
> A Note from the comments for SDL_FillRect in the header ...
> *  The color should be a pixel of the format used by the surface, and
> *  can be generated by the SDL_MapRGB() function.
>
> Ironically, due to the SDL_MapRGB, the decode of r g b  in SDL_FillRect3 is
> wrong for both BGR24 and RGB24!!!
>
> Regards,
> Rob
>
> P.S. I was using the just as a temporary working surface in order to modify
> one colour of the image to another. The work around I've used is to move to
> SDL_PIXELFORMAT_BGR888. However, I think a SDL_LoadBMP() will return one of
> these surfaces so it's not impossible to hit this by accident (which is how
> I ended up there...).
>
> The alternative - swap b and r in the SDL_MapRGB() - looks like it would
> break once this (possible) bug is fixed.
>
>  P.P.S. [Apologies if this is a duplicate post ... different email
> accounts, and all that]
>
>
>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110717/908539ce/attachment-0008.htm>


More information about the SDL mailing list