I'm making a program that manipulates the color channels of a bitmap separately. So I can paint on more red without changing any green, blue or alpha for example.

Here's code for painting on more red using the filled circle primitive.

al_set_target_bitmap(my_bitmap);
al_set_blender(allegro5.color.ONE, allegro5.color.ONE, al_map_rgba_f(1, 1, 1, 1));

allegro5.primitives.draw_filled_circle(x, y, 10, al_map_rgba_f(0.2, 0, 0, 1));

al_set_current_display(my_display);
set_blender(allegro5.color.ALPHA, allegro5.color.INVERSE_ALPHA, map_rgba_f(1, 1, 1, 1));

My problem now is that I wanna be able to reduce the amount of red too. But it seems there's only funcionality in place to let me add color.
Is there a way to erase some red from the bitmap?

Since OpenGL and D3D don't have subtractive blending without extensions, neither does Allegro. You'll have to find another way.

I've been thinking about it, and can't find a way.

What extensions are you talking about?
And does anyone have a different solution?

EDIT: I do know it's possible to blend in a darker color over something brighter. But the regular way to do that is by using the alpha channel for translucency and that means it will pull down r, g and b.

I just wish I could do that but only affect one color channel. :/

If I understand you correctly, using glColorMask will do the trick under OpenGL. While I'm sure this is also possible to do in D3D, this sort of function is unlikely to show up in Allegro itself since it'd require changing a megaton of code.

(Emphasis mine)

glColorMask() turns a particular RGBA element off entirely

I was thinking of masking off the green/blue channels and writing a new colour to the red channel... but I guess the reduction was meant more in the subtractive sense, than the setting to a lesser value sense I took it in

Nevermind then. Use a shader.

I'll take a look on colormask, maybe it can solve the problem. At least enough to meet my needs.

As for the shader route, I looked into that and it turns out blending takes place after your shader. So the blending stage isn't programmable and I've seen conflicting opinions about the readability of the rendering target which I think is required if I want to blend incoming fragments with what's previously on the target.

I guess Allegro 5 doesn't have get/putpixel.

The rendering target should always be readable in a shader, AFAIK... what good would they be if not? So instead of doing the blending stage, you do your blending in the shader. Luckily they're very fast.

Sure it does:
http://alleg.sourceforge.net/a5docs/refman/graphics.html#al_get_pixel
http://alleg.sourceforge.net/a5docs/refman/graphics.html#al_put_pixel
http://alleg.sourceforge.net/a5docs/refman/graphics.html#al_draw_pixel

so...he should make a blender function himself with it.

I guess I can assume it has the getr/getg/getb and rgb_to_hsv etc.

That's an awful slow way to do it. The get/put pixel functions are a bit slower than in 4.4. This is what shaders are meant for.

Don't guess, just read the manual.

Anyway, yes, you probably can do it that way. But it doesn't play nice with the hardware, as Trent said. It's the Allegro 4 way of doing things, but Allegro 5 is (will be) a different thing entirely.

The reasons for not bringing up getpixel/putpixel functions are these:
I fear it's rather slow. (minor reason, I could maybe live with it)
I'd have to code my own primitives rendering.
I was already aware of this approach and felt it was such an obvious option we don't even need to discuss it.

Having the rendering target available from shader is not at all an obvious feature. The incoming graphics in almost all situations has no need to know what's already been rendered. The shaders purpose is to determine how lighting and colors are handled on the current fragment without any consideration to what else is in the scene.

The fixed shader that you get in opengl sucks actually. For example, it barely handles specular so you get a diamond shaped lighting around vertices that get affected by specular. Just by coding a very basic shader you get much smoother shading.

Maybe you could glCopyPixels to/from a memory buffer and fiddle with the red component on your own.

How is that supposed to be able to handle blending, shadows and whatnot? Without knowing what is already there, you can't do any real fancy effects.

If you're doing all that, aren't you using lighting? Just change the lights...

The shader doesn't do blending, blending takes place in a later stage that's not programmable.

I don't know much about shadows, it's something about stencils and stuff.

Uh, why can't you do blending in a shader? I thought that was most of the reason for shaders. To implement awesome things that the fixed function stuff couldn't even dream of.

Trekzer, you're just trying to draw primitives in a window like MS-Paint?

No I'm working on a heightmap editor. The heightmap uses the color channels of one texture (splat texture) to blend four different textures. (This is different blending, I'm not blending with the target, only the textures which are used for the fragment that comes into the shader)

So for the editor, I al_set_target_bitmap(splat_texture) and paint the color channels, which makes it look like I'm painting textures onto my heightmap.

Anyway, I've tried glColorMask now and it works perfectly. At least rgb works just as I want, now I just need to figure out how to paint the alpha channel.

That's way beyond any bitmap-based heightmap I've ever done. I just used the int as a height so viewing the "image" would resemble a contour map.

The heights aren't controlled by any bitmap, only the texturing of it.
Here's an explanation.
http://www.gamedev.net/reference/articles/article2238.asp

For the height points I'm just using arrays now, haven't even gotten around to saving it to any file format.