256 colour transparencies? (Question/Suggestion)

[Scavenger]

Is it, at the moment, possible to create transparencies in 8bit games? I know it can be done, ala DPaint, where the colours underneath the object are darkened depending on what the transparency is. According to my sources, if you have a big enough pallette, and backgrounds that are imported "Exact Pallette", you can make things darker or lighter, like shadows, but I'm not sure about tints. They might mess up the sprite. It would be a great help to be able to have transparencies in Lo-Res, 8bit games... people like me with slow computers would benefit from it!

Also, the Tinted regions with a colorise type function... could that be done in 8bit games too? But bah, I'm not respectable enough to suggest things like that...

[Fuzzpilz]

Short answer: No. Doesn't work.

Why? Because you've got a limited set of colours to work with, and if you want transparency, you'll need to have one colour for each combination of foreground and background. This can be reasonably approximated in highcolour or truecolour graphics, but in palette games you have two choices: making "transparent views" for the character consisting of interchanging opaque and keyed (transparent/invisible) pixels or calculating the RGB value you need and finding the best approximation in your palette, which is a stupid idea for obvious reasons.
Which means that if you want reasonable transparency, you're going to have to switch your game to highcolour.

[Pumaman]

It is technically possible, assuming your palette has a good balance of colours.

However, it's not viable for a real-time game, since searching through the palette to find the right colour is too time-consuming.

[Gilbert]

Also if you're going to modify the palette frequently within the game (which I will do), that transparency thing won't work well, so I'd rather stay away from it than to bother our nice pumaman to implement such complex features.

[MrColossal]

i always wondered this too.

played Guilty and it had colour tinting and The Dig too and i thought to meself "curious"

eric

and gil, that's not much of a reason not to add something, if you're going to modify the palette frequently then either you figure a way to use it or you don't use it. if we went around judging what should be added based on what you're gonna use in your 4 years long game, we'd still have to draw walls. hehe

[Gilbert]

heh yeah right

But for those games what they did were either direct modification of the palette entries (for example, the character used colour slots exclusive to himself) which doesn't require these tinting functions (though the drawback is that you have to change everything with the same colour slot in whole), the other is of course, with calculations.

However, the problem is that most of the time these calculations were done possible because of designs, that mean, everything needed to be tuned carefully in design level, how you assign the palettes, whatever things use how many colours, etc., otherwise there may not be a magic (and fast)  way that the computer can do this effect perfectly for any arbitrary settings of graphics. The problem is that currently there isn't much of organized treatment on palettes in AGS, and might involve a lot of work (which probably won't worth it, as ppl needing much of such functions may go for hicolour anyway) implementing some.

[dm_c.]

i also noticed half-transparent shadows in numerous adventure games such as the dig or curse of monkey island.  not that taxing to the system but like pumaman said, the game palette has to have a good balance of colors.
here's a code I wrote years ago that mixes two colors and finds closest color in the palette.  you may find it useful if you're making your own game engine.
my p4 can make about 400,000 of this function call a second in 8 bit.  incidently it's faster in 24 bit. its fast enough provided that the transparent area is small.  you can make it a lot faster if your palette is organized in a way that you don't have to search through all 256 entries.


float opacity = 0.5; // from 0 to 1
BYTE r= (opacity * (newr - oldr)) + oldr;
BYTE g= (opacity * (newg - oldg)) + oldg;
BYTE b= (opacity * (newb - oldb)) + oldb;

//find the closest colour
BYTE closest;
int rd, gd, bd;
int currDiff, closestDiff = 200000;
for (int ctrt = 0; ctrt < 256; ctrt ++)
{
  rd = palette[ctrt * 3] - r; //red
  rd *= rd;
  gd = palette[ctrt * 3 + 1] - g; //green
  gd *= gd;
  bd = palette[ctrt * 3 + 2] - b; //blue
  bd *= bd;

  currDiff = rd + gd + bd;
  //if current colour is closest
  if (currDiff < closestDiff)
  {
     closest = ctrt;
     closestDiff = currDiff;
  }
}

return closest;

[Pumaman]

If the palette was the same throughout the game, you could create a lookup table to enable transparencies to be done easily. Unfortunately, the palette changes in each room, and as Gilbert says you can also modify it manually within a room.

A function like what dm_c posted would work, but does actually turn out too slow if you have a fairly sizable sprite to draw transparently several times a second.