RE: [AD] Faster hsv_to_rgb()

["AE" <ae-a@xxxxxxxxxx>]

>-----Original Message-----
>From: alleg-developers-admin@xxxxxxxxxx
>[mailto:alleg-developers-admin@xxxxxxxxxx Behalf Of aj
>Sent: 16 April 2003 08:30
>To: alleg-developers@xxxxxxxxxx
>Subject: Re: [AD] Faster hsv_to_rgb()
>
>
>is there any chance you'd like to optimz the  rgb_to_hsv()   ;)


Not in the way I optimised hsv_to_rgb(), which involved re-arranging the
expressions so they use fewer arithmetic operators to compute. However, by
looking at the code of rgb_to_hsv(), there are several divides that could be
eliminated if the RGB paramaters were from 0-1 instead of 0-255, and a
multiply could be removed if the Hue was in the range 0-6. This would break
the code so I wouldn't change them.

I have written my own super-optimised version of hsv_to_rgb() that's even
faster than what I submitted, but that breaks the code. Basically, all the
paramaters are in a 0.8 fixed-format number (ie. from 0.00 to 0.FF), except
hue which is in the range 0.00 to 5.FF. RGB paramaters could still be used
in their existing format as 0-255 in 8.0 fixed point numbers becomes 0-0.FF
if we interpret the byte as 0.8 format. Using paramaters in this range,
there is no need to do a conversion to the function's internal range.

One nice thing about 0.8 fixed-point numbers is that I can make a 64K
multiply lookup table for all values from 00-FF (they're one byte each).
This eliminates any multiplies from the code, but reduces the accuracy of
the results, but in the program I've tried it in, the results look fine.

Do you think Allegro has a need for seperate faster but less accurate
RGB<->HSV functions that use a different paramater-space, or should it be up
to users to add their own versions of these functions? I do plan to release
the sourcecode to the project I'm working on when it's finished.


AE.