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