Re: [AD] About Elias' bug

["Elias Pschernig" <eliaspschernig@xxxxxxxxxx>]

> This time I tried to mix your approach and the current code. As a result, I
> get almost no slowdown in normal conversion mode. Moreover, I used the
> special loop structure to implement the KEEP_TRANS flag, so as a bonus the
> code runs faster in several modes when compiled with GCC (15-20 % on my
> machine). I don't think this will hurt other compilers... and GCC rules :-)
> 
> 24->15                   normal  dither  keep  keep+dither
> Allegro 3.9.37 CVS        43.4    19.1    n/a      n/a
> patched                   43.2    15.1    21.7    14.8
> 

I've just been running my test program and got this (mingw):

24->15                   normal  dither  keep  keep+dither
Allegro 3.9.37 CVS         494     158    n/a      n/a
patched (blit3.diff)       438      97    151       95  

The patched-normal has almost no speed loss (might be inside the accuracy of my timing function), and the patched-keep is a bit slower than with the blit2.diff.

Also, I noticed that my test program crashes with the blit3.diff, whenever I try to convert from 8bit to any other color-depth. (It may be a bug in my program, but I couldn't find anything yet)

I was thinking about the function get_replacement_color() - it's probably easier to just define the replacement color as makecol(255,1,255) for true and makecol(255,8,255) for highcolor. If makecol is changed to never return 0 in palette modes, then there a standard makecol will get a replacement as well. So it seems to be overkill to keep the function :)

Elias Pschernig