Objects show through walkbehinds

[brushfe]

Hello!

I've noticed that objects that move through walkbehinds are visible when they pass behind an RGB colour of 255,0,255 (magenta).



In the screenshot above:
- On the left is the background PNG file, which is entirely covered in Walkbehind 2 in the editor.
- On the right is an in-game screenshot, where you can see the object passing 'behind' is visible wherever 255,0,255 is present in the background.

The walkbehind works properly - the baseline is set to the screen's bottom edge, and the rest of the object is hidden, just not where the pixels are in pure magenta.

Changing the background colour to 254,0,254 prevents this problem. So maybe this is a colour I should avoid in the future? (I've noticed that this 255,0,255 is also present when importing transparent sprites. Perhaps it's a colour AGS uses to denote transparent pixels?)

[Crimson Wizard]

Magenta also known as "magic pink" (255;0;255) is working as a transparent color in AGS.
Although I did not realize that it also works same for walk-behinds.

[brushfe]

Roger that, thank you for the reply! I didn't expect it in walk-behinds either, but I wonder if it could be used in interesting ways. 254;0;254 does the trick!

[Gilbert]

I think this should be considered a bug or an oversight though.
By defining a workbehind, you're already defining which pixels are opaque or transparent based on how far an item is placed "into the screen", if an item's baseline is higher than the one set for a certain walkbehind area, every pixel on the background in that walkbehind area shoud cover up the object, regardless of its colour.

[Crimson Wizard]

I think this should be considered a bug or an oversight though.
By defining a workbehind, you're already defining which pixels are opaque or transparent based on how far an item is placed "into the screen", if an item's baseline is higher than the one set for a certain walkbehind area, every pixel on the background in that walkbehind area shoud cover up the object, regardless of its colour.

I am in doubts if that may be fixed reliably.

The walk-behinds are handled in two different ways depending on whether we are running a software renderer or a texture-based renderer.

1. For texture-based renderer - the engine would cut out walk-behinds from room bgs, and display as regular sprites, sorted among objects and characters in the room. Since magenta (255;0;255) is treated as transparent color in general, this raises a question of how to distinguish background "opaque" magenta and normal transparency which also may appear on these cut-outs due to their non-rectangular shape.
If we were speaking solely of 32-bit games, this distinction may be done using alpha color component: i.e. we may instruct engine to add full alpha to walkbehinds pixels that were originally magenta (from bg). But it's not going to work in 16-bit games which do not have alpha channel (almost no one does these today, but 3.* engine still supports these).

2. For software renderer - the engine uses a different method. It takes character/object image and paints overlaying bits of walk-behinds over them. Which means that the magenta pixels will become character/object pixels, and also treated as transparent ones, so when the sprites are drawn you will see through these pixels on whatever is behind. I am not sure what would that be, either a room bg again, or a black clear color. In the first case that would be opaque magenta, which would kind of solve the issue, although secretly you will be seeing these pixels through transparent copies of themselves drawn on objects...
Again, in 32-bit games we likely can use alpha channel to make these pixels opaque, but not in 16-bit.

[brushfe]

Thank you for all the insight! It sounds like there's some potential solutions, at least for 32-bit games.

At the risk of asking a naive question, would it be possible for the user to set the general transparent colour manually, to override the 255;0;255 chosen by AGS?

In this case, I have a limited palette, and it's just bad luck that one of its colours happens to be that magic pink. I've changed my palette to avoid this, but if i could change it to a colour I'm not using, would that solve the larger problem without much effect on the engine?

[Crimson Wizard]

At the risk of asking a naive question, would it be possible for the user to set the general transparent colour manually, to override the 255;0;255 chosen by AGS?

No.

There's already a way to choose a transparent color: use alpha channel in 32-bit games. We might just need to stop engine from treating magenta as transparency, and rely purely on alpha values.

EDIT: I just tried an imported fully magenta 32-bit sprite with alpha channel, chose "import alpha" and "leave as-is" for transparency, and assigned it to the object in the room. It is displayed as opaque magenta in game.
This means that you may replace the walk-behind with an object using a sprite with alpha channel instead.
The above problem with walk-behind is happening because alpha channel is not defined for them. I suppose it should be. Maybe that can and should be fixed at least in 32-bit games.

EDIT2: as an option, since you said that you have a limited palette, you may also do a 8-bit game with palette where color index 0 is transparent, so AFAIK you may have magenta in any other index.

[brushfe]

Fantastic, thanks so much for looking into this so quickly! That's a great solution.