Add `al_blend_color`

[SiegeLord]

al_blend_color(ALLEGRO_COLOR c1, ALLEGRO_COLOR c2, float factor)

Note that this should go via the linear space (i.e. internally it'd call al_color_rgb_to_linear, blend and then convert back).

Optional: Add a version that does not do the sRGB conversion, although I can't imagine it being useful that often. Allegro colors are sRGB, and should be treated as such.

[SiegeLord]

We could call it al_interpolate_color, so avoid confusion with the blenders, although I don't think it's a huge deal with proper documentation. Note, that I expect the outputs to be the same for equivalent blend modes (i.e. ADD + appropriate alphas).

[MarkOates]

My preference for the name is the al_mix_color() with al_mix_color_*() variants that danielh suggested.

I like that it suggests "mixing" in a general sense, enough that it could encapsulate different mixing concepts like *_gama() or *_with_blending(). Also, I like that al_mix_color() is concise and light, where _interpolate is a bit much to type.

It also happens to match the GLSL mix() function, which would do the same thing.

ChatGPT:

al_blend_color → This can be misleading because "blend" already has a specific meaning in Allegro (and graphics APIs in general): blending is about combining source and destination pixels based on blending modes. Using blend might confuse users into thinking it interacts with Allegro's blending system rather than just interpolating values.

al_mix_color → This feels casual, but it doesn't immediately communicate that the function performs interpolation. "Mix" could imply averaging, but not necessarily linear interpolation.

al_interpolate_color → This is the clearest and most precise. It conveys that the function will compute an interpolated value between two colors given a parameter (e.g., t in [0,1]). Developers familiar with linear interpolation (lerp) will immediately know what to expect.

[SiegeLord]

Sure, we can go with al_mix_color