You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: