Re: [AD] Bug in Allegro's color convertors?

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


> We can write back into the screen a 0 value for the alpha channel. Or we
> can change makecol to detect this particular setup. I'd rather not have
> users insert MID(0, x, 255) for every parameter of makecol!

The RGB components clearly range from 0 to 255, so anyone doing something as
much weird as x*y for one of them must AND the result against the
appropriate mask. The overhead of ANDing is pretty low compared to
multiplying, so I think it's sensible to require it from the user.

Moreover that's a very uncommon use of makecol() so I don't think we should
degrade the performances of the color convertors just for this situation.

> What if they're explicitly using makeacol? Then the alpha channel will be
> filled with some info, which we don't want to show, especially not on
> *other* pixels!

We simply don't support alpha channel for video bitmaps, do we ?

> If you can, I'd also like for you to benchmark old vs new convertor on a
> non-MMX system. Although the non-MMX code is 2-2.5 cycles longer, it
> doesn't have partial loads from memory and uses one less memory operation,
> so that may give some performence improvements.

I still can do that, I'll just have to locate my old P200 CPU.

--
Eric Botcazou



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