Hey people.

Just curious, is it possible to filter out the black background, rather than the pink one RGB(255, 0, 255) on a sprite/bmp.

Thanks.

Dean.

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.

bah, thats long, i just finished compiling Alleg 4.1.11 I'm dumb!.

Oh well, Thanks..
Dean

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.

Go over the sprite when you load it and change any pixel you want to have masked to magic pink.
Other than that, short of recompiling Allegro, no. I'd suggest doing what Steve said though. Magic pink is a bit painful to the eyes at first, but you get used to it

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

In paletted modes, palette index zero is transparent. This is usually black, but technically that's coincidental.

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

It can always be hardcoded at index 255, just like black is hardcoded at index 0.

It's just one less color. It's not a big deal. It will not spoil graphics, since they would only use 8-bit colors anyway.

I didn't think of that, to tell you the truth. You are right, it would be a pain in the butt.

But, as it is right now, wouldn't you do it for 8-bit graphics anyway ? What I do is draw my graphics using bright pink for transparent areas, and use a very dark blue (0, 0, 1) for the black colors. Then, when I finish, I pass all the bitmaps through an app that converts the bright pink to black (color index 0).

If the bitmap has an alpha channel. What if it doesn't ? bitmasks are an established way to provide transparency.

That's why it should have been hardcoded at palette index 255.

It's one of the little problems Allegro has, that 8-bit graphics should be different than other color depth graphics, due to magic pink in high color modes and palette index 0 for 8-bit modes. It would have been much nicer to use color index 255, hardcoded to bright pink.

Anyway, in this day and era who is using 8 bit color depth ?

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.

Everything Evert says is right.

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

The fix for this is a single line of code in your program
Use magic pink for transparency in all your sprites - this is good for both ease of editing and hi-/truecolor compatibility. Then in your program, you change palette index 0 to black... problem solved. There's no need to keep two sets of images.

Allegro can color convert and preserve transparency for you.

Ever heard of 1-bit alpha channels?

Unfortunately, it does not. Maybe I am doing something wrong, therefore I post the source code, bitmap to show and the screenshot jpeg to prove that Allegro does not convert bright pink to black in 8 bit mode.

Does the 16-bit pixel format leave room for 1-bit alpha ? Nope (its 556).

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

[EDIT]
Attached screenshot.

16-bit can be 565 (pretty much defacto), 556, or 5551. All formats are possible, although I don't know to what extent allegro supports them.

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.

No it isn't. The other depths aren't paletted.

The lynched hamster swings both ways, I'm afraid.
Really, I find your logic rather backwards here. If you have less colors, taking away one makes a bigger difference, not a smaller one. Taking it to extremes, if you reduce a 2 color bitmap to 1 color, it's not going to work, but if you reduce a 16777216 color bitmap to 16777215 color, noone will notice a thing.

Oh right, so we'll just get everyone in the world who uses 256 color bitmaps to change their palette to keep you happy?

Better get started then. It may take a while to convince people that they've been wrong since the birth of 8 bit.

I'm afraid you're going to need some bigger boots.

Think about this from our point of view:

There are many people here who have used Allegro for years. Some have even written parts of it. They all find it perfectly reasonable, because they understand better how it works. Then, someone, with an apparently much shallower understanding of graphics and the innards of Allegro, decides that they want it done their way. And then they start using words like 'should', and suddenly has the community against them.

The sources are over here. Feel free to modify them yourself.

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.

No. As has already been said you just change what ever colour value you picked for palette entry 0 to black in your program. I tend to pick a darkish blue personally.

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.

By your logic 8888 would be 24-bit mode leaving 8 bits for alpha.

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

But I want color 0 to be black while I am drawing, since I am using some DOS full screen application for drawing (Deluxe Paint).

You still loose one color, either way.

1) According to the MOV documentation, the MOV instruction does not affect any flags. So I fail to see that the code you posted does the job you are saying.
From what I have seen from allegro sources, the instruction

orb %al, %al;

preceeds the

jz no_write;

Maybe you forgot it ?

3) Would n't it be faster to CMP with BL, for example, instead of an immediate value ?

I know that Bob knows the instruction timings, and I have read somewhere that using the AL register is faster than using any other register. Maybe this is the reason (using OR instead of CMP). Is this the reason ?

2) If MOV affected the Z flag, why this trick is not used in the other color depths ? it would speed them up.

Isn't it so for the 32-bit pixel format ?

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.

Yes, and 5551 is indeed a 16-bit pixel format, NOT a 15-bit pixel format.

As Lenny said - 5 + 5 + 5 + 1 = ..?

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.

You can still pack an 1-bit color mask separately from your color data without problems.

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

Thanks for the explanation, Bob. A final question: You are saying that the Allegro blit routines already use 8 registers. In the case of 15/16/24/32 bits, where is the magic pink value stored at ?

Check out the simple image I am posting. Half of it is pure black (RGB = 0, 0, 0) and the other half is RGB=0, 0, 1. Can you tell which half is the pure black by simply looking at it ?

I can't.

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.

If you work for TV Screens, no value should go below 32/32/32 or above 248/248/248.
At least that's in the docs I have here.

In fact, setting the mask color works nicely for the directX driver

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.

If I pump up the brightness, then yes. Black has the neat property of black times anything == black

First of all, I tried with 100% brightness and I could not spot the difference. Honestly. And I tried both CRT and TFT monitors.

Secondly, no one has 100% brightness all the time.

Anyway, it does not matter. All I wanted to say is that if I would make the decision, I would prefer the API to be consistent and then fast, rather the other way around. I see many people tricked with the transparent graphics in 8-bit mode, and there always the issues about the drawing tools.

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.

But right now we have all agreed (or rather forced) to use palette entry 0 for transparency, because Allegro does it like this. There would be no difference if entry 255 was used.

Aside from hardware problems, it's not good to change the dark blue to bright pink when you save (assuming you meant 'save' instead of 'safe'), because usually graphics are retouched after the first test.

The Z flag is set only from within comparison instructions, i.e. SCANS etc. The MOV instruction does not affect any flag.

But why should I have to do that ? libraries are here to help the programmer. Less effort = more (programming) happiness

It should have been though.

But you loose one more entry, since in all cases an opaque black would be needed, too.

But how do I do that in, let's say, 16 bits, where all bits are occupied by color information ? Furthermore, isn't alpha transparency much slower, especially when reading from the video ram ?

Sure. Out of the 100% of the sprites, only rectangular tiles need to be opaque. That may be 10%. All the other sprites are usually non-rectangular.

But Bob said:

So, he is saying that hardcoded values are slower, and you are saying that is faster. I think Bob got it right.

But the operation of turning one transparent pixel to another is a ...conversion. And when I hear "total conversion", transparency conversion is included. It does not say explicitely "only for opaque pixels". Furthermore, the COLORCONV_KEEP_TRANS flag is presented in the same list as the other flags. Finally, it should be included as default in COLORCONV_TOTAL: why would not I want transparency to be kept ?

That means it's hardcoded. What would be the benefit if it was done as in 8-bits ? Wouldn't that benefit justify the use of 0 as the transparent color ?

Not really. Blending white on black with half translucency results in a nice grey. Blending a white on RGB(0, 0, 1) results in a nice grey also, which is indistinguishable from the previous one. Only XOR produces vastly different colors, I think.

How's that irrelevant to a game ?

Hey, in the same line of thought, we all learned how to use DOS, right ? even if it was not the best system around. That something can people learn how to use is no excuse for its quality(look at Win32, for example).

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.

You only described one kind of blending. How about multiplication blending, additive blending, screen blending, dodge blending, etc.?

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.

Right. As I said, from the user's point of view, they're equally arbitrary. I take it than that we agree on this issue?

So change it back when you edit?

You do realize that you're effectively saying that everyone should have been forced to set palette index 255 to magic pink since the day the first VGA card was produced, right? Because that is what I mean if I say that it wasn't agreed from the beginning that colour 255 should be magic pink.
Hard-coding palette assumptions into Allegro would make it impossible for Allegro to load arbitrary bitmaps. I'm not sure why you seem so unwilling to see this simple fact.

I only ever used alpha blending in 32 bit images, so I can't say for sure. However, I think Allegro supports a 16 bit format that has an alpha layer of 1 pixel. Not sure though - it may depend on the hardware.

Yes, except possibly if it were to be hardware accelerated. AFAIK, Allegro never accelerates alpha blending though...
The 16 bit version could possibly be optimized to not read from the destination bitmap, since the alpha value is either completely transparent, or completely opaque.

Hardcoding the value saves the (small) time needed to load it from memory. It also saves a register, which you already don't have in abundance. So I'd say that having values hardcoded is faster than reading them from a variable in memory. I haven't benchmarked this, but in this case, I'm not taking Bob's word for it.

Sure. It's just not a colour conversion.

Hmm... ok, I see how that can be misleading. It's only an issue when converting between paletted graphics and non-paletted graphics, which is probably why it's not in there. But I understand you point here.

Assuming you meant relevant instead of irrelevant , things that come to mind are lighting effects. Also, don't assume that because you can't think of a use for this, noone else will either.
Allegro isn't just used for games either.

I wasn't arguing that people would be unable to understand palettes. People have done it in the past, so there's no reason they couldn't now. But in the past, palettes were part of the way the computer worked, something you simply had to learn if you wanted to do anything with computer graphics. Today, with everyone running graphical shells in high or true colours, palettes are far less noticable and obvious to newbies.

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

Yes, I did.
If enough people say the same thing,
axilmar might contemplate the possibility that we have a point