-
-
Notifications
You must be signed in to change notification settings - Fork 185
Pixelarray SDL3 #3309
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
Pixelarray SDL3 #3309
Conversation
@@ -828,13 +859,12 @@ _compare(pgPixelArrayObject *array, PyObject *args, PyObject *kwds) | |||
return 0; | |||
} | |||
|
|||
new_format = surf->format; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function goes from 3 pixel formats to 2. new_format == format
as the code was written previously.
Should it actually be a format derived from new_surf instead of surf? Was the previous implementation a typo?
I'm not fully sure, but this translates it as was written.
644a2ec
to
4696146
Compare
92f0a40
to
ec2bdd0
Compare
@@ -1021,20 +1029,23 @@ _array_assign_array(pgPixelArrayObject *array, Py_ssize_t low, Py_ssize_t high, | |||
} | |||
break; | |||
case 3: { | |||
// Note: | |||
// Why is the 24 bit case pixelformat aware but none of the rest are? | |||
// - Starbuck, jan. 2025 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How are the rest of the paths not pixelformat aware? I think they are assuming that source and destination pixelformats are same and therefore directly copying over the data. But I didn't find this check enforced in the code anywhere on a quick search?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just mean they don't take into account the pixelformat. As you say, it looks like they just assume the source and destination are the same. Going through the code we have a lot of pixel stuff in pygame-ce and lots of it has little suspicious items like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh well, guess that can be addressed in future PRs, it shouldn't block this one
ec2bdd0
to
66a7879
Compare
Rebased so it uses latest SDL2/SDL3 updates. (has it on the branch, so you don't need to swap dep versions between main and this). |
66a7879
to
11961d7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty understandable, and LGTM from what I can understand. Thanks for making it compile :) 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the PR. 🎉
IG this PR touches on some confusing code, but overall everything make sense so I am approving.
Today I ported a few modules and worked on a few others.
I first did everything with explicit SDL2 vs SDL3 code to observe patterns, then I made a few new compatibility macros to match what I saw.
This PR is those macros + the pixelarray module.