[AD] "blend color" is wrong

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

It all was said on allegro.cc already, but basically, I now think that the color parameter to al_set_[separate_]blender does not really belong there. Comparing to OpenGL, it works exactly like the glColor function in some old OpenGL versions (which has nothing to do with blending) and not at all like the glBlendColor function in newer OpenGL (which we don't support in A5).

So, the proposed change:

Option A:

Add two functions:

al_set_tint_color(ALLEGRO_COLOR color);
ALLEGRO_COLOR al_get_tint_color();

Not sure about the name, maybe just "al_set_color" or more technical "al_multiply_color" would work better. They would set the very same per-display color which right now is set by the blending functions, which would lose their color parameter.


Option B:

Alternatively we could add a color parameter to the bitmap and text drawing functions (the solid primitives already have it). However for bitmap drawing I think it would be a bit awkward having to specity a color every time, so instead a _colored or _tinted variant would mean 5 new functions:

al_draw_tinted_bitmap
al_draw_tinted_bitmap_region
al_draw_tinted_rotated_bitmap
al_draw_tinted_rotated_scaled_bitmap
al_draw_tinted_scaled_bitmap

Each would have an additional "ALLEGRO_COLOR color" parameter added after the bitmap argument.

For text drawing, we had a color parameter in A4 as well, so it would work as additional parameter to all text functions:

al_draw_text
al_draw_ustr
al_draw_justified_text
al_draw_justified_ustr
al_draw_textf
al_draw_justified_textf

Each of those would have an "ALLEGRO_COLOR color" parameter added after the font argument. There would be no per-display color any longer. The solid color primitives would lose the ability to multiply their color - you can already do that yourself.


We always have option C to just leave things as is of course. Below the surface not much would change either way, with option A it simply would be a different API function to specify the per-display color. With option B the color would come as a function parameter instead of from the current display.


So, myself I can't really decide, given how we are in beta stage for 5.0 and the API is more or less frozen and option C would mean the least work it started growing on me while writing this email :) On the other hand now is the last time we can fix this - once 5.2 is out (the missing shaders addon in 5.0  pretty much guarantees we will need it soon) everyone will say this is not enough reason to break compatibility with 5.0 code.