That's the point. For the 32bit pixel format. Not for the 24bit mode.
For the same reason the 5551 mode is a 16bit mode and not a 15 bit mode.

Certainly, but not all color depths leave room for alpha blending bits. So doing masking by alpha blending is not a solution for every color depth, as it was previously suggested.

Ahh, right. Sorry, I got mixed up with HC12 (another brain-dead ISA).

In any case, there are other reasons why 0 is used:
- No additional registers are needed. This is important because of the next two reasons.
- Less dependency chains; the code is inherently more parallel, allowingfor better dynamic scheduling by the ROB.
- No additional trips to memory. The Allegro blit routines already use 8 registers - there's no room for another register to hold the value to compare to.
- The loop actually works on 32-bits at a time, so we need a complete register to store the compare value.
- For hard-coded values, you lose flexibility, and you increase the code size. Code size might have an effect on speed (icache misses / decode bandwidth).

There are no free registers.

Using %eax (%al too?) as a register makes the code one byte smaller in most cases. This saves decode bandwidth and icache.

Because you'd like your black to be black, and not dark blue

No, it's not, because you don't know in advance that there even is a value corresponding to magic pink in the palette (and let's not get started again on how everyone should just agree to set colour 255 to magic pink. We both know that that is nonsense).

Ok, in that case, you can always set colour 0 to magic pink when you safe and something different (dark blue is easy on the eyes and easy to distinguish from other colours) while you work. You could also look into programs that allow you to change the border colour, but I don't know if the state is persistent between videomode changes and if it even works on modern hardware (if it's VGA compatible, it probably should - but you never know).

I had the recollection of rep movsb (rep movs really) breaking when either CX (or ECX) hits 0, or AL (or AX or EAX) becomes 0. Seems like I remembered incorrectly based on the link you posted, though Sun's reference is less clear. I'll dig up some old code when I get home and see how I used to do this in the past, but for now it seems my memory was incorrect.

Please, palette manipulations aren't that hard... taking a little time to think about it should convince you that that isn't true (you might want to use two sets of graphics, one which is hand-optimized for low colourdepths, but you don't have to).

Obviously. But it wasn't, so there.

Same could be said for index 0...

Apart from 1bit alpha channels which have already been mentioned, there's noone forcing you to use intermediate alpha values. Just make areas completely transparent or completely opaque.

The docs says it converts colours, not that it preserves transparency. No inconsistency. If you set palette index 0 to magic pink, you don't need COLORCONV_KEEP_TRANS.
Also, I think you need a recent version of Allegro for things to work properly, but I'm not sure.

I always have (which is partially why I remember that being easy to optimize for).

Not every sprite needs to be drawn transparently. Using pure black in sprites can often even be a bad idea (I don't have the pixel-artist tutorial where it's explained handy right now, but the bottom line is that black is very dominant).

I haven't checked, but I suspect it's not stored at all, but hardcoded. That's faster and easier to implement. If it were stored in a register, it would be trivial to make it possible to change the mask colour in Allegro, simply by changing a a variable. Since I know it's not that simple, by reverse logic (;)), it's not done in this way.

It's an inlined constant.

If I pump up the brightness, then yes. Black has the neat property of black times anything == black. This is something important when blending or performing other non-trivial operations on your pixels.

That's not what he meant. If you increase the brighness of the image by a factor of 10, you'll see the difference.

Have you even listened to what has been posted above? There is a fundamental difference at the hardware level between 8 bit colour mode and higher colourdepths. There is no inconsistency in the API, since you're dealing with different things.

With 8 bit graphics becoming dated, I suspect many people are unfamiliar with palettes. This is the main cause for confusion in 8 bit modes.

Sorry Axilmar, you have some good points, but I also don't think you are listening..

You said:

Bob earlier said:

so there is a reason why 0 is used rather than another value.. So that's your first question answered.

I take it that you are refering to drawing images with a distracting bright pink background. Earlier I said that you only change the colour to bright pink in your program, not the saved image file. You can always restore it to resave an image.

It seems that you want to treat a paletted graphics mode as a truecolour one. The two modes are fundamentally different and should not be treated the same. Otherwise people would be forced to have an entry in their palette for magic pink. This would mean that the blitting routines would have to either check through each of the 256 palette entries to find the colour or use a look up table. If it was using a look up table then the routine would be comparing against another variable which is slower. So we wouldhave to hardcode a palette entry to be transparant. If we used 255 it would still be slower than using 0 due to Bob's explanation.

.

Due to the VGA hardware used for palette modes, each colour channel only can go from 0-63 rather than 0-255. So 0,0,1 would become 0,0,4 which is just enough to be visible in some situations. Bright pink would suffer the same problem, but it's a colour least likely to be found in nature and other art due to it's extreme vividness.

So from a speed perspective index 0 is better.
From a hardware perspective palette modes have to be treated seperately.

There are, actually, several 32-bit formats, as there are several 16-bit formats. Saying "32 bits" doesn't say anything about the format except that each pixel uses 32 bits of memory.
Usually, this is either RGBX or BGRX or XRGB or XBGR, where X is a padding byte that can be used as alpha channel, or left unused, or used for anything else you might imagine.
But 32-bit could (theoretically) also mean a 16 bit palette entry and a 16 bit alpha channel. Or it could be 10 bits of each r, g, and b, plus 2 bits alpha channel.
As for 16-bit: Could be 565, 556, 655, 448, 484, etc. (RGB/BGR), could be 5551 (RGBA), 4444 (RGBA), could be 88 (palette + alpha), could be anything.

The point is, allegro uses only a few of these:

• 8-bit palette

• 16-bit RGB 555, leaving 1 bit unused (unfortunately called 15 bit mode)

• 16-bit RGB 565

(the "real" 16 bit mode)

• 24-bit RGB 888

• 32-bit RGB 888, leaving 8 bits unused (for screen) or as alpha channel (for other bitmaps)

But there is no reason why one couldn't write their own routines that use other color formats. OpenGL, for once, knows a lot more formats, like GL_RGBA4, with 4 bytes for each component. Allegro can easily produce this kind of bitmaps, you only need to make your own blender functions.

Must be catching.. Evert didn't you read my response? You already said the same for some of his questions as I did..