[AD] patches for color.c and graphics.c (was: Re: 4.2.1)

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

Elias Pschernig wrote:
On Thu, 2006-11-23 at 23:58 +1100, Peter Wang wrote:
Also, I notice that the patches I submitted on 25-01-2006 ( http://sourceforge.net/mailarchive/message.php?msg_id=14585796 ) for color.c and graphics.c were not included in either 4.2 or 4.3. Was it decided not to include them, or has someone just forgotten to apply them?
I seem to have a vague recollection that Elias looked into the color.c
patch?  I'm not considering the patches for 4.2.1.

Ah, yes, I remember now. Looking at the thread
http://sourceforge.net/mailarchive/forum.php?thread_id=9484132&forum_id=34599 it seems my conclusion was there's no point, after making a test image ( http://allefant.sourceforge.net/pics/allegro/palette.png - left/right halfes of each gradient are before/after).. and I can only even see the separation line when zooming in 10 times and looking at my monitor from the side for a while.

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.


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