Re: [AD] patches for color.c and graphics.c

[Robert Jr Ohannessian <rohannessian@xxxxxxxxxx>]

I think we should switch to round(x * 255.0 / 63) (or strictly 
equivalent non-floating point function), to match every other reasonable 
graphics API (and hardware) on the planet.

The expected behavior for conversions from fixed-point basis X to 
fixed-point basis Y is usually: fixed-point basis X to normalized float, 
followed by normaled float to fixed-point basis Y.

Thus for 6-bit to 8-bit, you need to first divide by 63.0 to get a 
number in the range 0.0 to 1.0 (inclusive!) and then multiply by 255 to 
scale it up to 8-bit.



Peter Wang wrote:
> On 2006-11-30, Andrei Ellman <ae-a-alleg@xxxxxxxxxx> wrote:
>
> > Even though there is no perceptible difference in the PNG between the 
> > two methods of converting 6-bit to 8-bit, I still think my patches 
> > should be applied for the following reasons:
> >
> > + With the shifting method, the progression of values will be linear. 
> > Using an integer-divide creates a progression of values with a slight 
> > curvature.
> > + create_blender_table() will work faster - especially on older 
> > processors where multiplies and divides are expensive.
> > + Using shifts will make the code consistent. _set_colorconv_palette() 
> > currently uses shifts, which means that there is currently an 
> > inconsistency in the way that Allegro converts 6-bit values to 8-bit vales.
> >
> > I think that the last point is particularly important, as for a given 
> > 6-bit input, the 8-bit result should always be the same.
>
>
> Agreed.  I'll commit it.
>
> Peter
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV