GET_PIXELVALS SDL3 compat #3343
Conversation
| GET_PIXELVALS(dR, dG, dB, dA, pixel, dstfmt, dstfmt); | ||
| GET_PIXELVALS(dR, dG, dB, dA, pixel, dstfmt, dstpal, | ||
| dstppa); |
There was a problem hiding this comment.
Unlike all other instances, this GET_PIXELVALS passes dstfmt into the macro twice. Once as the format, once as the "ppa" (per pixel alpha).
I believe this was a copy paste bug and have removed this behavior.
It now properly uses the per pixel alpha of the surface.
I'm classifying this as a super minor bugfix no one will notice. To notice you would have to be blit blend subtracting an 8 bit surface onto a 24 bit surface on a platform we don't do SIMD for (otherwise it would use a different implementation). I have not attempted to reproduce the issue.
There was a problem hiding this comment.
Sure, and nice catch too.
(we should reaaaalllyyy constrain surfaces to 32bits in pygame 3, imagine how much less branching and focus towards what really matters)
There was a problem hiding this comment.
I understand where you're coming from but forcing everything 32 bit will be difficult and removes paths that people can currently use.
I would like to do a review of all pixel handling code for pygame-ce 3, I think there are inconsistencies between places that could be resolved with higher level macros perhaps.
One other thing is that SDL3 introduces more exotic types of surfaces than ever before, and we need to make sure our APIs properly refuse to handle them or can actually handle them. Because it will be quite challenging to make sure they never leak into pygame-ce from SDL. Like imagine using the camera API and it gives you a YUV surface, or you load a weird png and it's a 64 bit surface.
Changes
These changes lead to surface_fill.c and alphablit.c fully compiling on SDL3.