Why is mask generated by Sprite_Generate inversed?

[sandord]

Let me start saying that I'm really enjoying using GODLIB.

Now, I was trying to get masking to work for sprites. I'm using Sprite_Create() with aMskPlaneCount = 1. The mask seems inversed though, there's a background colored block around the sprite and where it overlaps something else, colors are inversed.

If I add *lpDst = ~*lpDst; after the last *lpDst |= *lpSrc2++; in

https://github.com/ReservoirGods/GODLIB/blob/master/SPRITE/SPRITE.C#L154

it works flawlessly. Am I missing something or is this a bug?

[pink-rg]

There is actually a bug in the sample; the API expects you to pass in a pre-generated mask for composition into the sprite.

In the pipeline used by reservoir gods games, the MASKMAKE tool is invoked on each PI1 contain sprite sheets, and masks are created (by a similar algorithm as described above). The BSBMaker tool is then invoked and Sprite_Create() is passed both the original graphic and the generated mask.

I've enhanced the API to add a Sprite_MaskCreate() which can do this work. You pass in the result to Sprite_Create() and it work as described.

I updated the SPRITE sample to use this new behaviour.

[sandord]

Wonderful, thanks for fixing this so quickly.

Because the sample was passing in the same address for the mask as the sprite, I assumed that there was some kind of mask generation logic going on. This is what you refer to as the bug in the sample, right?

Now I understand that the plane OR-ing that I saw in the code wasn't mask generation code but just a mechanism that would accept any non-background color as mask data.

[pink-rg]

Exactly, this was the bug in the sample. I didn't notice as it was running on a black screen with no background.

When writing our games it is sometimes necessary to manually edit the sprite masks if you want colour 0 to be opaque in some instances, thus we added the flexibility of supplying a hand edited mask graphic to the routine (auto-generation cannot work in this case).