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

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> I guess it depends on how solid we want makecol to be. Currently, it doesn't
> do any bounds checking....

I personally don't mind this behaviour: we're not supposed to check every single argument
that we are passed, unless we want to slow down everything. The docs clearly state
"Converts colors from a hardware independent format (red, green, and blue values ranging
0-255)".

> However, these are the color convertors, and should draw on screen what the
> user should be seeing (i.e.: it's an actual bug).

...provided that the user uses a correct color format to talk to them.

> BTW, are there any plans on merging the blit color convertors with the
> windowed ones?

What do you mean exactly by merging ? The windowed color convertors are fast functions
that use hard-coded formats, whereas the blit color convertors are slower but much more
flexible (programmable format, special feature like dithering and transparency preserving,
support for banked VRAM). The only thing we can do is to redirect the latter to the former
if the necessary requirements are met. There are also the custom color convertors of the
Unix X11 driver, which are roughly in the middle.

I actually started to code an unified color convertor API some time ago (stalled for the
time being) that implements this idea (redirecting). I'll try to post a sketch in the near
future.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx