Bliting things with the "magic pink" color
Felix-The-Ghost

In a sortof spriting program I have a temp bitmap to draw shapes and lines onto while they're being positioned, then I blit that on top of everything else but the problem is if I want this bitmap to have that color in it.
Instead of a temp I could draw directly to the screen but is that a bad idea? Wouldn't I have to hide the mouse and acquire the screen and such if I do that?

someone972

I assume you mean that you are drawing a sprite containing lines and such over everything, but you want to be able to use magic pink as well as a color for the lines. The way I would do it is like this:

BITMAP* magic_pink_bitmap = create_bitmap_ex(8,BUFFER_W,BUFFER_H);
BITMAP* other_buffer = create_bitmap(BUFFER_W,BUFFER_H);

clear(magic_pink_bitmap); //clear to black: the default transparent color for 8-bit.
clear_to_color(other_buffer,makecol(255,0,255));
//...
if(color == makecol(255,0,255))
putpixel(magic_pink_bitmap,x,y,makecol8(255,0,255));
else putpixel(other_buffer,x,y,color);

draw_sprite(other_buffer);
draw_sprite(magic_pink_bitmap);

Edgar Reynaldo

You can cheat with the color and use makecol(254,0,254) - it's indistinguishable visually.

You can also just use a 32 bit bitmap with alpha instead. Clear it to transparent black and draw things opaquely, then use translucent drawing routines. You could also use alpha values as a binary transparency setting as well, and write your own drawing routine that ignores 0 alpha and writes non-0 alpha pixels.

Felix-The-Ghost

I want to avoid having other color depths, forgive me. Just a style I guess.
I have an idea kind of like yours, maybe draw the resembling color onto the bitmap and have a custom blit routine that reads each pixel ignoring the pink and for the special color writing that pink color instead so it's still that color but behind the scenes it works with a fake color. The dest bitmap is only 16x16 but I also draw a x2 copy and a x12 copy...would this be very slow? Doesn't the blit function read as well as write also?

Audric

I think the shortest solution in terms of source code would be the 32bit temp bitmap : You can keep using 24bit for everything else, and allegro does transformations only when you write to it and when you blit it to your screenbuffer.
The two zoomed views can read from the normal view and stretch_blit() it, no problem of magic pink or alpha.

> The dest bitmap is only 16x16
Then do as you wish, it's impossible to get any performance problems with such a small area. The drawing program I'm working on (grafx2) does all drawing with the equivalent of putpixel/getpixel for allegro's BITMAPs, and the resultis still very smooth when using brushes much larger than your whole canvas.

Felix-The-Ghost

You can cross the different depths with each other? Would I still initialize with 24?

Audric

Init with 24 since you want your "screen" to be 24 (and all memory bitmaps as well, by default) With create_bitmap_ex() you can precise for that one bitmap that you want 32bpp.
The manual for draw_trans_sprite() says:

Quote:

The bitmap and sprite must normally be in the same color depth, but as a special case you can draw 32 bit RGBA format sprites onto any hicolor or truecolor bitmap, as long as you call set_alpha_blender() first

Felix-The-Ghost

What happens if I draw in black (0,0,0) ?
Is the transparent black a different black?

Thomas Fjellstrom
Quote:

Is the transparent black a different black?

Remember its an 8 bit only thing... And its not Black, its palette index 0. Which often tends to be set to black, but it may not be, and makecol may not generate index 0 for makecol(0,0,0) if there another black in the palette.

Felix-The-Ghost

Wow I feel dumb for not understanding what you said.
You mean only in 8 bit black is transparent, yeah know that much, but you're saying that black is fine in 32 bit, but when converted it turns black?
So black's fine?

Audric

In RGBA, any color with A=0 is fully transparent.
You'll want to fill your buffer with makeacol32(anything,anything,anything,0)
And then draw lines, pixels, etc. in makeacol32(R,G,B,255)
You can then draw_trans_sprite() this buffer, all colors are preserved, and transparent area is preserved as well.

Thomas Fjellstrom
Quote:

You mean only in 8 bit black is transparent, yeah know that much, but you're saying that black is fine in 32 bit, but when converted it turns black?

NO.

In 8 bit, you draw using indexes into an array (palette) of colors. The 8 bit number is replaced in the graphics card with the color in the palette that matches up with the 8 bit number. Palette entry 0 is generally "transparent", so any time the function that does the bliting encounters a 0, it skips it. Doesn't really matter what color is stored in the palette, it will be skipped.

Felix-The-Ghost

>In RGBA, any color with A=0 is fully transparent.
You'll want to fill your buffer with makeacol32(anything,anything,anything,0)
And then draw lines, pixels, etc. in makeacol32(R,G,B,255)
You can then draw_trans_sprite() this buffer, all colors are preserved, and transparent area is preserved as well.

Ugh. So I'll have to use those getr() etc if I already have a full color int...
Well needs a bit more but I should be able to get it.

Thread #599210. Printed from Allegro.cc