Re: [AD] COLORCONV_KEEP_TRANS in datafiles + cleanup

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> 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.

After looking at _rgb_scale_5[] and _rgb_scale_6[], that seems to be true.

> 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.

I meant a little comment in the code, explaining the 'if' test.

> 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..

The two issues are indeed comparable: the behaviour after the fix is the
Right One, but the fix could harm some programs. Ok, let's follow the same
rule for this one too: we correct it only for 4.1.x and write a blurb in
api._tx to record the change.

After looking a little bit more at the code in datafile.c:fixup_datafile(),
I've run into two problems:
- inconsistent with read_bitmap(), the code expects 15-bit bitmaps to be
saved in 15-bit format. I don't understand why (Shawn ?).
- you said there is no problem with RLE sprites. Why ? 0xf83f is again
converted to MASK_COLOR_15, isn't it ?

--
Eric Botcazou
ebotcazou@xxxxxxxxxx