Draw_set_blend_mode Game Maker Studio 2

How Blend Modes Work

Extended blend modes are the source of more mystery than almost anything in the Game Maker arsenal. They are in fact completely logical and very straight-forward. Once you understand how they operate, you should have no trouble predicting what any particular blending mode will do.

It's all mathematical. The use of the term "factor" in the help file is the clue but it doesn't go into nearly enough detail.

Each extended blend mode has two factors, defined by the two arguments of the draw_set_blend_mode_ext function. The first factor is for the pixels being drawn (the source) and the second is for the existing pixels being drawn to (the destination). The source pixels can come from any drawing command, such as drawing sprites or primitives. The destination pixels can be the back buffer (the screen) or a targeted surface.

For the purposes of blending, color channels (Red, Green, and Blue) are thought of as holding values from 0.0 to 1.0, rather than from 0 to 255.

Let's start with normal blending, the default blend mode of Game Maker:

            Expand            draw_set_blend_mode_ext(bm_src_alpha, bm_inv_src_alpha);

Looking at the chart above:

bm_src_alpha: Blend factor is (As, As, As, As).

bm_inv_src_alpha: Blend factor is (1-As, 1-As, 1-As, 1-As).

The chart says the blend factor of bm_src_alpha is (As, As, As, As). What does this mean? Each of those four values ("As") represent factors for the four color channels (Red, Green, Blue, Alpha). The factor "As" means the Alpha of the Source pixels. The first letter refers to the color channel, and the second letter refers to the source or destination pixels. By "factor" we mean multiply; we are going to multiply each color channel of each of the source pixels by this factor.

Likewise, we are going to do the same sort of operation to the destination pixels, only using the bm_inv_src_alpha (1-As) factor instead. When a blend factor has "inv" (inverse) in the name, it means it subtracts the indicated channel from 1.0 (thus light becomes dark, and dark becomes light).

The results of these two operations are then added together to form the final image.

Here's the entire normal blending operation expressed mathematically:
Source Destination Resulting Pixels Pixels Pixels [Rs] * [As] + [Rd] * [1-As] = new Red [Gs] * [As] + [Gd] * [1-As] = new Green [Bs] * [As] + [Bd] * [1-As] = new Blue [As] * [As] + [Ad] * [1-As] = new Alpha

... and visually:

What's going on here is the alpha mask of the sprite is being used to (1) erase the background of the Mario sprite, and (2) erase the area in the existing image where Mario will appear. Now when these images are combined, there will be no interaction between the two. The isolated elements will fit together perfectly. This is obviously a very useful blend mode for games, which is why it's the default. Here's an example of the math in action. Let's say the pixel we are drawing is Mario's red shirt (#F84070) against a brown background (#C89858). Since this is part of Mario, we know the alpha is 100% for this pixel. The background is also fully opaque.
Source Destination Resulting Pixels Pixels Pixels [0xF8] * [1.00] + [0xC8] * [1-1.00] = new Red [0x40] * [1.00] + [0x98] * [1-1.00] = new Green [0x70] * [1.00] + [0x58] * [1-1.00] = new Blue [1.00] * [1.00] + [1.00] * [1-1.00] = new Alpha

[0.97] * [1.00] + [0.78] * [0.00] = 0.97 [0.25] * [1.00] + [0.60] * [0.00] = 0.25 (#F84070) [0.44] * [1.00] + [0.35] * [0.00] = 0.44 [1.00] * [1.00] + [1.00] * [0.00] = 1.00

The resulting pixel is the color of the shirt. Not surprising, I know, but the math shows us why. Now, what happens when Mario is not fully opaque? Let's try his blue overalls (#408098) at 60% alpha against the same background.
[0.25] * [0.60] + [0.78] * [0.40] = 0.46 [0.50] * [0.60] + [0.60] * [0.40] = 0.54 (#75897F) [0.60] * [0.60] + [0.35] * [0.40] = 0.50 [0.60] * [0.60] + [1.00] * [0.40] = 0.76

As expected, we have a blend of the two colors, a sort greenish-gray. Take special notice of the resulting Alpha: 0.76. Normally, when drawing to the back buffer, this is ignored. The game window is always 100% opaque, after all. However, when drawing to a surface this becomes extremely important. If we were to repeat the last operation on a surface, the resulting pixels, wherever we drew a transparent Mario, would in fact become partially transparent themselves. Although this effect can appear to be a weird graphical glitch, it is perfect normal. It can be corrected with additional blending operations. We will do that next with some "additive" blending.

Our drawing destination is a surface, the result of the preceeding operation. As noted, some of the pixels have become transparent. To restore them to full opacity, we are going to draw over them with black. Because the blend mode we will use simply adds two color channels together, and because black has a value of 0 for Red, Green, and Blue, it will not alter the destination RGB colors at all (n + 0 = n). The alpha, however, is set to 1.0, fully opaque. Adding this to the existing alpha will guarantee that the result will be at least 1.0. Values above 1.0 (or below 0.0) are clamped. The blend factor we are going to be using is called bm_one which, as you might guess, is equal to 1.0 in the blending equation. We will use it for both the source and destination pixels. The basic bm_add blend mode works similarly (but not identically).
Source Destination Resulting Pixels Pixels Pixels [0.00] * [1.00] + [0.46] * [1.00] = 0.46 [0.00] * [1.00] + [0.54] * [1.00] = 0.54 (#75897F) [0.00] * [1.00] + [0.50] * [1.00] = 0.50 [1.00] * [1.00] + [0.76] * [1.00] = 1.00 (clamped from 1.76)

The color remains the same but now the pixel is fully opaque.

So far all of the blend modes shown have factors that are the same for all color channels. This is not necessarily so. The blend factors with the word "color" in them have different factors for each channel. A common use for these is in lighting engines, the so called "multiplicative" lighting/texture pass. The idea is to draw the shading first, then the textures for the shaded objects second with a multiplicative blend. The colors in the source will be multiplied by the colors in the destination. White shaded areas will show the texture normally, color shaded areas will tint the texture, black areas will remain black. You can see exactly the same effect when you use the image_blend variable to change the color of an instance. The blend factors we will use are bm_dest_color and bm_zero.
Source Destination Resulting Pixels Pixels Pixels [Rs] * [Rd] +[Rd] * [0.00] = new Red [Gs] * [Gd] +[Gd] * [0.00] = new Green [Bs] * [Bd] +[Bd] * [0.00] = new Blue [As] * [Ad] + [Ad] * [0.00] = new Alpha

If the source texture is lilac (#C8A2C8) and the shaded destination pixels are deep saffron (#FF9933):
[0.90] * [1.00] + [1.00] * [0.00] = 0.90 [0.64] * [0.60] + [0.60] * [0.00] = 0.38(#E6602E) [0.90] * [0.20] + [0.20] * [0.00] = 0.18 [1.00] * [1.00] + [1.00] * [0.00] = 1.00

... the result is a darker, coppery color. Observant readers will have noticed that blend mode (bm_dest_color, bm_zero) is exactly the same as (bm_zero, bm_src_color).

Abusing forum power since 1986.