|
[a5 rc4] anomalous blending |
Mark Oates
Member #1,146
March 2001
|
Since switching to RC4 (from 4.9.22) I noticed my images were not blending the same as they were before while in different opacities. I recreated the problem thusly:
RC4
this is default with no function call to change the blender: This is after a call to al_set_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA); to 'draw it normally'. RC1It looks like the change happened somewhere between RC1 and RC3, I don't have a copy of RC2 that I could test it out with. Under RC1, it seems like the blending is correct. While in default: a call to al_set_blender(ALLEGRO_ADD, ALLEGRO_ONE, ALLEGRO_INVERSE_ALPHA); Here's my code: 1#include <allegro5\allegro5.h>
2#include <allegro5\allegro_image.h>
3#include <allegro5\allegro_color.h>
4
5
6void main()
7{
8 al_init();
9 al_install_keyboard();
10 al_init_image_addon();
11
12 ALLEGRO_DISPLAY *display = al_create_display(1024, 768);
13
14 ALLEGRO_BITMAP *b = al_load_bitmap("not_sure.png");
15 ALLEGRO_BITMAP *b2 = al_load_bitmap("donk3.png");
16 ALLEGRO_BITMAP *background = al_load_bitmap("background.png");
17 if (!b) return;
18
19 ALLEGRO_COLOR color = al_map_rgba_f(1, 1, 1, 1);
20
21 // comment/uncomment as necessary
22 //al_set_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA);
23 //al_set_blender(ALLEGRO_ADD, ALLEGRO_ONE, ALLEGRO_INVERSE_ALPHA);
24
25 do
26 {
27 al_clear_to_color(al_color_name("darkblue"));
28
29 al_draw_tinted_bitmap(b, color, 100, 100, 0);
30 al_draw_bitmap(b, 100, 200, 0);
31
32
33 for (int i=0; i<=5; i++)
34 {
35 color = al_map_rgba_f(1, 1, 1, i*0.2f);
36 al_draw_tinted_bitmap(b2, color, -50+i*175, 400, 0);
37 }
38
39 al_flip_display();
40 } while (true);
41}
I also attached the two images I used. I also tried al_set_new_display_flags(ALLEGRO_OPENGL); but it made no difference. -- |
Matthew Leverton
Supreme Loser
January 1999
|
Sorry, didn't really even read your post. Is this a pre-multiplied alpha thing? There's a bitmap flag to disable that. |
Mark Oates
Member #1,146
March 2001
|
Why would I, by default, want an image at 0 opacity to be visible? [edit] al_set_new_bitmap_flags(ALLEGRO_NO_PREMULTIPLIED_ALPHA); // load images heaurh al_set_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA); How 'bout we add al_set_display_flags(ALLEGRO_DISPLAY_NOT_UPSIDE_DOWN) while we're at it? -- |
Matthew Leverton
Supreme Loser
January 1999
|
There's a confusing explanation at al_set_new_bitmap_flags(). Personally, I wouldn't have changed Allegro to work this way by default, even if it is better to those who know what they are doing. |
Mark Oates
Member #1,146
March 2001
|
Images that you intend to be additive shouldn't have alpha data in them, regardless. It seems to me that it's an attempt to make additive images with alpha work with alpha, which they shouldn't. I vote we change it back. [edit] or at least make the default behavior as described above. -- |
Matthew Leverton
Supreme Loser
January 1999
|
Mark Oates said: Images that you intend to be additive shouldn't have alpha data in them, regardless. I agree; it just seems weird from my perspective as a casual 2D game programmer. I don't mind Allegro supporting pre-multiplied alpha, but I would make it opt-in via ALLEGRO_PREMULTIPLIED_ALPHA. And I think (ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA) makes for a better default blending mode. Anyway, I assume this was discussed on the AD mailing list. You could search it to find all the reasoning behind making this the default mode. |
Elias
Member #358
May 2000
|
The problem with ADD/ALPHA/INVERSE is mainly that it breaks when you turn filtering on (and also when you draw to intermediate alpha bitmaps). I got convinced that it's a better idea to have ADD/ONE/INVERSE by default when I read Shawn Hargreave's explanations [1] [2] why he changed the default blending mode in XNA 4 to just that (breaking all older XNA code by doing so ). The easiest explanation to justify the change is to just say it's the way both OpenGL and DirectX do blending - except for the special case of completely unfiltered blitting directly to a non-alpha target you won't be happy with non-premultiplied alpha. The donkey seems to be drawn correctly. If you do this: al_set_blender(ADD, ONE, INVERSE); al_draw_tinted_bitmap(donkey, {1, 1, 1, 0}, x, y, 0); Then it means the source alpha is 0 for every pixel due to the tinting, so you fully keep the blue background and then just add the r/g/b values in the source to it. To draw the donkey completely transparent, instead do this: al_set_blender(ADD, ONE, INVERSE); al_draw_tinted_bitmap(donkey, {0, 0, 0, 0}, x, y, 0); To draw it at exactly 50% of its normal transparency, do this: al_set_blender(ADD, ONE, INVERSE); al_draw_tinted_bitmap(donkey, {0.5, 0.5, 0.5, 0.5}, x, y, 0); This last version above may look similar to using the version below (assuming no premultiplied alpha below): al_set_blender(ADD, ALPHA, INVERSE); al_draw_tinted_bitmap(donkey, {1, 1, 1, 0.5}, x, y, 0); However this will break completely when you turn on filtering. Look at ex_filter and ex_premul_alpha to see why this will probably matter in most games. With premultiplied alpha you can do anything you can with non-premultiplied just as easily (for tinted drawing, simply multiply the r,g,b values you pass with the alpha yourself) but, the big advantage, things won't randomly break when you turn on filtering (or draw to an intermediate bitmap). It also will be like other libraries do it (XNA, OpenGL, DirectX, and likely also things like Flash or HTML5 which do filtering by default and so have little choice). -- |
Mark Oates
Member #1,146
March 2001
|
Alright, I'm down. It sure is wack at first, and I wouldn't have recommended changing it in an RC ( ), but it does solve more problems at the cost of (r*a, g*a, b*a) in tinting. So everything has the same appearance as before, except:
We gain:
Leave everything in default, and all you have to do differently is:
Right? [edit] perhaps a PREMULTIPLIED_TINTING may be helpful? [edit2] hmmm... subtractive blending is a challenge, now. -- |
Elias
Member #358
May 2000
|
Mark Oates said: [edit2] hmmm... subtractive blending is a challenge, now. I never tried it or thought about it, but is it really much different? In fact as long as bitmaps you blend additivly/subtractivly contain no alpha, nothing at all should change. -- |
|