Hi Tom, Is there any reason you couldn't use an SDL2 using pygame?
I assumed you would be able to. best, On Monday, March 20, 2017, Tom Rothamel <t...@rothamel.us> wrote: > I'll be honest and say I really haven't had any time to improve the > features of pygame_sdl2 that aren't used by Ren'Py. It's hard enough to > support one large project, and I just don't think I have another one in me > at this time. I'd love to work with anyone who wants to bring pygame_sdl2 > to parity with pygame, or to share/relicense any code that people want to > move to other projects. (This could also include stuff distributed with > Ren'Py at the moment, like Steam or IAP support.) > > Assuming that nobody wants to take this up as a project, I'll probably > rename pygame_sdl2 to something else, so as not to overly confuse people on > what it's about. > > I'd suggest there are three things a future pygame needs to focus on: > > 1) Mobile support - I think any game development platform that doesn't > support mobile devices is just going to get increasingly marginalized. > > 2) Providing access to modern graphics APIs, like OpenGL/OpenGL > ES/Vulkan/DirectX - perhaps via something like ANGLE, and then supporting > the rest of the stuff required to make a game around them - opening > windows, loading images, audio, haptics, etc. > > 3) I would suspect that a non-backwards-compatible pygame would be poorly > received if it keeps the same name and breaks the existing code. It would > require any book mentioning pygame to be rewritten - and is it likely > anyone would do that rather than try to teach people some other > API/language? > > But this is all backseat driving, since I really am kind of full up, > schedule-wise. That being said, when evaluating SDL2 migration > requirements, it's probably a good idea to first decide what the actual > needs are. > > > > > On Sun, Mar 19, 2017 at 6:46 PM Leif Theden <leif.the...@gmail.com > <javascript:_e(%7B%7D,'cvml','leif.the...@gmail.com');>> wrote: > >> I think that rewriting the extension modules in cython would be a great >> way to make the project accessible to new developers. >> >> Writing extensions in C, as it is now, requires that developers have 1. >> Good C skills, 2. Understanding of the Python C library, 3. Knowledge of >> the SDL library, 4. Understanding of low-level details about the platforms >> it supports, and finally, 5. a good sense of how pygame works. >> >> If you can imagine those skills charted as a Venn diagram, it's not >> difficult to understand why it is hard to maintain pygame as is, because >> only a handful of people have those skills and actually care. >> >> Cython is not difficult to learn and looks like Python. It would be less >> of a barrier of entry for new developers to contribute. >> >> Also, let's not forget that C in general is losing mindshare, as new >> developers tend to learn JS, java, and Python for their classes. >> >> At that point however, Toms python_sdl2 is already doing that so, where >> does that leave pygame2? >> >> If cython is chosen, better to let pygame 1.9 die gracefully and move on >> to a better platform and not duplicate effort (by moving to python_sdl2). >> >> Good night, sweet prince, in that case. >> >> >> On Sun, Mar 19, 2017 at 5:02 PM Lenard Lindstrom <le...@telus.net >> <javascript:_e(%7B%7D,'cvml','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/ >>> > >>> >>>
