Re: [AD] "blend color" is wrong

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


On Sun, 2010-06-13 at 18:55 +0200, Elias Pschernig wrote:
> 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.
> 

Ok, I committed this now. Besides the obvious drawback above (need to
pass along your own tint color since Allegro won't keep a color in the
display any longer) it seems the direct parameter is much clearer.

I'm already prepared to much scolding on allegro.cc for breaking the API
in such a major way at this point, but it's just inevitable to break
things from time to time. Even our great founder was breaking XNA this
year already:

http://blogs.msdn.com/b/shawnhar/archive/2010/03/16/breaking-changes-in-xna-game-studio-4-0.aspx

I think we should go the same route for Allegro 5.2 btw. - publish a
list of things you need to change when upgrading from 5.0 (but do break
compatibility where it makes sense) instead of trying to stay compatible
at all cost and have a more and more messy API. (Ignoring the fact that
we can't really compare A5 to XNA... one is just a small hobby project
the other a big game dev framework...)

Anyway, the other complaint of course could be that we should have
broken the API with the 5.2 release and not now in the beta phase of
5.0. But since nobody vetoed it in this thread and there isn't even a
final release date for 5.0... :)

-- 
Elias Pschernig <elias.pschernig@xxxxxxxxxx>





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