Re: [AD] memory bitmap blending

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Sat, 2008-11-29 at 15:46 +0100, Elias Pschernig wrote:
> 
> I think now, the formulas need to be:
> 
> r = dr * dst + sr * src * color.r * color.a
> g = dg * dst + sg * src * color.g * color.a
> b = db * dst + sb * src * color.b * color.a
> 

That's also no good. And playing a bit more with ex_blend2, the formula
and what is currently implemented don't match anyway. My favorite
formula now is even simpler, excluding the blend color completely:

r = dr * dst + sr * src
g = dg * dst + sg * src
b = db * dst + sb * src
a = da * dst + sa * src

And the blend color, conceptually, is multiplied with the source color
before anything else (so "src" and "dst" may include it as well). What
it means is, if I want to draw a 50% transparent Mysha, what I do is:

al_set_blender(ALPHA, INVERSE, {1, 1, 1, 0.5})

Just as it already happens to work. I'll update the documentation
accordingly if nobody complains.

This only leaves the issue of modifying destination alpha in a way which
usually is not desired. OpenGL apparently solves this by having two sets
of blenders, one for color components and one for alpha. For example:

glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
    GL_ONE, GL_ONE);

Would allow drawing with alpha blending to a destination which also has
alpha, but with the alpha channel adding up (which is what you would
expect). The usual:

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)

indeed does weird things if you have destination alpha just as A5
currently does in ex_blend2 - but without using FBOs simple OpenGL
applications don't deal with destination alpha, so it's what everyone
seems to use.

Now for A5, I think the best way is one of the following two options:

1) Keep the current way, and say destination alpha already is complex
enough that you should not use A5 blending any longer, but fragment
shaders (our design goal after all was to only support a few simple,
common blending operations and defer everything else to shaders - no
idea if blending two alpha bitmaps together can be considered a common
operation)

2) Provide something identical to OpenGL:

al_set_separate_blender(src, dest, alpha_src, alpha_dest, color)

and al_set_blender would just be a shortcut which has alpha_src=src and
alpha_dest=dest.

It shouldn't be hard to implement - just add two more blender variables
to the state for alpha, replace glBlendFunc with glBlendFuncSeparate for
the OpenGL implementation, do something analogous for DirectX, and
update the memory blenders.

-- 
Elias Pschernig <elias@xxxxxxxxxx>





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/