errr, I think they only thing you can do is go into the Allegro source and change the defines for the mask color... MASK_COLOR, MASK_COLOR_15, etc...

EDIT:
and recompile of course.

Ah just fire up paint and recolor all your sprites with magic pink , or you can write your own masked_blit function to handle other colors besides magic pink. That or haggle the developers to add a set_mask_col(int color); that would change the behavior of all masked* functions.

Shouldn't the transparent color be the same for all color depths ? either bright pink (since it is considered not very useful) or total black (0, 0, 0).

If it was bright pink for 8 bit modes, I would hardcoded in palette index 255.

I would prefer it to be black of course. And I would use (0, 0, 1) for black, which is undetectable anyway that it has a very little bit of blue in there.

(Of course a better solution would be to have a bit mask, with set bits for opaque pixels and zeroed bits for transparent pixels).

You can't do that. 8 bpp is a paletted mode, and whatever colour corresponds to the mask colour you pick is unknown until you search the palette. Moreover, it's not even guarenteed to be there. Forcing people to include magic pink into their palette is a bad idea.
It also percludes any possibility of optimizing the code in a useful way if the mask colour is determined at run time. So as it stands, the answer is no.

Magic pink is a good choice in high/true colour modes because it's such an ugly colour noone would ever want to use it for anything else. Black is a bad choice because you would want to use it from time to time. You yourself mentioned that already:

Never assume. It might map to (0,0,0) on some machines, making it true black. Even if it doesn't though, do you picture yourself finding the stray (0,0,1) pixels in a sea of (0,0,0) pixels in your favorite paint program?

You could use the alpha channel for this too.

And on a final note,

Yes, I always set colour 0 to magic pink in 8 bit mode - makes it easier to convert graphics and is easier to spot than black. In fact, I already did this years before I started to use Allegro.
The only caveat is that you need to manually set it to something different (black, preferably) because the outline of the screen has the same colour (and you don't want to look at a screen with a magic pink border. You honestly don't).

You can't hardcode palette entries. And palette index 0 isn't nescessarily black. Wether you pick 0 or 255 is, from the user perspective, unimportant. It is important for the inline assembler version though, since you can do a rep movsb when you want to break at index 0, but need to manually check against other values.

You don't know that. 256 colours is pretty constrained, and someone may need all of them.

Any particular reason you're not changing palette index 0 to magic pink? I did mention this is what I do, right?

As I said above, using 0 is natural when you look at a possible optimized implementation. Using 255 is not. From the users perspective, the palette index which corresponds to transparency is aribitrary, wether it's 0 or 255, or 63 or 13. So it might as well be 255. The border outline is the only real reason to map 0 to black in your palette, but if you absolutely want, there are ways to change the border colour too (used to work in DOS anyway, may not be possible reliably in Windows).

Allegro has problems, and that's not one of them. If you hardcode index 255 to bright pink in Allegro, you suddenly find yourself unable to reliably load arbitrary bitmaps. Which is a bad idea. Allegro has no fore-knowledge on what the palette looks like and should not force something like that on the user. Without for knowledge, you can't say `ok, we'll use magic pink in 8 bit mode too' and expect to end up with a decently optimized library.

Obviously, but whereas Allegro doesn't support bitmasks as such, it does support alpha channels. So my suggestion was to load the bitmask into the bitmaps alpha cahnnel and use the alpha-blended drawing mode. If that's what you want. I'
t probably not very optimized (fblend might help, don't know).

Check here and here for a few examples.

It could have been done as for the other color depths. It's exactly the same.

Exactly. Since it's pretty constrained, one less color would not hurt anyone. It's more important to have the same bitmaps for any color depth than to loose one color entry in the 8-bit depth.

You said it yourself: the ugly pink border. I use Deluxe Paint for Dos to draw stuff, as I find it much better than other apps for this type of drawing.

It also introduces an ugly pink border in games.

But 16 and 32 bit loops could also have been optimized in the same way. REP MOVSW, REP MOVSD (or with REPE/REPZ) works the same as REP MOVSB. So, black should have been the preferred magic color for 16/32 bit pixel values. Is the logic inconsistent here, or am I missing something ?

It is for me. In my gui lib, I tried to make a Cursor class which encapsulated the cursor bitmap, but since 8-bit images need to be separate from true color, it needed two images. I always had to synchronize the images pixel by pixel. I wanted the same cursor to be usable in any color depth.

And another problem: providing support for 8-bit color depths in game. You need two sets of graphics, one with black as the magic value and one with bright pink.

Not if index 255 was preagreed to contain the magic value.

I don't find it a big deal. So what, index 255 is used for transparencies. That's ok, as long as I don't have to use two sets of images.

Pardon my ignorance, but from this discussion I understand that the only reason bright pink is not used in 8-bit modes is the REP MOVSB loop. Isn't REP MOVS used in 16/32 bits ?

Maybe it should.

I don't want to do translucency, I am only speaking about "show-through" bitmaps.

Any relation to the Pope, maybe ?;D

Allegro can color convert and preserve transparency for you.

Ever heard of 1-bit alpha channels?

Add the line
set_color_conversion(COLORCONV_TOTAL | COLORCONV_KEEP_TRANS);after set_gfx_mode() and it works.

[EDIT]
Attached screenshot.

The only disadvantage of using colour 0 is it's also the border colour. But IMO that's an acceptable trade-off for slightly faster blitting.

also, there is no need to have two images as previously said. Just colour convert the images.

Why should I do that ? the Allegro help says explicitely that:

"The default mode is total conversion"

So I shouldn't set any flags.

5551 is 15 bit, leaving one bit for alpha. Just like 32 bit is RRGGBBAA.

Now that the little Allegro help inconsistency is solved (where it says the default color conversion is total conversion, but I have to manually specify COLORCONV_KEEP_TRANS), I don't care if 8-bit is using color 0, because my problem is solved.

No one has still explained why using color 0 permits faster blitting. I will have to search the Allegro sources. But since I know 80x86 assembly, I see no difference in using REP MOVSB and REP MOVSW, for example. Its the CX counter that is decremented, and the MOVS instruction does not do any comparison, as far as I know (it's not that the blit will stop as if using SCANS).

But using color 0 is just an agreement also between us users of the library.

If you take my statement as discrete algebra, then you are right. But, practically, it does not make any difference to the graphics designer, because it leaves 255 colors to use.

Why, does everyone use color 0 for transparencies ?

Look at it this way, and you might understand it: if I have color 0 (which is 99% black, due to border issues), then I need another color for black, right ? this means two things:

1) one less color nevertheless, since color 0 is for transparencies and must stay black. That means 255 colors in this case also.

2) another color used for blackness means problems when drawing. I have to know by memory which pixel is black-transparent and which pixel is black-opaque.

By using another color index for transparency, I would still have 255 colors available, but I would not have problem 2. And I would use the black color both for the border and the game's sprites.

Now that I explained it to you, I hope you understand it. If you don't, I will explained to you further.

What makes you think I am not using Allegro for years ? my first game (and only so far!!! shame on me!!) was a Tetris game written with Allegro in 1996!!! (God damn, so many years have passed already ?)

Good for them. I must be of inferior I.Q. not to understand the greatness of having two black colors in the same palette.;D

Sure buddy, whatever you say.

It's a free country, and I am free to express my opinions as I see fit. You can't judge me, since you don't know me, and surely you were not invited to play the devil's advocate.

Easy:

/* Color 0 is the mask */
 movb (%esi), %al;
 jz no_write;
 movb %al, %(edi);
no_write:


/* Color 34 is the mask */
 movb (%esi), %al;
 cmpb $34, %al
 je no_write;
 movb %al, %(edi);
no_write:

See, one more instruction.

I'd say you should ignore any advice given to you. It doesn'tz matter if it works...

The point is, if you check the flags given to set_color_converions(), you'll see that there's one more flag besides COLOR_CONV_TOTAL...

Ok let's see... 5+5+5+1 = ?

Using an index doesn't force anybody to change the colors... it's not that hard
And see Bob's post for why everybody uses index 0.

Now, that is a tough one