Hi, thanks for inviting me to opine. :)
I like it. But "import pygumm" looks a lot more handsome than "import
pygame2". Seriously.
Having had much recent experience with a SDL2 implementation (pypy,
CFFI, plus all the SDL2 libs), I found that I would really like to see
in the next generation:
1. CFFI wrapper. It is Python, which any of us can write, and it exposes
all of the SDL2 API to programmers, not just what the C developers
choose to expose. This would make pygame superbly extensible. And it
would allow easy ad hoc inclusion of third-party prebuilt libs,
something that is a fairly high bar to hurdle in pygame gen 1.
2. CFFI would also make pygame compatible with pypy, something which is
sorely needed in my opinion. One can use optimization tricks to
compensate for CPython's speed limit, but one cannot do many things that
are computationally intensive without farming out to a third-party
opaque library. pypy could let coders do a lot more in Python, when a
full blown physics/geometry/numeric/scientific opaque lib is overkill.
3. I had acquired the problem of a slower Rect in pypy, however, because
pygame has a pyd and I'm not spiffy enough to port it to anything but
Python. If CFFI and pypy are an option worthy of consideration, Rect
would be best done in a shared library. Rect is truly a workhorse, and
pypy Rects can't compete with pygame Rects under heavy usage of Rect()
and inflate and move, etc. In pygame most of my time is spent in blit().
In pypy most of my time is spent in Rect, because the class is 100%
Python except for the four-slot CFFI data structure.
See what can be done with CFFI and pypy here:
http://pygame.org/project/2957
https://bitbucket.org/gummbum/gsdl2
I made a number of releases and games And a few drop-in tests "import
gsdl2 as pygame", but it ain't perfect. However, I wasn't trying hard
for software rendering compatibility, I was shooting for the new texture
features. As expected, I discovered that all of the software-blit
optimization tricks that I solved in gummworld2 were no longer needed.
Sounds like a few of you have already put a lot of thought and
discussion into the next gen, and I understand this is something
completely different. I certainly don't propose gsdl2 as a new code
base. But it would be grand if choose to use CFFI. I have no stake in
seeing my code transform into a butterfly, but if parts of it are useful
then good.
Also, an acceptable alternative might be to provide CFFI-compatible
shared libs so that people who want to use pypy have that choice, even
if they do not have the nice pygame API available. If so, anybody could
write a pygame-like API just like I did, and it doesn't need to be
maintained by the pygame core developers.
On 3/18/2017 5: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/