Re: [AD] "blend color" is wrong

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Sun, 2010-06-13 at 09:13 -0600, Trent Gamblin wrote:
> On Sun, June 13, 2010 8:55 am, Elias Pschernig said:
> > So I'm leaning towards option B now. It's the one easiest to describe in
> > the documentation, with no special cases add all: If you want to specify
> > the color of something, that is done (and can only be done) by passing
> > in an ALLEGRO_COLOR parameter.
> 
> I think I agree... here's the scenario I described on IRC which occurs often
> for me, described in pseudo code:
> 
> if (some special case)
>   set tint color // currently blend color
> calculate where to draw
> draw
> 
> Now if we make tinting done through a separate function, it becomes
> 
> calculate where to draw
> if (some special case)
>   draw_tinted
> else
>   draw
> 
> Which seems repetitive to me, and much worse if "draw" is a bunch of
> different calls.
> 
> I think even text drawing it's better with a special al_set_tint_color function
> affecting text (for consistency and scenarios like above)..
> 

Yes, it does make a lot of sense. Fading out the screen or blending to
the next scene are quite common operations and you could do both if we
had a global color. But then it really would have to affect everything
which is affected by blending and transformation, without
hard-to-explain exceptions.

There's some good news though for 5.2 - fragment shaders will allow just
that :)

For now, your special case above could be done like this:

tint_color = solid_white
if (some special case)
  tint_color = color
calculate where to draw
draw_tinted(tint_color...

Basically, nothing says you ever need to use the non-tinted bitmap
drawing functions once we have tinted ones. Could just have a global
ALLEGRO_COLOR variable and always pass it to font and bitmap drawing
functions and then use it like the blend color currently.

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>