|
|
|
This thread is locked; no one can reply to it.
|
1
2
|
| al_draw_text with alpha |
|
Mark Oates
Member #1,146
March 2001
 |
For some reason the concept hasn't quite sunk in with all the allegroids, yet. When this thread comes up again, nobody should mention the al_set_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA) and/or the ALLEGRO_NO_PREMULTIPLIED_ALPHA flag as a solution. It does not "return things to how they were before." Specifically, half-opacity is gray, you get text outlines, etc. Those two are not a working solution. (In fact, I think ALLEGRO_NO_PREMULTIPLIED_ALPHA should be removed. The correct solution is "you'll need to multiply all your color components by the alpha value. For example: float alpha = 0.3f; ALLEGRO_COLOR color = al_map_rgba_f(0.7*alpha, 0.3*alpha, 0.6*alpha, alpha); " or, the similar answer using 0-255 values. Thank you. -- |
|
Edgar Reynaldo
Major Reynaldo
May 2007
 |
Mark Oates said: For some reason the concept hasn't quite sunk in with all the allegroids, yet. I haven't used A5 yet, but well personally I just don't get it either. Mark Oates said: The correct solution is "you'll need to multiply all your color components by the alpha value. For example: The problem is, it should work the same way whether you multiply the alpha yourself or whether Allegro multiplies it for you. Using 'filtering' on a bitmap with alpha makes no sense to me, because then the color values in the pixels with zero alpha are used to blend the edges. So you better pick the right color values for your zero alpha pixels, or you're screwed and you get funky outlines. So the real problem is that you can't pick sensible values for zero alpha pixels with filtering because it should be mixed with the background color instead. I'm reading Shawn Hargreaves blogs linked from Elias's response to anomalous blending, and maybe it makes sense and maybe it doesn't. I'm not sure yet. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
|
jmasterx
Member #11,410
October 2009
|
I really think a nice flag which would state weather allegro's color mapping functions will be multiplying the colors for you would be very useful. By this I mean, if the flag is set, a call to al_map_rgba would do: al_map_rgba(r * a, g * a, b * a, a); and would return a pre multiplied ALLEGRO_COLOR. Agui GUI API -> https://github.com/jmasterx/Agui |
|
Mark Oates
Member #1,146
March 2001
|
jmasterx said: By this I mean, if the flag is set, a call to al_map_rgba would do: al_map_rgba(r * a, g * a, b * a, a); I think that's a good idea. Right now, I use these two functions quite a bit: 1static inline ALLEGRO_COLOR color_hex(const char *hex, float a=1.0f)
2{
3 ALLEGRO_COLOR color = al_color_html(hex);
4 color.a = a;
5 color.r *= a;
6 color.g *= a;
7 color.b *= a;
8 return color;
9}
10
11static inline ALLEGRO_COLOR color_name(const char *name, float a=1.0f)
12{
13 ALLEGRO_COLOR color = al_color_name(name);
14 color.a = a;
15 color.r *= a;
16 color.g *= a;
17 color.b *= a;
18 return color;
19}
Some time ago, I had a convenience function: -- |
|
Peter Wang
Member #23
April 2000
|
There would be no problem adding convenience versions of al_map_rgb* which multiply in the alpha component, if only someone could suggest decent names. For now, I create my own makecol.
|
|
jmasterx
Member #11,410
October 2009
|
al_map_premultiplied_rgba ? or a flag and use the same functions Agui GUI API -> https://github.com/jmasterx/Agui |
|
Mark Oates
Member #1,146
March 2001
|
Peter Wang said: if only someone could suggest decent names. I think the al_map_rgb* functions should, by default, multiply the components by the alpha. But, if you ALLEGRO_NO_PREMULTIPLIED_ALPHA then they will not. -- |
|
jmasterx
Member #11,410
October 2009
|
Mark Oates said: I think the al_map_rgb* functions should, by default, multiply the components by the alpha. But, if you ALLEGRO_NO_PREMULTIPLIED_ALPHA then they will not. I was hoping Allegro 5.0.0 was going to work like that. Agui GUI API -> https://github.com/jmasterx/Agui |
|
Mark Oates
Member #1,146
March 2001
|
I haven't completely thought through what else it could affect, but it seems to make sense. Since it's essentially what's happening to a bitmap's colors when you're loading them, it should also happen with the mapped colors. [edit]however, I seem to recall that xma makes you multiply the components explicitly... hmm... -- |
|
Matthew Leverton
Supreme Loser
January 1999
 |
The flag used for bitmap loading is a necessary evil. For colors, it would be another annoying thing I'd have to check for and disable in library code. |
|
Peter Wang
Member #23
April 2000
|
ALLEGRO_NO_PREMULTIPLIED_ALPHA is only a bitmap flag that affects how allegro_image loads images. It has no other bearing. The rest of Allegro really doesn't care if you use the convention or not, which is all it is.
|
|
Mark Oates
Member #1,146
March 2001
|
Peter Wang said: ALLEGRO_NO_PREMULTIPLIED_ALPHA is only a bitmap flag that affects how allegro_image loads images. It has no other bearing. The rest of Allegro really doesn't care if you use the convention or not, which is all it is. Hmm... I see... -- |
|
Evert
Member #794
November 2000
 |
jmasterx said: I really think a nice flag which would state weather allegro's color mapping functions will be multiplying the colors for you would be very useful. It could potentially slow you down quite a bit as well, if you're doing an extra comparison in a tight loop. Peter Wang said: There would be no problem adding convenience versions of al_map_rgb* which multiply in the alpha component, if only someone could suggest decent names.
Agreed. |
|
Elias
Member #358
May 2000
|
Evert said: How about al_map_alpha_rgba()? Or maybe al_map_premultipled_rgba(). In both cases you likely want to keep your custom color functions/macros though so not sure it's necessary. -- |
|
|
1
2
|
) 
