Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support drawing non-sprite crosshair on item cursor sprites with alpha channel #2377

Open
ivan-mogilko opened this issue Apr 4, 2024 · 0 comments
Labels
context: graphics type: bug unexpected/erroneous behavior in the existing functionality

Comments

@ivan-mogilko
Copy link
Contributor

Problem

Somehow this either was never noticed, or never reported before. But it appears that the current drawing logic in the engine does not properly support drawing a non-sprite crosshair over an item cursor, if the cursor sprite has alpha channel.

To be precise, it does draw a crosshair, but it is only visible when positioned over a non-transparent portion of a sprite. This is because the crosshair pixels are copying underlying sprite's alpha value when drawn.

This is probably not a recent regression, but a "historical" behavior for quite some time now.

The related code is found here:

ags/Engine/ac/draw.cpp

Lines 1251 to 1258 in 582e70c

void putpixel_compensate (Bitmap *ds, int xx,int yy, int col) {
if ((ds->GetColorDepth() == 32) && (col != 0)) {
// ensure the alpha channel is preserved if it has one
int alphaval = geta32(ds->GetPixel(xx, yy));
col = makeacol32(getr32(col), getg32(col), getb32(col), alphaval);
}
ds->FillRect(Rect(xx, yy, xx + get_fixed_pixel_size(1) - 1, yy + get_fixed_pixel_size(1) - 1), col);
}

The comment to the function sais "ensure the alpha channel is preserved if it has one", so likely it was meant to keep alpha in case the put pixel does not have one. In the described case it does the opposite though.

Suggestion

I suppose that if a crosshair is drawn over sprite, then it's expected to be drawn with full alpha, not copying alpha from the base picture.

It's essential to investigate the uses of this function. The behavior should be consistent if possible, and changes not break existing valid behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
context: graphics type: bug unexpected/erroneous behavior in the existing functionality
Projects
None yet
Development

No branches or pull requests

1 participant