Hello,
as the subject says, i have a problem with setting alpha values for
surfaces. I have attached a (crude, but working) cpp and image file to
show my problem. Basically, I take an image, load it and try to set an
alpha value via SDL_SetAlpha before blitting it. This works fine as long
as the image has no alpha channel itself, but somehow fails completely
if it does. Does anyone have a clue how to solve/circumvent this? Maybe
it is also an issue with the image file itself, I am not too experienced
in this field…
Ulf–
recursive:
see recursive
-------------- next part --------------
A non-text attachment was scrubbed…
Name: test.cpp
Type: text/x-c++src
Size: 857 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060126/676cdcbe/attachment.cpp
-------------- next part --------------
A non-text attachment was scrubbed…
Name: test.png
Type: image/png
Size: 676 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060126/676cdcbe/attachment.png
It’s a limitation of the SDL API/implementation. Supporting alpha
channel and full surface alpha at the same time would add another
bunch of multiplications per blended pixel. (And a couple of more
cases to implement and optimize.)
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Thursday 26 January 2006 23:27, Ulf Lorenz wrote:
Hello,
as the subject says, i have a problem with setting alpha values for
surfaces. I have attached a (crude, but working) cpp and image file
to show my problem. Basically, I take an image, load it and try to
set an alpha value via SDL_SetAlpha before blitting it. This works
fine as long as the image has no alpha channel itself, but somehow
fails completely if it does. Does anyone have a clue how to
solve/circumvent this? Maybe it is also an issue with the image file
itself, I am not too experienced in this field…
So I basically have to use color keys or such? Are there any (sort of
simple) possibilities to globally change the alpha value of the image,
then? If not, I am going to use color keys again.
UlfOn Fri, Jan 27, 2006 at 12:47:11AM +0100, David Olofson wrote:
It’s a limitation of the SDL API/implementation. Supporting alpha
channel and full surface alpha at the same time would add another
bunch of multiplications per blended pixel. (And a couple of more
cases to implement and optimize.)
–
recursive:
see recursive
A simple, quick loop through all the pixels in the image, setting the
pixel alpha would work just as well. This might even be doable with
memcpy or something, depending on how the pixel components are
arranged for alpha images. Color keys are a hack, let’s not propagate
that if we can avoid it.
-JustinOn 1/27/06, Ulf Lorenz wrote:
On Fri, Jan 27, 2006 at 12:47:11AM +0100, David Olofson wrote:
It’s a limitation of the SDL API/implementation. Supporting alpha
channel and full surface alpha at the same time would add another
bunch of multiplications per blended pixel. (And a couple of more
cases to implement and optimize.)
So I basically have to use color keys or such? Are there any (sort of
simple) possibilities to globally change the alpha value of the image,
then? If not, I am going to use color keys again.
It’s a limitation of the SDL API/implementation. Supporting alpha
channel and full surface alpha at the same time would add another
bunch of multiplications per blended pixel. (And a couple of more
cases to implement and optimize.)
So I basically have to use color keys or such?
Yes, colorkey + full surface alpha is supported.
Are there any (sort of simple) possibilities to globally change the
alpha value of the image, then?
It depends on what you need to do. If all you need is some antialiazed
sprites (RGBA) that fade in and out, you might get away with
generating a bunch of frames with their alpha channels scaled by
various amounts. You can do this at load time, so it can be done with
simple and “slow” code.
If not, I am going to use color keys again.
Well, as I said, that should work, but of course, it doesn’t provide
antializaing…
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Friday 27 January 2006 18:44, Ulf Lorenz wrote:
On Fri, Jan 27, 2006 at 12:47:11AM +0100, David Olofson wrote:
Yes, colorkey + full surface alpha is supported.
On second thought: No, I don’t want to reimplement alpha keys. 
Are there any (sort of simple) possibilities to globally change the
alpha value of the image, then?
It depends on what you need to do. If all you need is some antialiazed
sprites (RGBA) that fade in and out, you might get away with
generating a bunch of frames with their alpha channels scaled by
various amounts. You can do this at load time, so it can be done with
simple and “slow” code.
That’s what I wanted to do. I’ll either use different images or do it
manually, then.
Thanks for the answers,
UlfOn Fri, Jan 27, 2006 at 08:05:52PM +0100, David Olofson wrote:
–
recursive:
see recursive
