Hi everyone,
I consistently fail to remember/understand what exact scenario will cause the "alpha channel" bug to pop-up.
Therefore I need to ask you:
- I have a 32-bit game
- I use AGS 3.2.1 (current stable release)
- I imported some PNGs files with a pink background. AGS asked "do you want to use the alpha channel?" I said no (but the issue is the same when I try with "yes").
- In repeatedly_execute_always, I use a DynamicSprite : I get its DrawingSurface, I clear it, then paste the imported sprite into it like this: mySurface.DrawImage (0, 0, graphicID, customTransparency);
And Iget the bug: whenever customTransparency is not exactly 0, the non-transparent parts of the sprite appear pink instead of having their own color and being partly transparent.
What should I change to make it work? Halp mee plez.
PS: I guess it's because I then display the DynamicSprite as he background image of a GUI? Damned.
I am working to fix this now: http://www.adventuregamestudio.co.uk/forums/index.php?issue=424.0
Is this the same issue? I had problems to precisely reproduce this in 3.2.1, instead I am getting a fully-transparent "hole" in the surface where the drawn sprite should be.
I guess I should try setting transparency level > 0?
I cannot test the symptoms you described -- since I entirely switched to a system using no transparency, and instead two different Gui's (I then use the transparency property of the Gui).
I know you're working on that and if you recall I posted a warm THANK YOU in the relevant thread ;) Keep up with the excellent work!
Whenever you draw a sprite with an alpha channel to a transparent Drawingsurface, the semi-transparent pixels will look as if drawn on pink.
The reason - afaik - is that you can only draw something semi-transparent to an already colored surface; you can't make pixels of the surface turn semi-transparent (technically, it should be possible of course, but AGS doesn't do it yet).
The only workaround I can think of is getting the portion of the background beneath the GUI and drawing that to the DrawingSurface first.
EDIT: Whoops, ignore what I said there. I somehow used wrong sprite in drawing. Now when I really use a
translucent sprite, there's indeed a pink.
Spoiler
Okay, I am getting mad at this.
How do you guys make it "semi-transparent pixels ... look as if drawn on pink"? When you say "pink" do you mean, literally, PINK?
I really want to reproduce what you describe there, but I get different result all the time.
What I do, in 3.2.1:
1. Make a 32-bit game.
2. Import a 32-bit sprite with alpha channel having translucent pixels (0 > alpha > 255).
3. Script:
d = DynamicSprite.Create(100, 100, true);
DrawingSurface *ds = d.GetDrawingSurface();
ds.Clear(COLOR_TRANSPARENT);
ds.DrawImage(0, 0, 16, 0); // <---- drawing aforementioned sprite here
ds.Release();
overlay = Overlay.CreateGraphical(20, 20, d.Graphic, false); // also tried "true" with same result
Now, if the dynamic sprite was created without alpha channel, then the imported sprite is drawn over it as 100% opaque.
If the dynamic sprite was created with alpha channel, then the imported sprite is drawn over it as 100% transparent (invisible).
So... what am I missing? how do I get that pink color???
Sorry, but more on this topic...
Quote from: Monsieur OUXX on Fri 20/09/2013 08:57:10
mySurface.DrawImage (0, 0, graphicID, customTransparency);
And Iget the bug: whenever customTransparency is not exactly 0, the non-transparent parts of the sprite appear pink instead of having their own color and being partly transparent.
There are two cases: when the drawing surface you create has alpha channel and when it does not.
The first case is simple: the result should be alpha blending of two surfaces, while the overlaying surface may have additional transparency (although that does not work in AGS anyway, it does not draw anything instead).
The second case - this is the one that causes blending with pink now. But what is the expected behavior for this one?
What is absolutely true - the result cannot be translucent on its own, because the created surface does not "have" alpha channel (well, technically, it does, but AGS "pretends" it doesn't). It may have 100% transparent parts, though (like with magic pink). But what about blended colors? Should they be just copied over (taking their rgb part) as if it was simply opaque sprite drawing, or blended with the destination surfaces using source alpha, while treating transparent parts
on destination as clear color (0,0,0) instead of magic pink?
I think that Calin Leafshade suggested the latter (http://www.adventuregamestudio.co.uk/forums/index.php?issue=424.0). Are there other opinions?
Sorry again, my brain is overworked :-.
This might be a controversial opinion, but I say you should just leave it as is.
If you're telling AGS to alpha-blend two sprites onto a surface that doesn't have an alpha channel (but does use magic pink), you're essentially asking for the impossible. The operation doesn't make sense.
I think it's better to let the result be obviously wrong (with shades of pink), so people will realize their mistake and switch to a drawing surface with alpha channel, than to add special behavior that makes the error less apparent, and therefore harder to pinpoint.
Quote from: Snarky on Wed 25/09/2013 00:17:42
If you're telling AGS to alpha-blend two sprites onto a surface that doesn't have an alpha channel (but does use magic pink), you're essentially asking for the impossible. The operation doesn't make sense.
Well, the thing is that we cannot explicitly ask AGS to "alpha blend" sprite to surface. At the moment there's only one available operation: DrawImage. Which may simply mean "draw as you can".
Maybe it is better to just make opaque copy to surface with no alpha, and wait for the times when DrawImage will have "blend operation" parameter?
What I mean is, if you're drawing a sprite that uses alpha transparency onto a surface that doesn't have an alpha channel, that's not really a well-defined operation (in any part of the surface that was transparent due to magic pink), and the result is always going to be distorted in some way. Even if you did have a DrawImage blend parameter, asking it to blend without alpha still doesn't provide any good answer to how it should treat alpha-transparent pixels.
Quote from: Snarky on Wed 25/09/2013 07:16:40What I mean is, if you're drawing a sprite that uses alpha transparency onto a surface that doesn't have an alpha channel, that's not really a well-defined operation (in any part of the surface that was transparent due to magic pink), and the result is always going to be distorted in some way. Even if you did have a DrawImage blend parameter, asking it to blend without alpha still doesn't provide any good answer to how it should treat alpha-transparent pixels.
Hmmmmmm.... right.
Perhaps, in any way, there should not be any "special" way to handle magic pink on destination surface, because that would mean we would take it differently depending on whether we blend an image over or drawing this image itself (using magic pink as transparency).
So, I think, for now we are to define the "default" operation for DrawImage to use when painting RGBA with RGB. Two possible options are:
1) Plain copy RGB (discard source alpha);
2) Standard rgba->rgb alpha blend (ignoring destination alpha): this will produce pink hues on magic pink.
(2)
Because then it will work correctly when you're drawing onto the background. (Actually I don't know whether Room.GetDrawingSurface() gives you a surface with our without an alpha channel, but I assume without, since it doesn't really make sense for any part of it to be transparent.)