Start getting base module ready for SDL3

pygame-community / pygame-ce

🐍🎮 pygame - Community Edition is a FOSS Python library for multimedia applications (like games). Built on top of the excellent SDL library.

https://pyga.me

939 stars 155 forks source link

Start getting base module ready for SDL3 #3171

Closed Starbuck5 closed 2 weeks ago

Starbuck5 commented 1 month ago

Before this PR there are 3 issues preventing base from compiling on SDL3, this PR handles ~~2 of them (the easy ones).~~ all 3.

SDL_getenv has changed to return a const char instead of char, so I reworked pg_EnvShouldBlendAlphaSDL2 to return an integer yes/no instead of a pointer where NULL/non NULL is interpreted as yes/no.
SDL_INIT_TIMER has been removed, so I made a PG_INIT_TIMER which is 0 on SDL3
SDL_ConvertSurface in SDL3 only exists as SDL2's SDL_ConvertSurfaceWithFormat, so restructured default pixelformat system to use enum values instead of structs. This is a complex looking change but I think is a good simplification overall.

~~The remaining issue is the pixelformat changes interacting with get and set default pixelformat.~~

~~Wanted to get this PR out so these two simpler changes can go through before worrying about what will need to happen with the pixelformat.~~

ankith26 commented 1 month ago

The remaining issue is the pixelformat changes interacting with get and set default pixelformat.

I think the fix for this should be easy enough to get done with in this PR. I'd like to see base.c actually compiling while reviewing a SDL3 port PR. I'm thinking we just make the pixel format functions deal with SDL3 SDL_PixelFormat integers. If any caller needs more info they can extract that with SDL3 API.

The callers can be fixed in future PRs on a submodule basis, just the function definition can be fixed now. And we can use our usual strategy of not changing the SDL2 codepath at all.

Starbuck5 commented 1 month ago

Not changing the SDL2 codepath is all well and good, but I'd also like to avoid completely separate SDL2/SDL3 codepaths.

I hadn't yet figured out whether to store the enum or the details in SDL3 or in SDL2, or how the consumer could be refitted in SDL2 to use enum instead of mask values.

Earlier in the porting effort I moved almost everything over from mask style to enum style, this is one I didn't touch.

My thought was that this PR contains simple enough code changes to go through without burdening the review of the pixelformat stuff (which could get complicated!)

ankith26 commented 1 month ago

I'd like some solution that gets base.c compiling in this PR, even if it's not the final solution or ideal solution. We can always change it later (and I believe when the tests actually start running we are gonna hit many more issues and have to do changes anyways)

Starbuck5 commented 3 weeks ago

As requested I have made the module compile fully, and as predicted it completely blows up the scope of this PR.

PR now changes the SDL2 codepath, includes changes to other modules, and the diff significantly larger. If I were reviewing this, I would want it in a separate PR.

Here is an infographic to help explain the changes: maskpixelformat_infographic

Starbuck5 commented 2 weeks ago

I consider this PR done, unless you insist on the macro Ankith.

Left the last commit unsquashed so the recent changes are viewable on their own. I would squash the last couple commits before merging.

Starbuck5 commented 2 weeks ago

(Just squashed the last 3 commits together)