create_trans_table
Onewing

Setting up a little translucent GUI for my game. I haven't messed with the blender or draw_trans_sprite and/or draw_lit_sprite functions hardly at all, so pardon if I say something obviously incorrect. Anyway, as a quick test, I added this to the game:

...
PALETTE pal;
COLOR_MAP trans_table;

set_palette(pal);
create_trans_table(&trans_table, pal, 0, 0, 0, NULL);
set_trans_blender(0, 0, 0, 128);

...
//Inside game loop
rectfill(bText, 0, 0, bText->w, bText->h, GREEN);
draw_trans_sprite(buffer, bText, 0, 0);
...

Now, the manual says about create_trans_table:

Quote:

The r, g, and b parameters specify the solidity of each color component, ranging from 0 (totally transparent) to 255 (totally solid). For 50% solidity, pass 128.

But, when I try to change anything of those parameters, nothing changes. In fact, if I try to change the first parameters of set_trans_blender parameters, nothing changes. To me, only changing the last parameter of set_trans_blender does anything.

ReyBrujo

Have you remembered to set the rgb_map and the color_map global variables after creating your transparency table?

Onewing
Quote:

Have you remembered to set the rgb_map and the color_map global variables after creating your transparency table?

It's not that I didn't remember, it's that I didn't know. What do I set them to?

ReyBrujo

rgb_map isn't necessary it seems, it only speeds transformations up. Check extrans.c, line 99. You set the global color_map to point to your trans_table.

Onewing

I set color_map = &trans_table and the parameters of create_trans_table and set_trans_blender still don't make any difference.

ReyBrujo

Try the extrans.c, modifying the values you are modifying in your program, and see if it doesn't change as well.

Onewing

It seems if I set the color depth to 32, those parameters don't do anything. At least, that's what I did with the extrans.c.

That's okay, I still have enough control to do what I need. I was just curious as to why they weren't doing anything. Thanks.

ReyBrujo

Wait... you were using 32bpp? Palettes are for 8bpp only.

Onewing
Quote:

pardon if I say something obviously incorrect

I didn't know that either. I just saw the create_trans_table() function needed a palette, so I set one up.

Johan Peitz

You need to set the drawing mode to tell allegro you want fancy effects. Like so:

// let's do some fancy schmancy stuff!
drawing_mode(DRAW_MODE_TRANS, NULL, 0, 0);
// draw it
rectfill(...);
// back to normal drawing
solid_mode();

Ceagon Xylas

Yeah, that's what you really want unless you're dealing with lower color modes. (256 and below I believe) Remember allegro's blender modes are a little slow.

ReyBrujo

Oh, don't worry. You know, I only work with 8bpp modes, so stuff like palette manipulation I take it for granted... from 15bpp to above, I know nothing :-[

Tobias Dammers

Colors are represented ultimately differently between 8bpp and everything else. 8bpp uses a global palette, and each color value represents an index into the palette. 15bpp and above packs RGB values directly into a single integer (16, 24 or 32 bits wide).
In high-color modes, a color's rgb components can be manipulated directly, and all kinds of blending, mixing, and lighting are implemented through blender functions, all of which take two colors and output another color.
In palette (8bpp) mode, though, this is highly inefficient, since it would involve:
1. Get the input color RGB values from the current palette
2. Appy the blender function
3. Find the nearest match for the result and return it.
Especially step 3 takes too long to be useful, even with an rgb_map.
Instead, one calculates the result for each possible pair of input values once and stores it in a table (the trans_table). After that, the "blend" operation is nothing more than a simple 2d array lookup.
Apart from that, a custom blender table allows for "special" colors, e.g. something like an alpha-aware palette that chooses blend factors according to color index; or "team colors", implemented using a selective color replacement table.

Thread #580693. Printed from Allegro.cc