#16 Grabber: Palette grabbing broken
I don't know for how long this has been going on (since I haven't worked much with palettes in the past), but something is seriously wrong with the palette grabber.
First, make a test bitmap using a wide variety of colors (try and make them "odd" colors to better exemplify the problem) and be sure you include bright pink (transparency) somewhere. Now open up the grabber and add a new palette object. Grab the palette from the image you just created and it may, at first, seem as though nothing's wrong. If you look closely, however, you will notice that there are two pinks (assuming you only used one pinkish color in the image). One is in index 0 (as it should be) and the other is somewhere else within the set of colors, but it looks kind of off-color. Upon dumping the palette to a file and viewing it with your editor of choice, you will see that those suspicions were correct - there really are two! The one at index 0 is color FF00FF (as it should be), but the other one is color F200F2 (it is for me, at least). Upon further investigation, you will find that the second color (the off-pink one) is being used for all your pink colors instead of the correct one. Upon even further investigation, you will find that ALL the colors are off. Color CD59BD, for example, is now C250B2. The grabber also appears to make an attempt to use only 60 colors at most and will throw out any beyond that.
I've tested this with both the DOS and Windows versions and gotten the same results. The Grabber is running in 640x480x32 on both platforms.
That the colours are off is not a bug. VGA cards traditionally only have 6 bits per colour sample, instead of 8 as you expect. Allegro follows this, for backwards compatibility reasons. Therefore any palettes grabbed will be slightly off.
As for the other things, I'll try to take a look later.
Logged In: YES
user_id=44413
I can't replicate this problem. I tried doing what you said, and I do get slight rounding errors in the palette,
but as Peter said, this is due to Allegro treating palettes as 6-bit as opposed to 8-bit, since VGA hardware
only uses 6-bit palettes. I get no problems with bright pink, and the full palette range is used.
Logged In: YES
user_id=153332
So, there is no way to use full 8-bit quality palettes with
Allegro (besides creating my own palette format and working
it in)? Shouldn't VGA-compatability be optional rather
than required?
The problem with pink seems to come from the grabber
dithering 24-bit bitmaps before looking for pink. The
dithering changes pink pixels to a slightly off-pink color
and then the when paletter (or whatever it is that converts
the pixels) reads them, it thinks they are that other color
rather than pink.
And about the 60 color thing, I think what happened was
that the majority of the colors I tested with were similar
enough that many of them were read as being the same
color. Since I presumed that full-color palettes were
being used, I thought that that was a bug.
Logged In: YES
user_id=44413
No, there is no way of using 8-bit palettes short of writing your own routines. Shawn Hargreaves has said
that this is a limitation, but Allegro was so developed by the time it was ported to non-VGA hardware that it
wasn't really possible to change this behaviour.
I have now reproduced your problem with pink. If I load a 24-bit bitmap containing 255,0,255 pink areas,
and grab a palette from that bitmap, then I get a 242,0,242 pink color in the resulting palette. Presumably if
I grab an 8-bit bitmap from the 24-bit bitmap, the pink areas will be of the second type of pink.
Unfortunately, the solution to this problem is rather complex. I believe it would require changing src/blit.c,
function `dither_blit()'. I have asked for suggestions on the Allegro conductor's mailing list, to see what
response I get.