Re: [AD] COLORCONV_KEEP_TRANS in datafiles + cleanup

["Elias Pschernig" <eliaspschernig@xxxxxxxxxx>]

> > The last 2 lines in the patch are related to this. Maybe I should try to
> > come up with something which looks a bit nicer and uses
> > bitmap_mask_color()?
> 
> Can't you use a single test on 'c' instead of three on the RGB components ?
> A little comment would also be nice.

Yes, of course, that would be more clever :)

if (c == 0xf83f) g = 8; // 11111 000001 11111 binary

Should also work. If I'm thinking correctly, it's the only 16bit color that
can possibly be incorrectly translated into the 15bit mask color.

About the comment: What I did was, I used a modified output bitmap from pink.c,
which has a white-pink gradient, and put it into a datafile. Then I used
dat2s on it, and linked against your example program - using fixup_datafile
and the bitmap out of the datafile. In a 15bit mode, there now was a
transparent block of pixels where in the original it was pink.

> Moreover, if you removed the empty lines between the /* ... color */ and the
> code, the patch would be even nicer :-)

I see, I could have sworn the original code also looked like that :)

..
> > So after this patch, it should be possible to load any bitmap data into
> > any colordepth, and transparency would be preserved when the KEEP_TRANS
> > flag is set.
> 
> That's fine. I'm willing to apply these modifications to both trunk and
> branch, given that the docs have been lying in the 4.0.x releases. However,
> we could also choose the other way round (fixing the docs on the branch) in
> a more conservative spirit. Thoughts ?

My thought is, it's a bug fix, and so could be applied. But I remember
something else (the one-pixel-off menu-borders), where I also thought it's a
bug fix, and it was considered breaking ABI compatibility.. 

--
Elias Pschernig