New Surfaces never have alpha channel
Reported by Trickster | June 19th, 2008 @ 01:17 AM | in Surface & Rect
I've noticed this for a long time, but I was playing with it today.
When you create a surface with the Rubygame::SRCALPHA flag, the returned surface never has an alpha channel.
That is if I run this code
@surf = Surface.new([16, 16], 32, [Rubygame::SRCALPHA])
surf2 = @surf.to_display_alpha
p @surf.flags
p surf2.flags
0 and Rubygame::SRCALPHA is printed
but after some investigating the reason why flags was returning 0 even though Rubygame::SRCALPHA was sent as a parameter was because for the masks you just got them from the screen and the Amask for the screen was 0, which means no alpha channel.
But this isn't a big a deal since you can just call to_display_alpha or set_alpha(255)
but masks should be a parameter, since you can create a Surface with depth != screen.depth or something obscure like depth = 15 and masks = [0x7C00, 0x02E0, 0x001F, 0x0000], and its default should be the screen's masks or something.
This way they can configure the surface as they see fit.
Comments and changes to this ticket
-
John Croisant July 18th, 2008 @ 02:14 AM
- → State changed from “new” to “open”
- → Tag changed from “” to “@bug surface”
- → Milestone changed from “” to “Surface & Rect”
I'm extremely hesitant to add a parameter that's so obscure and low-level.
The correct mask values can vary from platform to platform (depending on which endian they are), and also vary with the desired Surface depth. Rubygame doesn't expose this sort of low-level information through its API, so there's no good way for an application to calculate what the correct masks should be for the current platform.
So, I do think that Surfaces lacking an alpha mask is an important issue. But it calls for a better solution than manually specifying masks.
My current best idea is to make Rubygame set the alpha mask automatically, based on the depth, the system endianness, and whether the SRCALPHA flag was given. I think that should address the issue properly.
I'm not sure when this change would roll out, though. I don't think in 2.4. I'll mark it for the "Surface & Rect" release sometime in the future.
-
Trickster July 19th, 2008 @ 03:07 PM
Hmm I now see that endian order would be a problem if it were included.
But this ticket (the title) was just a thought seeing as though the alpha was broken
also I don't think that depth would be much of a problem as the most common depths are 32, 24, 8 more obscure ones are 15 and 16. I've really haven't seen another value for depth being used.
And for endianness something like this would do
#determine masks from depth given #if SDL_BYTEORDER == SDL_BIG_ENDIAN #leave masks alone #else #reverse masks #endifor maybe I'm mistaken.
And yeah sorry I am annoying you with all of these tickets ;)
-
John Croisant July 19th, 2008 @ 03:29 PM
- → Title changed from “Surface.new should have masks as an optional argument” to “New Surfaces never have alpha channel”
I don't think there's any compelling reason for the user to specify masks for the Surface. It's inconvenient for the user and increases the chance of error, and I don't see what benefit it has over automatically calculating the correct masks.
P.S. Don't apologize for all the tickets. Tickets is what the bug tracker is here for! ;)
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Flexible library for making games with the Ruby language.
rubygame.sourceforge.net
