Yeah, conditional compilation, compatible functions, macros and opaque types. Which ever is nicer for each part.
Cython is fine for new things, IMHO. cheerio, On Sunday, March 19, 2017, Lenard Lindstrom <le...@telus.net> wrote: > Hi René and everyone else, > > I like this approach. My patches achieve the first step, using SDL2. The > next step is to introduce new SDL2 features as new modules and classes. > > I suppose the SDL2 patches can be incorporated as conditionally compiled > code. They can be added one at a time, but must all be in place to work > properly. Then any new Pygame modules will expose SDL2 features only, so > not be built for SDL1. > > As a long term goal SDL1 can be removed and SDL1 legacy modules > reimplemented on top of the SDL2 specific code. > > Is there any reason new modules should not be written in Cython? If not > then we could try to use parts of pygame_sdl2 to quickly introduce SDL2 > specific features. > > Lenard Lindstrom > > > On 17-03-18 05:02 AM, René Dudfield wrote: > >> Hello, >> >> so, I've spent some more time reading source code, and investigating SDL2 >> and the options a lot. >> >> I *think* this plan below could be the best way forward for us. >> >> tldr; >> * have a single source SDL1, and SDL2 code base with a compile time >> option. (like we have single source py2 and py3). >> * move bitbucket/pygame repo to github/pygame. >> >> >> Rather than reimplementing everything, and introducing lots of >> compatibility bugs, Instead I think a gradual approach would work better. >> I'm starting to think that perhaps pygame_sdl2 by Tom, is not such a great >> way forward (for the pygame project, I think it was necessary and good for >> Ren'Py). >> >> A big breaking change is kind of silly for how little resources we have. >> Python 3 managed to pull it off... after a decade, and with massive >> resources having poured into it. And it only took off once they put >> compatibility code back in. Here's the thread where some discussion has >> been happening. >> https://bitbucket.org/pygame/pygame/issues/174/pygame-20-the-sdl2-edition >> >> >> What we do have is some patches to get the current code base working with >> SDL2. >> https://bitbucket.org/llindstrom/pygame-1.10-patch >> >> I think it should be possible with some work to improve an SDL2 >> compatibility layer, so that pygame code base can work with either (as a >> compile time option). Then newer APIs can be introduced in time, in a non >> break-every-program kind of way. Also, it's been proven that 'hardware' >> blitting does not need to break SDL1 API compatibility to use hardware >> accelerated APIs (Angle, SDL_gpu, [insert 4 or 5 other projects], ...). >> >> Having a pygame2, or whatever separate repo would also make maintenance >> harder. Since for the foreseeable future, we will likely need to do >> maintenance releases for this anyway (at least I want to!, and I know other >> users of pygame will). >> >> --- >> >> For pip uploads, they would continue to be for SDL1, until we can finish >> the SDL2 changes, and it works better. There would be no new additions >> until compatibility is mostly there. >> >> The work would progress by slowly adding in compatibility changes whilst >> keeping pygame working. By keeping the SDL2 patch set as is, and slowly >> reducing the patch set until it is size zero. So we always have a pygame >> with sdl2, and a pygame with sdl1 that is producible. Eventually the patch >> set will disappear. >> >> --- >> >> A pygame2 module would just cause confusion amongst users, and that >> really boring 'pygame 1 or pygame 2' type debate would go on, and on like >> the "python 2, verses python 3" one did. For me, just avoiding that >> discussion for the next decade would be worth it. >> >> Then there would need to be two sets of documentation on the website. And >> two sets of tutorials... and... we'd have 2 of everything to *do*, and 2 of >> everything for people to look at. >> >> Finally, "import pygame2" looks kind of weird. I've grown used to "import >> pygame". >> >> ... >> >> >> >> I'm keen to get moving on this. I've been trying to get feedback on the >> 'pygame sdl2 addition' issue for the last month, and the issue has been >> open since 2013. So I'd like to put a time limit on this decision for one >> more week. >> >> I'd really like to hear back from contributors, and users (everyone). >> >> >> >> >> ps. Interestingly SDL_gfx has an SDL2 release now. >> http://www.ferzkopp.net/wordpress/2016/01/02/sdl_gfx-sdl2_gfx/ >> >> >
