Hi! Does SDL_Surface (ie. SDL_PixelFormat) support 2-color surfaces ?–
Trick
Linux User #229006 * http://counter.li.org
Some more questions also =)
Is it possible for a surface to have both an alpha channel and a
colorkey ? And maybe also overall alpha ?
Where i’m going with this: How do i determine if a pixel is
transparent ?
Btw, for colorkey’d surfaces, is it sufficient to just compare the
colorkey value with the pixel in question, or do i have to do some
anding first ?On Tuesday 25. September 2001 01:44 (CEST), you wrote:
Hi! Does SDL_Surface (ie. SDL_PixelFormat) support 2-color surfaces
?
–
Trick
Linux User #229006 * http://counter.li.org
Hi! Does SDL_Surface (ie. SDL_PixelFormat) support 2-color surfaces
?
SDL supports only RGB modes and 8 bpp indexed color modes. It should be
possible to create various weird RGB modes, but the problem is that SDL
assumes pixels to be 1, 2, 3 or 4 bytes. There’s also some special case
handling for 8 bit modes, I think - they’re always assumed to be
palettized modes, so I dont’t think you can create RGB 3:3:2 surfaces for
example…
Some more questions also =)
Is it possible for a surface to have both an alpha channel and a
colorkey ? And maybe also overall alpha ?
I don’t think so. Alpha channel + surface alpha would require tons of
extra multiplications. Alpha + color key shouldn’t affect RLE blits
performance wise, but I don’t think it’s supported.
Where i’m going with this: How do i determine if a pixel is
transparent ?
Well, you just look at it to see if you can see through it. 
Seriously; I think you’d have to check the pixel as well as the surface
flags. In colorkey mode, compare the pixel values to the colorkey. In
alpha mode, check the alpha channel of pixels.
Btw, for colorkey’d surfaces, is it sufficient to just compare the
colorkey value with the pixel in question, or do i have to do some
anding first ?
I’m not sure if you can assume that the unused bits (as defined by the
surface pixelformat) are guaranteed to be zero - it might be a good idea
to compare only the used bits. (This applies to the pixel data of
surfaces as well - there are RGB 5:5:5 modes and the like, and some
people use the “spare” bits for custom stuff to save space, as most video
cards just ignore them…)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Tuesday 25 September 2001 01:55, Trick wrote:
On Tuesday 25. September 2001 01:44 (CEST), you wrote:
Hi! Does SDL_Surface (ie. SDL_PixelFormat) support 2-color
surfaces ?SDL supports only RGB modes and 8 bpp indexed color modes. It
should be possible to create various weird RGB modes, but the
problem is that SDL assumes pixels to be 1, 2, 3 or 4 bytes.
There’s also some special case handling for 8 bit modes, I think -
they’re always assumed to be palettized modes, so I dont’t think
you can create RGB 3:3:2 surfaces for example…
Ok, thanks! (would love to have a 2:2:2:2 RGBA mode btw, or maybe
palettes with alpha
Is it possible for a surface to have both an alpha channel and a
colorkey ? And maybe also overall alpha ?I don’t think so. Alpha channel + surface alpha would require tons
of extra multiplications. Alpha + color key shouldn’t affect RLE
blits performance wise, but I don’t think it’s supported.
I don’t see any reason why it should be either, but i just wanted to
be sure =)
Where i’m going with this: How do i determine if a pixel is
transparent ?Well, you just look at it to see if you can see through it.
Seriously; I think you’d have to check the pixel as well as the
surface flags. In colorkey mode, compare the pixel values to the
colorkey. In alpha mode, check the alpha channel of pixels.
Ok, thanks again! One more question though … In palettized modes, is
the colorkey value the actual color of the transparent pixel, or the
index to it ? (if it’s the latter it doesn’t need any special
handling, so that’d be great =)
Btw, for colorkey’d surfaces, is it sufficient to just compare
the colorkey value with the pixel in question, or do i have to do
some anding first ?I’m not sure if you can assume that the unused bits (as defined by
the surface pixelformat) are guaranteed to be zero - it might be a
good idea to compare only the used bits. (This applies to the pixel
data of surfaces as well - there are RGB 5:5:5 modes and the
like, and some people use the “spare” bits for custom stuff to save
space, as most video cards just ignore them…)
Yea, i guess so … So, i need to AND the value, but i don’t need to
do any shifting, rite ? Since i’m testing all values (r,g,b,a?) at
once i mean…
Anyway, thank you for your help! I appreciate it!–
Trick
Linux User #229006 * http://counter.li.org
Hi! Does SDL_Surface (ie. SDL_PixelFormat) support 2-color
surfaces ?SDL supports only RGB modes and 8 bpp indexed color modes. It
should be possible to create various weird RGB modes, but the
problem is that SDL assumes pixels to be 1, 2, 3 or 4 bytes.
There’s also some special case handling for 8 bit modes, I think -
they’re always assumed to be palettized modes, so I dont’t think
you can create RGB 3:3:2 surfaces for example…Ok, thanks! (would love to have a 2:2:2:2 RGBA mode btw, or maybe
palettes with alphaIs it possible for a surface to have both an alpha channel and a
colorkey ? And maybe also overall alpha ?I don’t think so. Alpha channel + surface alpha would require tons
of extra multiplications. Alpha + color key shouldn’t affect RLE
blits performance wise, but I don’t think it’s supported.I don’t see any reason why it should be either, but i just wanted to
be sure =)
Alpha + colorkey (or preferably dual alpha channels 
could be useful
for assembling images off-screen, generating RGBA results, that can be
blitted to screen in normal alpha blending mode.
But for that kind of stuff, using RGBA surfaces with colorkeyed blitting
should already work. (Unless it’s been specifically eliminaded in the
colorkey blitting code, comparing RGBA pixels to an RGBA key should be
exactly the same thing as doing it with RGB data - it’s just a few more
bits that aren’t supposed to be ignored.)
Where i’m going with this: How do i determine if a pixel is
transparent ?Well, you just look at it to see if you can see through it.
Seriously; I think you’d have to check the pixel as well as the
surface flags. In colorkey mode, compare the pixel values to the
colorkey. In alpha mode, check the alpha channel of pixels.Ok, thanks again! One more question though … In palettized modes, is
the colorkey value the actual color of the transparent pixel, or the
index to it ? (if it’s the latter it doesn’t need any special
handling, so that’d be great =)
It’s the index, as you get it from SDL_GetRGB(). (Well, that’s what I
think anyway - and my code works
Btw, for colorkey’d surfaces, is it sufficient to just compare
the colorkey value with the pixel in question, or do i have to do
some anding first ?I’m not sure if you can assume that the unused bits (as defined by
the surface pixelformat) are guaranteed to be zero - it might be a
good idea to compare only the used bits. (This applies to the pixel
data of surfaces as well - there are RGB 5:5:5 modes and the
like, and some people use the “spare” bits for custom stuff to save
space, as most video cards just ignore them…)Yea, i guess so … So, i need to AND the value, but i don’t need to
do any shifting, rite ? Since i’m testing all values (r,g,b,a?) at
once i mean…
Well, constructing a mask and ANDing would be totally safe, but I don’t
think you should have to, unless you’re really doing something weird with
the “unused” bits.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Tuesday 25 September 2001 03:00, Trick wrote:
Hi! Does SDL_Surface (ie. SDL_PixelFormat) support 2-color surfaces ?
Yes, though the format conversion code isn’t very fast, and you can’t
blit to them, only from them.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga wrote:
Hi! Does SDL_Surface (ie. SDL_PixelFormat) support 2-color surfaces ?
Yes, though the format conversion code isn’t very fast, and you can’t
blit to them, only from them.
the support for 1bpp bitmaps is very spotty — a lot of code both in
SDL and outside assume surfaces are at least 8bpp. I’m not sure why
the code is there (historical reasons, Sam?)
Another problem with the 1bpp support is that it makes several implicit
(and undocumented) assumptions on the bitmap format (bit order and bitmap
unit)
Trick wrote:
Is it possible for a surface to have both an alpha channel and a
colorkey ? And maybe also overall alpha ?
no. The rules are described fairly well in the docs (see the sections
on SDL_SetAlpha and SDL_BlitSurface). Basically, per-surface alpha can
be combined with colour keying, but per-pixel alpha overrides
per-surface alpha, and colour keying cannot be combined with per-pixel
alpha
Btw, for colorkey’d surfaces, is it sufficient to just compare the
colorkey value with the pixel in question, or do i have to do some
anding first ?
comparing should be enough, unless you have set any of the unused bits
in a pixel (the leftover bit in RGB555 format, or the 8 unused bits
in 32-bit RGB888). SDL should normally keep those bits clean
Trick wrote:
Ok, thanks! (would love to have a 2:2:2:2 RGBA mode btw, or maybe
palettes with alpha
SDL does not support palettes with alpha at the moment since there is
rarely any hardware support for it. Write your own blits for it if you
need it
Ok, thanks again! One more question though … In palettized modes, is
the colorkey value the actual color of the transparent pixel, or the
index to it ? (if it’s the latter it doesn’t need any special
handling, so that’d be great =)
the colour key is always the pixel value (that is, the index in indexed
mode). In other words, it’s what you get from SDL_MapRGB/SDL_MapRGBA
Sam Lantinga wrote:
Hi! Does SDL_Surface (ie. SDL_PixelFormat) support 2-color surfaces ?
Yes, though the format conversion code isn’t very fast, and you can’t
blit to them, only from them.
the support for 1bpp bitmaps is very spotty — a lot of code both in
SDL and outside assume surfaces are at least 8bpp. I’m not sure why
the code is there (historical reasons, Sam?)
There are programs out there that need to be able to blit bitmaps
for one reason or another. The testbitmap test program is an example
that shows how the code works.
Another problem with the 1bpp support is that it makes several implicit
(and undocumented) assumptions on the bitmap format (bit order and bitmap
unit)
True. The code was added for specific purposes (I don’t remember exactly
why, only that it was needed) and hasn’t been widely used otherwise.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga writes:
Another problem with the 1bpp support is that it makes several implicit
(and undocumented) assumptions on the bitmap format (bit order and bitmap
unit)True. The code was added for specific purposes (I don’t remember exactly
why, only that it was needed) and hasn’t been widely used otherwise.
I seem to recall that one good use for bitmaps in SDL is to create an
alpha mask. For example, if one wants to draw only to a circular
region of the screen, one can draw a filled circle in a bitmap (1bpp)
and then apply that as the alpha mask when blitting. I didn’t see any
other easy way to do anything like that.
Derrell
Derrell Lipman <Derrell.Lipman at UnwiredUniverse.com> wrote:
I seem to recall that one good use for bitmaps in SDL is to create an
alpha mask. For example, if one wants to draw only to a circular
region of the screen, one can draw a filled circle in a bitmap (1bpp)
and then apply that as the alpha mask when blitting. I didn’t see any
other easy way to do anything like that.
Since alpha masks aren’t supported, in what way does SDL help you with
this?
(not that it wouldn’t be a useful feature)
“Mattias Engdeg?rd” writes:
Derrell Lipman <Derrell.Lipman at UnwiredUniverse.com> wrote:
I seem to recall that one good use for bitmaps in SDL is to create an
alpha mask. For example, if one wants to draw only to a circular
region of the screen, one can draw a filled circle in a bitmap (1bpp)
and then apply that as the alpha mask when blitting. I didn’t see any
other easy way to do anything like that.Since alpha masks aren’t supported, in what way does SDL help you with
this?(not that it wouldn’t be a useful feature)
Caveat: I haven’t yet implemented to this. However, the scheme that I
came up with involved the functions in SDL_blit_0.c; specifically the
function BlitBtoNAlpha() (as retrieved by calling the public function
SDL_CalculateBlit0(surface, 2). I think I found that I might need
some non-standard wrapper functions, but that I could create an alpha
"mask" by blitting a pixmap to a surface using this function.
Am I way off base, or is the concept sound?
Derrell
Derrell Lipman <Derrell.Lipman at UnwiredUniverse.com> wrote:
Caveat: I haven’t yet implemented to this. However, the scheme that I
came up with involved the functions in SDL_blit_0.c; specifically the
function BlitBtoNAlpha() (as retrieved by calling the public function
SDL_CalculateBlit0(surface, 2).
BlitBtoNAlpha just copies a 1bpp surface to a >8bpp surface, blending each
pixel by a constant per-surface value. It’s probably not what you are looking
for
SDL has no support for anything of the kind. I’m considering allowing
general destination alpha mask for 1.3 (probably RLE coded for
software, and accelerated for hardware), but I won’t add anything like it
to 1.2
This is exactly what i’m planning to do. In the library i’m making,
SDL_sgf (Simple GUI Framework), i have multiple shape types that the
cursor might be inside. One of these are the MASK type, which will
detect whether the cursor is in the supplied mask.
I was thinking of using SDL_Surface for this shape type, since then i
could make the mask work with colorkey’d and alphachannel’d surfaces
in addition to this simple bitmask, without much extra work.
Now that i know it’s supported i’ll start using it =) One question
though: Is the [RGB].* members used in 1-bit surfaces (if so, how ?)
Btw, if they’re not, maybe they could be used to define the bitorder ?On Tuesday 25. September 2001 18:50 (CEST), you wrote:
Sam Lantinga writes:
Another problem with the 1bpp support is that it makes several
implicit (and undocumented) assumptions on the bitmap format
(bit order and bitmap unit)True. The code was added for specific purposes (I don’t remember
exactly why, only that it was needed) and hasn’t been widely used
otherwise.I seem to recall that one good use for bitmaps in SDL is to create
an alpha mask. For example, if one wants to draw only to a
circular region of the screen, one can draw a filled circle in a
bitmap (1bpp) and then apply that as the alpha mask when blitting.
I didn’t see any other easy way to do anything like that.
–
Trick
Linux User #229006 * http://counter.li.org