How about using al_set_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_ONE), and then make sure that both source images have 50% alpha set? Or draw with al_draw_tinted_bitmap with a tint that has 0.5 for all it's values, like is done in this thread: https://www.allegro.cc/forums/thread/612304

This could be tough. As far as I know, most (if not all) GPUs only support certain preset blend settings that you can combine to create your blend operation. I don't think there is an average blend setting, so you'll most likely have to do it manually. One thing you could do: render your whole game into a bitmap, then, whenever you need blending, pass this bitmap (let's call it "destination") and your source bitmap to a shader and do all the blending inside the pixel shader. Oh well, maybe it's not that tough after all. In any case, you'll most likely have to use shaders. I don't think there is another efficient way, unless you consider going with the %50 alpha solution.

How about just using a bitmap without alpha channel as your target bitmap? Effectively this will just not writ anything to the alpha channel at all. If you access such a texture from a shaders, as far as I know, the alpha channel will always return 1.0.

Okay, well first off, the averaging. That isn't a big deal to me, I don't personally use it but it's something that Sphere supports so I'd have to emulate it for full compatibility. It would be very easy to implement if we had an ALLEGRO_HALF blend op:

al_set_blender(ALLEGRO_ADD, ALLEGRO_HALF, ALLEGRO_HALF);

But sadly, such a thing doesn't exist.

The second effect however, is VERY useful, and I personally make use of it in my own Sphere games. Here's the code for Sphere's usual mode of blending:

void Blend3(destT& d, srcT s, int alpha)
{
    d.red   = (s.red   * alpha + d.red   * (255 - alpha)) / 255;
    d.green = (s.green * alpha + d.green * (255 - alpha)) / 255;
    d.blue  = (s.blue  * alpha + d.blue  * (255 - alpha)) / 255;
}

inline void blendRGBA(RGBA& dest, RGBA src)
{
    Blend3(dest, src, src.alpha);
    dest.alpha = 255;
}

This performs traditional alpha blending on the RGB components, but sets any pixels touched to fully opaque. This is useful as it allows you to do stuff like this:

textSurface = new Surface(320, 36, new Color(0, 0, 0, 0));
for (i = 0; i < 3; ++i) {
    font.setColorMask(textColor);
    textSurface.drawText(font, 5, i * 12, textLines[i]);
}

// later on...
textSurface.blit(textbox_x, textbox_y);

When that surface is rendered, only the text is visible and everything else remains transparent. Which in turn allows effects like this:

{"name":"Untitled.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/6\/56129637a2a3df511fc5a2bf70f399c3.png","w":656,"h":519,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/6\/56129637a2a3df511fc5a2bf70f399c3"}

Note the fade-in effect on the end of a line of text. This is done by rendering the text to a transparent surface (which makes the text opaque but leaves the rest transparent), then switching to subtractive blending and drawing a gradient over the line with alpha going from 0 to 255, making the end of the line gradually transition from opaque to invisible. This is a difficult effect to achieve with Allegro at present.

Thinking about this, in case you're going with shaders anyways, you can get this much easier than I described in my previous post. You don't actually even need to render to texture for that. Just set up your blend state as

al_set_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA)

And then, in your pixel shader, just return the unmodified color of a pixel except with the alpha channel set to 0.5. That should already give the desired effect if the blend state is set up correctly and the sprites are drawn in the correct order. Of course you can still render to an RGB bitmap, as described above, to eliminate the the alpha channel in your destination image.

The feature of the pull request is interesting but the pull request itself won' t be acceptable, I'm afraid. Please remove the .gitignore, and add at least one example such as ex_blend_color.c Also does this work on all platforms including the mobile ones as well?

Good to hear you found a useful combination. Cloning an existing engine is hard to do if you want to keep the effects completely identical. I'm glad to hear Allegro has been of use.

We don't have a gitignore. Please don't use git commit -a

Also , you don't have to test yourself, but you'll have to ask others to test this for you. That's where the example program comes in.

You can just unstage the git ignore files, and other files that aren't part of your feature.

And that's where the cli is a much better interface

I think there is an example for the blending already, you could probably add the new mode to that, I think.

IIRC you can just remove entire directories at a time with the CLI.

Maybe I haven't read the thread carefully, but isn't that the reason for using build directories outside your source tree, i. e. out-of-source builds?

The CLI is better. GitHub for Windows is just silly.

I dunno, in my shell I get working scrolling and syntax highlighting/coloring. \o/

Yeah, don't get me wrong, I won't hesitate to drop to bash (NOT Command Prompt) for complex stuff like merges, cherry-pick, bisect (things which are intrinsically serial)... But for normal day-to-day commit and branch creation I find the GUI superior.

We'll just have to agree to disagree here, I think I've derailed the thread enough (which is ironic since it's my own thread, and also because there's a guy with a Thomas the Tank Engine avatar here ).