Re: [AD] About Elias' bug |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> I've just browsed the story. I think we should try to find a solution,
> because transparency needs to be preserved through color conversion.
>
> So far Elias has proposed two solutions:
> - testing color value on a per-pixel basis: minimal amount of added
code,
> but huge slowdown for every blit() between color formats,
> - brand new blit_keep_trans() function: in order not to duplicate the
whole
> blit.c file, the function has to be very generic, hence very slow.
>
> I think we shouldn't bear the first solution in mind, because it
> definitively costs too much.
It depends on where the function is used. I remember posting some timing
info which showed that my functions still run at 60% of the original in
worst case (most fast blit() otherwise). In a recent thread you was
discussing color-conversion in windowed modes (which is not using blit),
so i have the impression there never is the need to colorconvert-blit()
in real time ?
> Would it not be more efficient to use a two-pass color conversion
process
> for the COLORCONV_KEEP_TRANS mode rather than the very generic and
very
> slow blit_keep_trans() ?
>
> There are only two colors in the source color space that we must take
care
> of: the transparency color (color 1) and the color which will give the
> transparency color in the destination color space (color 2).
> So the first pass would 'prepare' the bitmap by changing color 1 into
color
> 2 and color 2 into any distinct color in the neighborhood. The second
pass
> would be the raw blit().
> This would work unmodified for ascendant conversions. For descendant
ones,
> color 2 is of course not a single color but a cloud of colors.
I came across that idea too - but it won't work with dithering. Maybe
use a prepare() function, and additionally modify the dithering code
(which won't be slowed down as it is slow anyway) ? I might try writing
a prepare() function on the weekend..
Another idea would be maybe a 3 pass-method with masks:
mask=create_mask(BITMAP *unconverted)
blit(unconverted,bmp)
apply_mask(bmp,mask)
It should always work, and maybe there is a way to reuse some of the
existing drawing modes to make the mask work. If no additional functions
should be exported, it can still be called from blit() when some flag is
set. A drawback is the additional memory required for the mask.
Elias