-
-
Notifications
You must be signed in to change notification settings - Fork 119
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
Alpha fillers #2682
Labels
Comments
Related #2435 I vote adding for a new flag for this, and also implementing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Recent updates in #2382, #2565 and #2566 have improved the speed of Surface.fill calls when using the
ADD
,SUB
MULT
,MIN
andMAX
blend flags. However, there’s still a fundamental issue with the fill function.Currently, if no flags are used, the fill function simply replaces the surface pixels with the chosen color. If the color has an alpha value (and the surface is set up to support alpha), all surface pixels will adopt this alpha value, and no alpha blending will occur.
Consider this example:
Using blit instead of fill gives different results:
In terms of the C API implementation, adding this functionality directly (meaning when the blend_flag is 0) would conflict with the current setup, as it would be impossible to distinguish between wanting to blend with alpha or overwrite the pixel completely. Not to mention it could break back-compat.
A potential solution could be to add a specific blend flag for
fill
likeFILL_BLEND
. This would allow for an easy implementation of the three possible alpha blending algorithms.So we would have something like this:
The text was updated successfully, but these errors were encountered: