Re: [pygame] pygame with SDL2 proposal

[Daniel Pope]

On Tue, 21 Mar 2017, 12:28 Leif Theden,  wrote:
>Students should be taught how textures work, where different memories
reside, and that GPUs operate differently than a CPU.

You are thinking about much more advanced students than Pygame is being
used to teach. Pygame is being taught to 9 and 10 year olds and the concept
of "memory", let alone execution model, is far beyond their level. They
just want to know what they need to type to make things happen - but they
need to be able to get results without knowing about memory and GPUs.

If we want to change everything totally, we should feel free - as long as
it remains easy to use.

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

In 21 March 2017 at 08:21, René Dudfield  wrote:

> If people can't use SDL1 for the moment with pygame, then we will be in a
> situation where two branches are needed. Rather than that, it seems simpler
> for me with a single code base for SDL1 and SDL2.


I guess this is the core of it. To me, the single code base sounds harder
than keeping two separate branches, especially as I expect the SDL 1 branch
wouldn't see many changes. But you're the one doing it, so if you prefer
the single code base option, that's reason enough to do it that way. ;-)

Re: [pygame] pygame with SDL2 proposal

[René Dudfield]

On Mon, Mar 20, 2017 at 4:47 PM, Thomas Kluyver  wrote:

> On 20 March 2017 at 15:13, René Dudfield  wrote:
>
>> The big advantage is that it is a much smaller change than something new.
>>
>>- smaller changes reducing risk
>>- the smaller amount of resources needed to get to SDL2
>>
>> I think we're talking at cross purposes, because what I'm arguing against
> (supporting SDL 1 and 2 at the same time) requires *more* resources, not
> less. You have to expend the effort to make SDL 2 work either way, but with
> your proposal, you must also expend extra effort to ensure that SDL 1 still
> works, and still more effort to build the mechanisms to switch between them
> at build time.
>



Looking into how much config we will need to change, and exploring why I
think supporting SDL1 is useful further...


First details on config.

For each platform our config scripts will have the SDL2 stuff added.
config_unix.py for example.

if sdl2:
...
DependencyProg('SDL', 'SDL_CONFIG', 'sdl2-config', '2.0', ['sdl']),
else:
...
DependencyProg('SDL', 'SDL_CONFIG', 'sdl-config', '1.2', ['sdl']),


The current build should require no more effort to build pygame with SDL1
as it is now. (I guess that sounds obvious) What I mean is that keeping it
compiling with SDL1 doesn't really add that much extra work. Whilst there
is a small maintenance cost for keeping the SDL1 code there, I think we
need to pay it until we finish the transition (see end of email).

The extra work goes into making SDL2 builds work. Concretely, it looks like
the config file include paths, and library paths are different. But also
building the dependencies on windows will be a major piece of work, since
the current windows build chain is not supported by SDL2 (or maybe that's
changed).

For dependency building we can have two scripts to build the different
ones. On manylinux we add the extra SDL2 based dependencies to the docker
builds, so we can build both with one image. I think that's not so hard.

For travis linux, and launchpad, we add a few more apt packages for sdl2.
For travis osx, we add a few more homebrew packages for sdl2.
Windows... dependencies all need to be redone for SDL2. Hopefully we can
lean on the SDL2 binaries here more.

As you say, getting people to upgrade at once to SDL2 on various distros
will not really be possible. Since we can't, that means SDL1 still needs to
be supported for the time being. If people can't use SDL1 for the moment
with pygame, then we will be in a situation where two branches are needed.
Rather than that, it seems simpler for me with a single code base for SDL1
and SDL2.


>>- SDL1 using people can keep with that for the time being
>>
>>
> My proposal is that people who need to stick with SDL 1 will install
> pygame <2. We can either declare it finished and let people rely on the
> last working release, or make occasional 1.9.x releases to fix critical
> bugs. Either way, that seems less effort that trying to carry SDL 1 support
> forwards with us as we support SDL 2. Pygame 1.9.3 works well enough for
> lots of games, and I'm fine with saying that we're leaving SDL 1 support
> there.
>

I think doing a new SDL2 based build will potentially take quite some time
on all platforms to finish. In that time in the middle, where it's not
ready yet, I think it'd be easier to keep the same code base and
infrastructure(For those fixes).

Additionally, because some platforms are going to be easier to port to SDL2
than others, being able to release a new pygame with either depending on if
the platform has SDL2 or is easy to port to SDL2 will not hold up all the
platforms. So if windows is much harder, then we could still potentially
build new releases with our existing toolchain and SDL1. And the windows
port is going to be much more time consuming, than say linux. It's a better
place to be in not having to hold everything up whilst we wait on all
platforms to be finished.

And that's the most important reason for keeping SDL1 for now: it allows us
to keep having releases on some platforms whilst the work continues, and
not have to maintain two sets of infrastructure.

Re: [pygame] pygame with SDL2 proposal

[René Dudfield]

On Tue, Mar 21, 2017 at 4:52 AM, Lenard Lindstrom  wrote:

> Okay, let's clear up a misunderstanding. This not an /either/ GPUs /or/
> CPUs issue here. SDL2 adds windows, textures, and renderers. But it still
> supports surfaces, even screen surfaces. So a Pygame 2 will add new object
> types for the new features while keeping surfaces, unless we no longer want
> image file support or text on the screen. The only big compatibility issue
> I see is that events are reorganized in SDL2. I emulate SDL1 events in my
> patch set to maintain backwards compatibility.
>
> The real question is do we want to add SDL2 features to the existing
> Pygame code base or pull a Python 3 and redesign the Pygame api for ascetic
> reasons.
>
>
Another option is to add compatibility now, and decide on a new or
additional APIs later.

Re: [pygame] pygame with SDL2 proposal

[René Dudfield]

Lets please try and keep conversation civil. Accusing people of trolling
isn't helpful.

There are few people on this mailing list which have a lot of knowledge
about GPU rendering, and Ian is definitely one of them. I think he was
genuinely trying to be helpful. His claim isn't even controversial - GPU,
ASIC, and CPU rendering all have different trade offs. As do game libraries
like pygame.



On Tue, Mar 21, 2017 at 12:18 AM, Leif Theden  wrote:

> I'm not really sure how to respond to this wall of text.  Ian, you are
> really trying to make the case that a software renderer making simple
> shapes around the on the screen is better than a GPU?  Why then are
> basically all games these days using a GPU?  Please, don't answer it,
> because I'm not sure if you are trolling or not, and don't want to risk
> derailing the tread with this...honestly quite ludicrous assertion you've
> made.  The proof is in the pudding, so to speak, and the pudding is
> certainly not software rendering anything.
>
> Anyway, I don't think the typical use case for games is drawing lines.
> People want sprites, and they want them to rotate, scale, and translate
> quickly.  Pygame1 cannot do this, but SDL2 can.
>
> I would say maybe there is a niche for pygame1, a toy for drawing lines
> and breaking students dreams of building a game using python.  There is a
> real desire for a fast python library that doesn't have the magic of say,
> Kivy, or even pyglet, but isn't slow and cumbersome either.
>
> On Mon, Mar 20, 2017 at 5:07 PM, Ian Mallett  wrote:
>
>> ​On Mon, Mar 20, 2017 at 3:52 PM, Greg Ewing > > wrote:
>>
>>> Ian Mallett wrote:
>>>
 Per-pixel drawing operations, if they must be individually managed by
 the CPU, will always be much faster to do on the CPU. This means things
 like Surface.set_at(...) and likely draw.circle(...) as well as potentially
 things like draw.rect(...) and draw.line(...).

>>>
>>> This is undoubtedly true in the case of drawing one pixel at a time,
>>> but are you sure it's true for lines and rectangles?
>>
>>
>> On Mon, Mar 20, 2017 at 12:25 PM, Leif Theden 
>> wrote:
>>
>>> Good points Ian, but I don't see why we need to support software drawing
>>> when OpengGL supports drawing primitives?  Is there a compelling reason
>>> that drawing lines with the CPU is better then doing it on the GPU?
>>>
>> ​Oh yes!
>>
>> Basically, it's because a GPU runs well when it has a big,
>> parallelizeable workload, and terribly when not. Flexible, small workloads,
>> such as you see in a typical indie game or small project, are basically
>> exactly this worst case. They are small (rendering dozens to hundreds of
>> objects), and they are dynamic in that the objects change positions and
>> shading according to CPU-hosted logic. Heuristic: if you've got a branch
>> deciding where/whether to render your object or what color it should be,
>> then the GPU hates it and you.*
>>
>> If that made sense you to, you can skip this elaboration:
>> 
>>
>> The GPU is basically a bunch of workers (thousands, nowadays) sitting in
>> a room. When you tell the GPU to do something, you tell everyone in the
>> room to do that same thing. Configuring the GPU to do something else
>> (saliently: changing the shader) is slow (for technical reasons).
>>
>> I have a GTX 980 sitting on my desk right now, and it has 2048 thread
>> processors clocked at 1126 MHz. That's ing *insane*. I can throw
>> millions and millions of triangles at it, and it laughs right back at me
>> because it's rendering them (essentially) 2048 at a time. The fragments (≈
>> pixels) generated from those triangles are also rendered 2048 at a time.
>> This is awesome, but only if you're drawing lots of triangles or shading
>> lots of pixels in the same way (the same shader).
>>
>> But I *cannot* change the way I'm drawing those triangles individually.
>> Say I alternate between a red shader and a blue shader for each of a
>> million triangles. NVIDIA guidelines tell me I'm at about 3 *seconds per
>> frame*, not even counting the rendering. This is what I mean by
>> overhead. (To work around this problem, you *double* the amount of work
>> and send a color along with each vertex as data. That's just more data and
>> the GPU can handle it easily. But reconfigure? No good.) And this is in
>> C-like languages. In Python, you have a huge amount of software overhead
>> for those state changes, even before you get to the PCIe bus.
>>
>> And in a typical pygame project or indie game, this is basically exactly
>> what we're trying to do. We've got sprites with individual location data
>> and different ways of being rendered--different textures, different blend
>> modes, etc. Only a few objects, but decent complexity in how to draw them.
>> With a bunch of cleverness, you could conceivably write some complex code
>> to work around this (generate work 

Re: [pygame] pygame with SDL2 proposal

[Lenard Lindstrom]

Okay, let's clear up a misunderstanding. This not an /either/ GPUs /or/ 
CPUs issue here. SDL2 adds windows, textures, and renderers. But it 
still supports surfaces, even screen surfaces. So a Pygame 2 will add 
new object types for the new features while keeping surfaces, unless we 
no longer want image file support or text on the screen. The only big 
compatibility issue I see is that events are reorganized in SDL2. I 
emulate SDL1 events in my patch set to maintain backwards compatibility.


The real question is do we want to add SDL2 features to the existing 
Pygame code base or pull a Python 3 and redesign the Pygame api for 
ascetic reasons.


Lenard Lindstrom

On 17-03-20 04:18 PM, Leif Theden wrote:
I'm not really sure how to respond to this wall of text. Ian, you are 
really trying to make the case that a software renderer making simple 
shapes around the on the screen is better than a GPU?  Why then are 
basically all games these days using a GPU?  Please, don't answer it, 
because I'm not sure if you are trolling or not, and don't want to 
risk derailing the tread with this...honestly quite ludicrous 
assertion you've made.  The proof is in the pudding, so to speak, and 
the pudding is certainly not software rendering anything.


Anyway, I don't think the typical use case for games is drawing 
lines.  People want sprites, and they want them to rotate, scale, and 
translate quickly.  Pygame1 cannot do this, but SDL2 can.


I would say maybe there is a niche for pygame1, a toy for drawing 
lines and breaking students dreams of building a game using python.  
There is a real desire for a fast python library that doesn't have the 
magic of say, Kivy, or even pyglet, but isn't slow and cumbersome either.

Re: [SPAM: 9.600] Re: [pygame] pygame with SDL2 proposal

[Greg Ewing]

Leif Theden wrote:
For those just reading the thread and haven't voiced your opinion, 
please do so now.


It would be nice if pygame 2 could have a pygame 1 compatible
subset, because of the aforementioned tutorial materal etc.
out there, and in the interests of users not having to relearn
more than necessary.

But only if it's reasonably possible to do so without either
crippling the API or going to a lot of trouble in the implementation.
I don't know enough about the differences between SDL 1 and 2
yet to tell how feasible it would be.

--
Greg

Re: [pygame] pygame with SDL2 proposal

[Leif Theden]

I'm not really sure how to respond to this wall of text.  Ian, you are
really trying to make the case that a software renderer making simple
shapes around the on the screen is better than a GPU?  Why then are
basically all games these days using a GPU?  Please, don't answer it,
because I'm not sure if you are trolling or not, and don't want to risk
derailing the tread with this...honestly quite ludicrous assertion you've
made.  The proof is in the pudding, so to speak, and the pudding is
certainly not software rendering anything.

Anyway, I don't think the typical use case for games is drawing lines.
People want sprites, and they want them to rotate, scale, and translate
quickly.  Pygame1 cannot do this, but SDL2 can.

I would say maybe there is a niche for pygame1, a toy for drawing lines and
breaking students dreams of building a game using python.  There is a real
desire for a fast python library that doesn't have the magic of say, Kivy,
or even pyglet, but isn't slow and cumbersome either.

On Mon, Mar 20, 2017 at 5:07 PM, Ian Mallett  wrote:

> ​On Mon, Mar 20, 2017 at 3:52 PM, Greg Ewing 
>  wrote:
>
>> Ian Mallett wrote:
>>
>>> Per-pixel drawing operations, if they must be individually managed by
>>> the CPU, will always be much faster to do on the CPU. This means things
>>> like Surface.set_at(...) and likely draw.circle(...) as well as potentially
>>> things like draw.rect(...) and draw.line(...).
>>>
>>
>> This is undoubtedly true in the case of drawing one pixel at a time,
>> but are you sure it's true for lines and rectangles?
>
>
> On Mon, Mar 20, 2017 at 12:25 PM, Leif Theden 
> wrote:
>
>> Good points Ian, but I don't see why we need to support software drawing
>> when OpengGL supports drawing primitives?  Is there a compelling reason
>> that drawing lines with the CPU is better then doing it on the GPU?
>>
> ​Oh yes!
>
> Basically, it's because a GPU runs well when it has a big, parallelizeable
> workload, and terribly when not. Flexible, small workloads, such as you see
> in a typical indie game or small project, are basically exactly this worst
> case. They are small (rendering dozens to hundreds of objects), and they
> are dynamic in that the objects change positions and shading according to
> CPU-hosted logic. Heuristic: if you've got a branch deciding where/whether
> to render your object or what color it should be, then the GPU hates it and
> you.*
>
> If that made sense you to, you can skip this elaboration:
> 
>
> The GPU is basically a bunch of workers (thousands, nowadays) sitting in a
> room. When you tell the GPU to do something, you tell everyone in the room
> to do that same thing. Configuring the GPU to do something else (saliently:
> changing the shader) is slow (for technical reasons).
>
> I have a GTX 980 sitting on my desk right now, and it has 2048 thread
> processors clocked at 1126 MHz. That's ing *insane*. I can throw
> millions and millions of triangles at it, and it laughs right back at me
> because it's rendering them (essentially) 2048 at a time. The fragments (≈
> pixels) generated from those triangles are also rendered 2048 at a time.
> This is awesome, but only if you're drawing lots of triangles or shading
> lots of pixels in the same way (the same shader).
>
> But I *cannot* change the way I'm drawing those triangles individually.
> Say I alternate between a red shader and a blue shader for each of a
> million triangles. NVIDIA guidelines tell me I'm at about 3 *seconds per
> frame*, not even counting the rendering. This is what I mean by overhead.
> (To work around this problem, you *double* the amount of work and send a
> color along with each vertex as data. That's just more data and the GPU can
> handle it easily. But reconfigure? No good.) And this is in C-like
> languages. In Python, you have a huge amount of software overhead for those
> state changes, even before you get to the PCIe bus.
>
> And in a typical pygame project or indie game, this is basically exactly
> what we're trying to do. We've got sprites with individual location data
> and different ways of being rendered--different textures, different blend
> modes, etc. Only a few objects, but decent complexity in how to draw them.
> With a bunch of cleverness, you could conceivably write some complex code
> to work around this (generate work batches, abstract to an übershader,
> etc.), but I doubt you could (or would want to) fully abstract this away
> from the user--particularly in such a flexible API as pygame.
>
> The second issue is that the PCIe bus, which is how the CPU talks to the
> GPU, is *really slow* compared to the CPU's memory subsystem--both in
> terms of latency and bandwidth. My lab computer has ~64 GB/s DDR4 bandwidth
> (my computer at home has quadruple that) at 50ns-500ns latency. By
> contrast, the PCIe bus tops out at 2 GB/s at ~2ns latency. My CPU also
> has 15MB of L3 cache, while my 980 

Re: [pygame] pygame with SDL2 proposal

[Leif Theden]

Good points Ian, but I don't see why we need to support software drawing
when OpengGL supports drawing primitives?  Is there a compelling reason
that drawing lines with the CPU is better then doing it on the GPU?

Also, I'm a bit tired of the "python is slow so you may as well make
everything slow and not expect it to work quickly" attitude.  A pygame app
burns through the CPU not because of the interpretor, but because it is
flipping bits in ram when a GPU could do it.

On Mon, Mar 20, 2017 at 12:42 PM, Ian Mallett  wrote:

> Hi,
>
> As sort of a side-note, since performance has come up . . .
>
> Per-pixel drawing operations, if they must be individually managed by the
> CPU, will always be much faster to do on the CPU. This means things like
> Surface.set_at(...) and likely draw.circle(...) as well as potentially
> things like draw.rect(...) and draw.line(...). And it means everything, if
> there are a lot of calls. The GPU is obviously faster at graphics
> operations in-general, but it's still a thorough loss if you have to send
> the commands over the PCIe in the first place: if not in processing time,
> then in latency. As a matter of fact, this is true for most things people
> try to use GPUs for, and mitigating it is why e.g. Vulkan has to be so
> complex.
>
> What does this have to do with anything?
>
> Well, it's a philosophical question of what we want pygame to be:
>
> 1: Hardware-accelerated pygame-API-compatible library. (Basically won't
> work for reasons above.)
> 2: Hardware-accelerated pygame-API-incompatible library. (Fine, but AFAIK
> this already exists .
> There are probably other projects too.)
> 3: Software pygame-API-compatible library. (We have this now, and any
> movement to SDL2 should be considered in light of what features it changes
> (i.e. many misc. improvements, but worse (?) blitting).)
> 4: Software pygame-API-incompatible library. (Works best, IMO, with any
> plan to support SDL2.)
>
> Python is a slow language, and if you're using it, you're implicitly
> saying usability is more important right now. This includes graphics, and
> pygame is currently occupying that niche: highly usable, low-level,
> slow(ish; still pretty fast) graphics. If we want hardware acceleration
> (options 1, 2) then we're moving outside that niche. Ditto, to a lesser
> extent, breaking compatibility to add more-modern features (option 4). So
> basically, what it comes down to is whether we like our niche, whether
> moving to/incorporating SDL2 is focusing on a real problem, if so whether
> moving to SDL2 affects our feature set in ways we do like, and if so
> whether this affects our niche in ways we don't like.
>
> Ian
>

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

Thanks Ian for the clear post! I think this is the sort of thing I was
trying to get at, but I don't know as much about it.

On 20 March 2017 at 17:42, Ian Mallett  wrote:

> Hi,
>
> As sort of a side-note, since performance has come up . . .
>
> Per-pixel drawing operations, if they must be individually managed by the
> CPU, will always be much faster to do on the CPU. This means things like
> Surface.set_at(...) and likely draw.circle(...) as well as potentially
> things like draw.rect(...) and draw.line(...). And it means everything, if
> there are a lot of calls. The GPU is obviously faster at graphics
> operations in-general, but it's still a thorough loss if you have to send
> the commands over the PCIe in the first place: if not in processing time,
> then in latency. As a matter of fact, this is true for most things people
> try to use GPUs for, and mitigating it is why e.g. Vulkan has to be so
> complex.
>
> What does this have to do with anything?
>
> Well, it's a philosophical question of what we want pygame to be:
>
> 1: Hardware-accelerated pygame-API-compatible library. (Basically won't
> work for reasons above.)
> 2: Hardware-accelerated pygame-API-incompatible library. (Fine, but AFAIK
> this already exists .
> There are probably other projects too.)
> 3: Software pygame-API-compatible library. (We have this now, and any
> movement to SDL2 should be considered in light of what features it changes
> (i.e. many misc. improvements, but worse (?) blitting).)
> 4: Software pygame-API-incompatible library. (Works best, IMO, with any
> plan to support SDL2.)
>
> Python is a slow language, and if you're using it, you're implicitly
> saying usability is more important right now. This includes graphics, and
> pygame is currently occupying that niche: highly usable, low-level,
> slow(ish; still pretty fast) graphics. If we want hardware acceleration
> (options 1, 2) then we're moving outside that niche. Ditto, to a lesser
> extent, breaking compatibility to add more-modern features (option 4). So
> basically, what it comes down to is whether we like our niche, whether
> moving to/incorporating SDL2 is focusing on a real problem, if so whether
> moving to SDL2 affects our feature set in ways we do like, and if so
> whether this affects our niche in ways we don't like.
>
> Ian
>

Re: [pygame] pygame with SDL2 proposal

[Ian Mallett]

Hi,

As sort of a side-note, since performance has come up . . .

Per-pixel drawing operations, if they must be individually managed by the
CPU, will always be much faster to do on the CPU. This means things like
Surface.set_at(...) and likely draw.circle(...) as well as potentially
things like draw.rect(...) and draw.line(...). And it means everything, if
there are a lot of calls. The GPU is obviously faster at graphics
operations in-general, but it's still a thorough loss if you have to send
the commands over the PCIe in the first place: if not in processing time,
then in latency. As a matter of fact, this is true for most things people
try to use GPUs for, and mitigating it is why e.g. Vulkan has to be so
complex.

What does this have to do with anything?

Well, it's a philosophical question of what we want pygame to be:

1: Hardware-accelerated pygame-API-compatible library. (Basically won't
work for reasons above.)
2: Hardware-accelerated pygame-API-incompatible library. (Fine, but AFAIK
this already exists . There
are probably other projects too.)
3: Software pygame-API-compatible library. (We have this now, and any
movement to SDL2 should be considered in light of what features it changes
(i.e. many misc. improvements, but worse (?) blitting).)
4: Software pygame-API-incompatible library. (Works best, IMO, with any
plan to support SDL2.)

Python is a slow language, and if you're using it, you're implicitly saying
usability is more important right now. This includes graphics, and pygame
is currently occupying that niche: highly usable, low-level, slow(ish;
still pretty fast) graphics. If we want hardware acceleration (options 1,
2) then we're moving outside that niche. Ditto, to a lesser extent,
breaking compatibility to add more-modern features (option 4). So
basically, what it comes down to is whether we like our niche, whether
moving to/incorporating SDL2 is focusing on a real problem, if so whether
moving to SDL2 affects our feature set in ways we do like, and if so
whether this affects our niche in ways we don't like.

Ian

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

On 20 March 2017 at 15:13, René Dudfield  wrote:

> The big advantage is that it is a much smaller change than something new.
>
>- smaller changes reducing risk
>- the smaller amount of resources needed to get to SDL2
>
> I think we're talking at cross purposes, because what I'm arguing against
(supporting SDL 1 and 2 at the same time) requires *more* resources, not
less. You have to expend the effort to make SDL 2 work either way, but with
your proposal, you must also expend extra effort to ensure that SDL 1 still
works, and still more effort to build the mechanisms to switch between them
at build time.

>
>- SDL1 using people can keep with that for the time being
>
>
My proposal is that people who need to stick with SDL 1 will install pygame
<2. We can either declare it finished and let people rely on the last
working release, or make occasional 1.9.x releases to fix critical bugs.
Either way, that seems less effort that trying to carry SDL 1 support
forwards with us as we support SDL 2. Pygame 1.9.3 works well enough for
lots of games, and I'm fine with saying that we're leaving SDL 1 support
there.

Re: [pygame] pygame with SDL2 proposal

[René Dudfield]

On Mon, Mar 20, 2017 at 2:27 PM, Thomas Kluyver  wrote:

> On 20 March 2017 at 12:25, René Dudfield  wrote:
>
>> The stronger evidence of tests passing, and no concrete theoretical
>> reasons presented on why it can't be compatible suggests to me that it can
>> be done.
>
>
> I don't know a lot about SDL, but the transition sounds like a big change.
> And my experience is that any big change inevitably makes things break.
> People will rely on undocumented, untested features, and things that aren't
> features at all but just happen to work. There are some old stories about
> the lengths Microsoft went to for backwards compatibility in Windows, which
> included checking when a certain popular game was started, and then
> emulating an old bug which that game happened to rely on. I don't think
> we're going to be doing that sort of thing.
>
>
I understand it's a risk. But from what I've seen, I don't think it's a big
one.

I also don't see the advantage of having one version of pygame that can be
> built with two different versions of SDL. When people install it, they're
> getting one or the other version of SDL, not both. If they install it with
> SDL 1, they don't benefit from the SDL 2 support. If they install it with
> SDL 2, there's just as much risk of incompatibility as if they had to
> install a different version or different package for pygame with SDL 2. And
> recompiling to switch between the two is harder than simply running 'pip
> install pygame<2'.
>
>
The big advantage is that it is a much smaller change than something new.

   - smaller changes reducing risk
   - the smaller amount of resources needed to get to SDL2
   - compatibility for those of us who care about what we've made
   - SDL1 using people can keep with that for the time being

End users will still `pip install pygame` and not care about how we decide
to develop the changes.


This (supporting both SDLs in the same pygame release) is a separate
> question from making pygame API compatible when it moves to SDL 2 by
> default. That's an easier case to make - though I think there's also a case
> for letting pygame 1.x go quietly into the sunset supporting games already
> built for it, and making pygame2 for new games with some API breakage.
>

I guess that is a lot more effort than what I'm suggesting, and provides
less benefit.

The proposal:

   - takes work that is mostly done already, and cleans it up
   - keeps everyones apps working
   - whilst the work happens, pygame 1.9.x and 1.9.10 are releasable.
   - provides a base for future improvements
   - gets extra platform support (SDL2 gives us easier mobile, etc)
   - keeps everything working whilst the changes are made
   - reduces future documentation, and packaging work of maintaining two
   code bases
   - is less work, and less risky than continuing on from pygame_sdl2 and
   filling in the missing bits.
   - has a transition plan for end users, which is do nothing differently.

Re: [pygame] pygame with SDL2 proposal

[Leif Theden]

Thomas:

> I think there's also a case for letting pygame 1.x go quietly into the
sunset supporting games already built for it, and making pygame2 for new
games with some API breakage.
Considering that the breaking changes are basically just for graphics,
other parts of existing projects can be salvaged.

> I also don't see the advantage of having one version of pygame that can
be built with two different versions of SDL.
Agreed.

> Or do you develop and release a game with the pieces available at the
time, and then move on to a new project?
Generally, I just work with what is available.  I don't mind adapting small
changes to my projects where there is a great payoff for the effort.



On Mon, Mar 20, 2017 at 10:06 AM, Leif Theden  wrote:

> For those interested, here is the SDL2 migration guide.  Pygame is
> combination of SDL 1.2 wrapper code (surface, events), some value-added
> type functions (drawing code, some rect functions), and python code (like
> sprite module).  Because of this, it is protected from some changes to the
> underlying library, but not all.
>
> https://wiki.libsdl.org/MigrationGuide
>
> There will be subtle changes, and also complex ones.  My vote still is to
> make pygame2 close to SDL2, drop compatibility where it doesn't seem worth
> the effort, and keeping the spirit of pygame.
>
> Anything else seems like wasted effort.
>
> Also, lets focus on the issues here, and not waste time with things we
> agree on.
>
> We agree:
> * Pygame1 is outmoded and doesn't fit in with modern game libraries
> * Pygame1 is not a suitable target for real development because the
> graphics are slow
> * Pygame1 has significant problems that need to be addressed
> * Pygame1 needs a 2.0 version because its been sitting at 1.9 for years
> and it just looks silly to not modernize
>
> We don't agree:
> * Should pygame2 sacrifice some compatibility?
> * Should the effort be put to hardware-accelerated graphics or software
> graphics?
>
> Once the community reaches an agreement, then discussions of
> implementation can be addressed.
>
> For those just reading the thread and haven't voiced your opinion, please
> do so now.
>
> On Mon, Mar 20, 2017 at 8:27 AM, Thomas Kluyver  wrote:
>
>> On 20 March 2017 at 12:25, René Dudfield  wrote:
>>
>>> The stronger evidence of tests passing, and no concrete theoretical
>>> reasons presented on why it can't be compatible suggests to me that it can
>>> be done.
>>
>>
>> I don't know a lot about SDL, but the transition sounds like a big
>> change. And my experience is that any big change inevitably makes things
>> break. People will rely on undocumented, untested features, and things that
>> aren't features at all but just happen to work. There are some old stories
>> about the lengths Microsoft went to for backwards compatibility in Windows,
>> which included checking when a certain popular game was started, and then
>> emulating an old bug which that game happened to rely on. I don't think
>> we're going to be doing that sort of thing.
>>
>> I also don't see the advantage of having one version of pygame that can
>> be built with two different versions of SDL. When people install it,
>> they're getting one or the other version of SDL, not both. If they install
>> it with SDL 1, they don't benefit from the SDL 2 support. If they install
>> it with SDL 2, there's just as much risk of incompatibility as if they had
>> to install a different version or different package for pygame with SDL 2.
>> And recompiling to switch between the two is harder than simply running
>> 'pip install pygame<2'.
>>
>> This (supporting both SDLs in the same pygame release) is a separate
>> question from making pygame API compatible when it moves to SDL 2 by
>> default. That's an easier case to make - though I think there's also a case
>> for letting pygame 1.x go quietly into the sunset supporting games already
>> built for it, and making pygame2 for new games with some API breakage.
>>
>> At the heart of this, there's a question about how pygame users see game
>> development: do you work on one game in an ongoing manner, adding support
>> for new libraries and platforms as they come up? Or do you develop and
>> release a game with the pieces available at the time, and then move on to a
>> new project? Commercial games appear to follow the latter description more,
>> and contests like pyweek lend themselves to develop-and-stop, which
>> suggests that preserving API compatibility is not all that important. But
>> maybe lots of other games follow the latter model.
>>
>> > Holding onto legacy books, apps, tutorials is only hindering the
>> progress of a modern Python game library.
>>
>> Leif, while I agree with your points about complexity and compatibility,
>> I think that the body of experience with pygame - in the form of tutorials,
>> books, etc. - is actually a strength, and perhaps even the reason that
>> people are still wanting to 

Re: [pygame] pygame with SDL2 proposal

[Leif Theden]

For those interested, here is the SDL2 migration guide.  Pygame is
combination of SDL 1.2 wrapper code (surface, events), some value-added
type functions (drawing code, some rect functions), and python code (like
sprite module).  Because of this, it is protected from some changes to the
underlying library, but not all.

https://wiki.libsdl.org/MigrationGuide

There will be subtle changes, and also complex ones.  My vote still is to
make pygame2 close to SDL2, drop compatibility where it doesn't seem worth
the effort, and keeping the spirit of pygame.

Anything else seems like wasted effort.

Also, lets focus on the issues here, and not waste time with things we
agree on.

We agree:
* Pygame1 is outmoded and doesn't fit in with modern game libraries
* Pygame1 is not a suitable target for real development because the
graphics are slow
* Pygame1 has significant problems that need to be addressed
* Pygame1 needs a 2.0 version because its been sitting at 1.9 for years and
it just looks silly to not modernize

We don't agree:
* Should pygame2 sacrifice some compatibility?
* Should the effort be put to hardware-accelerated graphics or software
graphics?

Once the community reaches an agreement, then discussions of implementation
can be addressed.

For those just reading the thread and haven't voiced your opinion, please
do so now.

On Mon, Mar 20, 2017 at 8:27 AM, Thomas Kluyver  wrote:

> On 20 March 2017 at 12:25, René Dudfield  wrote:
>
>> The stronger evidence of tests passing, and no concrete theoretical
>> reasons presented on why it can't be compatible suggests to me that it can
>> be done.
>
>
> I don't know a lot about SDL, but the transition sounds like a big change.
> And my experience is that any big change inevitably makes things break.
> People will rely on undocumented, untested features, and things that aren't
> features at all but just happen to work. There are some old stories about
> the lengths Microsoft went to for backwards compatibility in Windows, which
> included checking when a certain popular game was started, and then
> emulating an old bug which that game happened to rely on. I don't think
> we're going to be doing that sort of thing.
>
> I also don't see the advantage of having one version of pygame that can be
> built with two different versions of SDL. When people install it, they're
> getting one or the other version of SDL, not both. If they install it with
> SDL 1, they don't benefit from the SDL 2 support. If they install it with
> SDL 2, there's just as much risk of incompatibility as if they had to
> install a different version or different package for pygame with SDL 2. And
> recompiling to switch between the two is harder than simply running 'pip
> install pygame<2'.
>
> This (supporting both SDLs in the same pygame release) is a separate
> question from making pygame API compatible when it moves to SDL 2 by
> default. That's an easier case to make - though I think there's also a case
> for letting pygame 1.x go quietly into the sunset supporting games already
> built for it, and making pygame2 for new games with some API breakage.
>
> At the heart of this, there's a question about how pygame users see game
> development: do you work on one game in an ongoing manner, adding support
> for new libraries and platforms as they come up? Or do you develop and
> release a game with the pieces available at the time, and then move on to a
> new project? Commercial games appear to follow the latter description more,
> and contests like pyweek lend themselves to develop-and-stop, which
> suggests that preserving API compatibility is not all that important. But
> maybe lots of other games follow the latter model.
>
> > Holding onto legacy books, apps, tutorials is only hindering the
> progress of a modern Python game library.
>
> Leif, while I agree with your points about complexity and compatibility, I
> think that the body of experience with pygame - in the form of tutorials,
> books, etc. - is actually a strength, and perhaps even the reason that
> people are still wanting to use it when there are so many newer tools. So I
> think it would be good to keep the API similar enough that those materials
> are still applicable.
>
> Thomas
>

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

On 20 March 2017 at 12:25, René Dudfield  wrote:

> The stronger evidence of tests passing, and no concrete theoretical
> reasons presented on why it can't be compatible suggests to me that it can
> be done.


I don't know a lot about SDL, but the transition sounds like a big change.
And my experience is that any big change inevitably makes things break.
People will rely on undocumented, untested features, and things that aren't
features at all but just happen to work. There are some old stories about
the lengths Microsoft went to for backwards compatibility in Windows, which
included checking when a certain popular game was started, and then
emulating an old bug which that game happened to rely on. I don't think
we're going to be doing that sort of thing.

I also don't see the advantage of having one version of pygame that can be
built with two different versions of SDL. When people install it, they're
getting one or the other version of SDL, not both. If they install it with
SDL 1, they don't benefit from the SDL 2 support. If they install it with
SDL 2, there's just as much risk of incompatibility as if they had to
install a different version or different package for pygame with SDL 2. And
recompiling to switch between the two is harder than simply running 'pip
install pygame<2'.

This (supporting both SDLs in the same pygame release) is a separate
question from making pygame API compatible when it moves to SDL 2 by
default. That's an easier case to make - though I think there's also a case
for letting pygame 1.x go quietly into the sunset supporting games already
built for it, and making pygame2 for new games with some API breakage.

At the heart of this, there's a question about how pygame users see game
development: do you work on one game in an ongoing manner, adding support
for new libraries and platforms as they come up? Or do you develop and
release a game with the pieces available at the time, and then move on to a
new project? Commercial games appear to follow the latter description more,
and contests like pyweek lend themselves to develop-and-stop, which
suggests that preserving API compatibility is not all that important. But
maybe lots of other games follow the latter model.

> Holding onto legacy books, apps, tutorials is only hindering the progress
of a modern Python game library.

Leif, while I agree with your points about complexity and compatibility, I
think that the body of experience with pygame - in the form of tutorials,
books, etc. - is actually a strength, and perhaps even the reason that
people are still wanting to use it when there are so many newer tools. So I
think it would be good to keep the API similar enough that those materials
are still applicable.

Thomas

Re: [pygame] pygame with SDL2 proposal

[Leif Theden]

I agree with Thomas; a compile time switch of SDL 1 or 2 sounds like a
nightmare and source of confusion for end users. Doesn't sound like a
simple way forward, and further locks the code base to a few developers who
can understand how the whole thing works.

The developers of pygame are currently overworked and can't even keep up
with pull requests or issues on the bitbucket. Making the code base more
complex will not being in more developers, which is needed to keep up with
bug fixes.

SDL 2 itself introduced breaking changes, but you don't see the maintainers
of it clinging to legacy code just to ensure source compatibility. There is
a code migration guide in the docs.

Holding onto legacy books, apps, tutorials is only hindering the progress
of a modern Python game library.

And to be clear, the biggest change is the the rendering modules.
Everything else can keep the pygame API. You could even just emulate the
old clunky surface and blit API behind the scenes, but you need hardware
accelerated support first, not an afterthought.

With proper mobile support, you can entice actual game developers to make
money or advertise the platform.

Content creators should embrace changes and not worry about breaking
changes. They get to write new blogs, sell more books, and teach more
content. Better for everyone.

Let's not forget this mailing list is an echo chamber of people who have
watched pygame languish. The people who have opinions about writing games
and apps in Python have moved on to Kivy, or bypassed pygame as soon as
they hit a performance wall because blitting is slow, and they don't
understand why their computer runs Crysis, but can't manage to draw a 100
sprites at 60 FPS.

This is my final reminder that every line of code written to ensure that
some pong tutorial from 2004 runs unmodified on pygame 2, is a line of code
lost that could make pygame relevant again.
On Mon, Mar 20, 2017 at 7:25 AM René Dudfield  wrote:

> I think this is a really good thing to think through.
>
> The issues you bring up hinge on one thing (compatibility concerns). So
> far the unit tests pass. From my investigations, I haven't been able to
> find any theoretical reasons why it can't be compatible for 99% of things
> using pygame.
>
> The stronger evidence of tests passing, and no concrete theoretical
> reasons presented on why it can't be compatible suggests to me that it can
> be done. As the patches currently exist, and have for some time, gives me a
> reason to think those fears about OS packagers doing strange things are
> unfounded. As they upgrade SDL versions at different times, I think we
> should still be ok if things are compatible.
>
>
> By not aiming for compatibility we guarantee there won't be. Having a
> compatible pygame API lets us do that, and still release to places where
> SDL2 doesn't exist yet. If considering the API is compatible as I hope,
> then I don't see a problem with people who require SDL2 features seeing if
> they are running on an SDL2 pygame.
>
> A pygame 2.0 would be released under the pygame package name, with SDL 2
> as default, with a pygame compatible API. Until we get to that point pygame
> 1.10.0+ will exist, but patches and conditional compilation will be
> available for SDL2. (as they exist right now, but made easier to select).
> Old modules like cdrom, and overlay will be marked as depreciated.
>
> By using new pygame APIs for differences between SDL1 and SDL2 we allow
> the old apps to continue working. So there should be no sudden break the
> world transition.
>
> If an app really isn't compatible with a newer pygame for some reason
> (unlikely IMHO), then it's still possible for an older version to be
> bundled with pip, conda, and many virtual envs. Things like apt, could do
> like they did with SDL1, and python2 and python3. That is, making pygame1
> into a pygame1-sdl1 package, which perhaps gets installed as pygame1. Then
> the rare cases of old uncompatible apps, which have not been updated
> themselves are covered. But I honestly don't think that will happen.
>
>
>
>
>
>
> On Mon, Mar 20, 2017 at 11:15 AM, Thomas Kluyver  wrote:
>
> Having a codebase compatible with both versions of SDL sounds sensible,
> but having spent a day considering it, I suspect it would be a mistake.
>
> Compatibility is never going to be perfect, so in practice I expect that a
> lot of games will require "pygame 1.10 compiled with SDL 2" or "...with SDL
> 1.2", according to what the developer tested it with. The packaging systems
> I'm familiar with are not able to express a dependency like this. So it
> would be useful if the name (e.g. pygame2) or version (e.g. pygame version
> 2.0) of the package encoded that it was based on SDL 2.
>
> To frame this another way: for most people there will be a sudden
> transition when the pre-compiled packages they use switch to building with
> SDL 2. If pygame makes releases that are compatible with both SDL 

Re: [pygame] pygame with SDL2 proposal

[René Dudfield]

I think this is a really good thing to think through.

The issues you bring up hinge on one thing (compatibility concerns). So far
the unit tests pass. From my investigations, I haven't been able to find
any theoretical reasons why it can't be compatible for 99% of things using
pygame.

The stronger evidence of tests passing, and no concrete theoretical reasons
presented on why it can't be compatible suggests to me that it can be done.
As the patches currently exist, and have for some time, gives me a reason
to think those fears about OS packagers doing strange things are unfounded.
As they upgrade SDL versions at different times, I think we should still be
ok if things are compatible.


By not aiming for compatibility we guarantee there won't be. Having a
compatible pygame API lets us do that, and still release to places where
SDL2 doesn't exist yet. If considering the API is compatible as I hope,
then I don't see a problem with people who require SDL2 features seeing if
they are running on an SDL2 pygame.

A pygame 2.0 would be released under the pygame package name, with SDL 2 as
default, with a pygame compatible API. Until we get to that point pygame
1.10.0+ will exist, but patches and conditional compilation will be
available for SDL2. (as they exist right now, but made easier to select).
Old modules like cdrom, and overlay will be marked as depreciated.

By using new pygame APIs for differences between SDL1 and SDL2 we allow the
old apps to continue working. So there should be no sudden break the world
transition.

If an app really isn't compatible with a newer pygame for some reason
(unlikely IMHO), then it's still possible for an older version to be
bundled with pip, conda, and many virtual envs. Things like apt, could do
like they did with SDL1, and python2 and python3. That is, making pygame1
into a pygame1-sdl1 package, which perhaps gets installed as pygame1. Then
the rare cases of old uncompatible apps, which have not been updated
themselves are covered. But I honestly don't think that will happen.






On Mon, Mar 20, 2017 at 11:15 AM, Thomas Kluyver  wrote:

> Having a codebase compatible with both versions of SDL sounds sensible,
> but having spent a day considering it, I suspect it would be a mistake.
>
> Compatibility is never going to be perfect, so in practice I expect that a
> lot of games will require "pygame 1.10 compiled with SDL 2" or "...with SDL
> 1.2", according to what the developer tested it with. The packaging systems
> I'm familiar with are not able to express a dependency like this. So it
> would be useful if the name (e.g. pygame2) or version (e.g. pygame version
> 2.0) of the package encoded that it was based on SDL 2.
>
> To frame this another way: for most people there will be a sudden
> transition when the pre-compiled packages they use switch to building with
> SDL 2. If pygame makes releases that are compatible with both SDL versions,
> the packages from PyPI, conda, apt, homebrew and so on may make that
> transition at different version numbers, generating confusion. If pygame
> 2.0 simply switches to SDL 2, the switch is coordinated, so the version
> number is a reliable indicator of what you're getting.
>
> So if we do turn the pygame codebase into an SDL 2 wrapper, rather than
> adopting/recommending one of the existing wrappers, I would strongly
> suggest that we a) make a clean switch, not attempting to support both, and
> b) use a new major version number, or even a new package name, to clearly
> distinguish it.
>
> Thomas
>

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

Having a codebase compatible with both versions of SDL sounds sensible, but
having spent a day considering it, I suspect it would be a mistake.

Compatibility is never going to be perfect, so in practice I expect that a
lot of games will require "pygame 1.10 compiled with SDL 2" or "...with SDL
1.2", according to what the developer tested it with. The packaging systems
I'm familiar with are not able to express a dependency like this. So it
would be useful if the name (e.g. pygame2) or version (e.g. pygame version
2.0) of the package encoded that it was based on SDL 2.

To frame this another way: for most people there will be a sudden
transition when the pre-compiled packages they use switch to building with
SDL 2. If pygame makes releases that are compatible with both SDL versions,
the packages from PyPI, conda, apt, homebrew and so on may make that
transition at different version numbers, generating confusion. If pygame
2.0 simply switches to SDL 2, the switch is coordinated, so the version
number is a reliable indicator of what you're getting.

So if we do turn the pygame codebase into an SDL 2 wrapper, rather than
adopting/recommending one of the existing wrappers, I would strongly
suggest that we a) make a clean switch, not attempting to support both, and
b) use a new major version number, or even a new package name, to clearly
distinguish it.

Thomas

Re: [pygame] pygame with SDL2 proposal

[René Dudfield]

"it's probably a good idea to first decide what the actual needs are"​

Some ideas on that...

   - SDL2 provides better platform support in some places, and some nicer
   features.
   - SDL1 provides better platform support in some places.
   - pygame apps would like to continue working.
   - ...

Things like mobile support, I agree are important, but I guess getting the
basics done first is more important. Everything else can flow from there.

Currently we don't even have a good story for distribution on pypi,
windows, linux, or mac (The platforms where people make things on). I think
we should keep our goals humble, and achievable. Complete them, and move on
to the next steps.

Daniel Pope had a good point about not putting in any experimental
features, and to keep it simple. We've learned that lesson, and have
removed things already that were not maintainable. It's the approach that
CPython now takes as well - things need to gain popularity and prove
stability before they are moved in. Additionally now it's much easier to
use external packages via pip, so bundling all together is not as useful as
it once was (binary distribution is still challenging however).

The app distribution work(so people can distribute their own games easily),
I think should continue with the wider python community. A tool I'm working
on has had massive contributions from someone who doesn't use pygame, or
game tools at all. I think that Thomas Kluver probably has the same
experiences with his packaging work. Trying to get things fixed in the
python distribution tools themselves has proved challenging, but has also
proved to sometimes work.

With this proposal, we should be able to work on other things like mobile,
and extended graphics support afterwards. I agree that they are important.
There's also nothing stopping people from working on them separately(or
raising resources to fund that work).

Re: [pygame] pygame with SDL2 proposal

[Tom Rothamel]

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  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  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.
> 

Re: [pygame] pygame with SDL2 proposal

[Leif Theden]

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  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 

Re: [pygame] pygame with SDL2 proposal

[Lenard Lindstrom]

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/

Re: [pygame] pygame with SDL2 proposal

[Lenard Lindstrom]

Hello,

Pygame relies heavily on the new buffer protocol to interact with 
external modules like NumPy. The new buffer protocol is a CPython C api 
level protocol for exposing array data. There is nothing comparable at 
the Python level. In particular, the new buffer protocol allows for a 
callback to call when a client releases a buffer. For a Pygame surface, 
the callback unlocks the surface. The alternative to a callback is to 
unlock the surface when the client object is garbage collected. This 
will not work in PyPy, which lacks reference counting. So much of Pygame 
needs to remain as extension modules to continue to use the new buffer 
protocol, making CFFI less useful.


Lenard Lindstrom

On 17-03-18 10:32 PM, bw wrote:

Hi, thanks for inviting me to opine. :)

[snip]


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:




[snip]


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.

Re: [pygame] pygame with SDL2 proposal

[Leif Theden]

One huge advantage is that it is supported by the main developers. SDL 1.2
won't be getting much development (any?) to combat bitrot and depreciations
of the interfaces it relies on.

After that, there are new interfaces in SDL 2 to make mobile games and apps
fit into the platform better. There is easy hardware accelerated sprites. I
would say those are the highlights.
On Sun, Mar 19, 2017 at 1:43 PM Thomas Kluyver  wrote:

> Going back to basics for a moment: what is the advantage for game
> developers of SDL 2 over 1.2? Is it more performant? Does it offer easier
> to understand abstractions? Can you make games do things that would be
> impossible with 1.2? And are there any downsides to the new version? I
> think we need an idea of the differences to have a useful discussion on
> supporting SDL 2.
>
> Thomas
>
> On 19 Mar 2017 6:04 p.m., "Leif Theden"  wrote:
>
> Idk. You could argue that pygame had a "tight coupling" to pushing pixels
> with a CPU. Or the display for that matter (ever try to use the sound
> module before initializing the display?) In any case, I don't see this
> comparison to Kivy going anywhere.
>
> On Sun, Mar 19, 2017 at 11:49 AM Daniel Pope  wrote:
>
> > It's not a tight coupling, it supports several backends and runs on many
> platforms, from PC to Rpi
>
> That's not the part that I am claiming is a tight coupling. The tight
> coupling is between the OpenGL/input bindings for mobile - which could be
> great, but is incomplete and undocumented - and the UI framework, which I
> don't like.
>
> > I don't think it would take much to have a games API if the community
> put effort in to it.
>
> Exactly - if it has to be an API of Kivy, rather than a separate project
> built upon it, then that's a tight coupling.
>
> On Sun, 19 Mar 2017, 15:47 Leif Theden,  wrote:
>
> I don't follow your idea about mistakes in Kivy. It's not a tight
> coupling, it supports several backends and runs on many platforms, from PC
> to Rpi. I love kivy and have been using it for a long time. It's not
> extremely stable (API changes), but it is light years ahead of pygame in
> terms of usability and functionality.
>
> It may be a bit more cumbersome in Kivy for use with games or extreme
> beginners, but I don't think it would take much to have a games API if the
> community put effort in to it.
>
> I'm all for a simple pygame too, and I don't think the comparison to Kivy
> is appropriate. Kivy is a framework for touch applications primarily.
> On Sun, Mar 19, 2017 at 9:28 AM Daniel Pope  wrote:
>
> Something that I think is important is that we should aim to avoid putting
> experimental stuff into Pygame.
>
> I think it's a mistake Kivy made: tightly coupling excellent work in
> OpenGL ES bindings and deployment on mobile, with a crude UI framework and
> runtime.
>
> I guess all I'm saying is that we should keep Pygame simple, and let other
> projects build the ecosystem on top of it.
>
> On Sun, 19 Mar 2017, 13:27 Leif Theden,  wrote:
>
> My comment from the Reddit:
>
> It has always been my feeling that pygame2 break compatibility with
> pygame1 and embrace modern computer features, namely the GPU. Shoehorning
> the clunky surface & blit API over sdl2 is a major regression. As is, no
> modern game library uses a system like this.
>
> If it is moved to sdl2, then I would like to see it completely move to a
> modern rendering backend, without legacy features. Allow new programmers to
> try out shaders, experiment with opencl, maybe include a full featured SDL2
> backend that you can drop into.
>
> Also:
>
> * first class gamepad support
> * easier to understand sound API
> * remove redundant modules like key, mouse, and joystick
> * more focus on using the event queue
> * more scaffolding, like a drop in event engine, easier setup for the
> screen, and game loop with less boilerplate cruft
>
> At this point pygame1 is useful for quick prototyping and embedded systems
> because it can use a framebuffer. Beyond that? I'm not so sure that pygame
> can be relevant if it trys to support the old software API.
>
> Even SDL2 dropped the software API, for the most part.
>
> pygame_sdl2, guess what, it is trying to be source compatible, and despite
> being written in cython and compiled into native code, it is slower than
> pygame because of the legacy software renderer sdl2 doesn't optimize like
> the original did. To get pygame1 level performance with the legacy API, you
> will need to patch sdl2 and maintain a fork that contains optimized
> blitting code.
>
> If you want to avoid a long transition and constant bickering about
> breaking changes, then you need to introduce a great feature to get people
> to switch. Implement a solid hardware-accelerated Sprite & Groups API and a
> "click to distribute" script in the std. lib and you will have people
> moving very quickly.
>
> Also, drop 

Re: [pygame] pygame with SDL2 proposal

[Thomas Kluyver]

Going back to basics for a moment: what is the advantage for game
developers of SDL 2 over 1.2? Is it more performant? Does it offer easier
to understand abstractions? Can you make games do things that would be
impossible with 1.2? And are there any downsides to the new version? I
think we need an idea of the differences to have a useful discussion on
supporting SDL 2.

Thomas

On 19 Mar 2017 6:04 p.m., "Leif Theden"  wrote:

> Idk. You could argue that pygame had a "tight coupling" to pushing pixels
> with a CPU. Or the display for that matter (ever try to use the sound
> module before initializing the display?) In any case, I don't see this
> comparison to Kivy going anywhere.
>
> On Sun, Mar 19, 2017 at 11:49 AM Daniel Pope  wrote:
>
>> > It's not a tight coupling, it supports several backends and runs on
>> many platforms, from PC to Rpi
>>
>> That's not the part that I am claiming is a tight coupling. The tight
>> coupling is between the OpenGL/input bindings for mobile - which could be
>> great, but is incomplete and undocumented - and the UI framework, which I
>> don't like.
>>
>> > I don't think it would take much to have a games API if the community
>> put effort in to it.
>>
>> Exactly - if it has to be an API of Kivy, rather than a separate project
>> built upon it, then that's a tight coupling.
>>
>> On Sun, 19 Mar 2017, 15:47 Leif Theden,  wrote:
>>
>> I don't follow your idea about mistakes in Kivy. It's not a tight
>> coupling, it supports several backends and runs on many platforms, from PC
>> to Rpi. I love kivy and have been using it for a long time. It's not
>> extremely stable (API changes), but it is light years ahead of pygame in
>> terms of usability and functionality.
>>
>> It may be a bit more cumbersome in Kivy for use with games or extreme
>> beginners, but I don't think it would take much to have a games API if the
>> community put effort in to it.
>>
>> I'm all for a simple pygame too, and I don't think the comparison to Kivy
>> is appropriate. Kivy is a framework for touch applications primarily.
>> On Sun, Mar 19, 2017 at 9:28 AM Daniel Pope  wrote:
>>
>> Something that I think is important is that we should aim to avoid
>> putting experimental stuff into Pygame.
>>
>> I think it's a mistake Kivy made: tightly coupling excellent work in
>> OpenGL ES bindings and deployment on mobile, with a crude UI framework and
>> runtime.
>>
>> I guess all I'm saying is that we should keep Pygame simple, and let
>> other projects build the ecosystem on top of it.
>>
>> On Sun, 19 Mar 2017, 13:27 Leif Theden,  wrote:
>>
>> My comment from the Reddit:
>>
>> It has always been my feeling that pygame2 break compatibility with
>> pygame1 and embrace modern computer features, namely the GPU. Shoehorning
>> the clunky surface & blit API over sdl2 is a major regression. As is, no
>> modern game library uses a system like this.
>>
>> If it is moved to sdl2, then I would like to see it completely move to a
>> modern rendering backend, without legacy features. Allow new programmers to
>> try out shaders, experiment with opencl, maybe include a full featured SDL2
>> backend that you can drop into.
>>
>> Also:
>>
>> * first class gamepad support
>> * easier to understand sound API
>> * remove redundant modules like key, mouse, and joystick
>> * more focus on using the event queue
>> * more scaffolding, like a drop in event engine, easier setup for the
>> screen, and game loop with less boilerplate cruft
>>
>> At this point pygame1 is useful for quick prototyping and embedded
>> systems because it can use a framebuffer. Beyond that? I'm not so sure that
>> pygame can be relevant if it trys to support the old software API.
>>
>> Even SDL2 dropped the software API, for the most part.
>>
>> pygame_sdl2, guess what, it is trying to be source compatible, and
>> despite being written in cython and compiled into native code, it is slower
>> than pygame because of the legacy software renderer sdl2 doesn't optimize
>> like the original did. To get pygame1 level performance with the legacy
>> API, you will need to patch sdl2 and maintain a fork that contains
>> optimized blitting code.
>>
>> If you want to avoid a long transition and constant bickering about
>> breaking changes, then you need to introduce a great feature to get people
>> to switch. Implement a solid hardware-accelerated Sprite & Groups API and a
>> "click to distribute" script in the std. lib and you will have people
>> moving very quickly.
>>
>> Also, drop python 2 support. Just my thoughts.
>> On Sun, Mar 19, 2017 at 8:04 AM René Dudfield  wrote:
>>
>> There's some more conversation over on the reddit.
>> https://www.reddit.com/r/pygame/comments/604cxw/pygame_
>> with_sdl2_proposal_pygame_dev_ren%C3%A9/
>>
>>
>> On Sun, Mar 19, 2017 at 8:57 AM, René Dudfield  wrote:
>>
>> Haha. "import pygumm" 

Re: [pygame] pygame with SDL2 proposal

[Daniel Pope]

> It's not a tight coupling, it supports several backends and runs on many
platforms, from PC to Rpi

That's not the part that I am claiming is a tight coupling. The tight
coupling is between the OpenGL/input bindings for mobile - which could be
great, but is incomplete and undocumented - and the UI framework, which I
don't like.

> I don't think it would take much to have a games API if the community put
effort in to it.

Exactly - if it has to be an API of Kivy, rather than a separate project
built upon it, then that's a tight coupling.

On Sun, 19 Mar 2017, 15:47 Leif Theden,  wrote:

> I don't follow your idea about mistakes in Kivy. It's not a tight
> coupling, it supports several backends and runs on many platforms, from PC
> to Rpi. I love kivy and have been using it for a long time. It's not
> extremely stable (API changes), but it is light years ahead of pygame in
> terms of usability and functionality.
>
> It may be a bit more cumbersome in Kivy for use with games or extreme
> beginners, but I don't think it would take much to have a games API if the
> community put effort in to it.
>
> I'm all for a simple pygame too, and I don't think the comparison to Kivy
> is appropriate. Kivy is a framework for touch applications primarily.
> On Sun, Mar 19, 2017 at 9:28 AM Daniel Pope  wrote:
>
> Something that I think is important is that we should aim to avoid putting
> experimental stuff into Pygame.
>
> I think it's a mistake Kivy made: tightly coupling excellent work in
> OpenGL ES bindings and deployment on mobile, with a crude UI framework and
> runtime.
>
> I guess all I'm saying is that we should keep Pygame simple, and let other
> projects build the ecosystem on top of it.
>
> On Sun, 19 Mar 2017, 13:27 Leif Theden,  wrote:
>
> My comment from the Reddit:
>
> It has always been my feeling that pygame2 break compatibility with
> pygame1 and embrace modern computer features, namely the GPU. Shoehorning
> the clunky surface & blit API over sdl2 is a major regression. As is, no
> modern game library uses a system like this.
>
> If it is moved to sdl2, then I would like to see it completely move to a
> modern rendering backend, without legacy features. Allow new programmers to
> try out shaders, experiment with opencl, maybe include a full featured SDL2
> backend that you can drop into.
>
> Also:
>
> * first class gamepad support
> * easier to understand sound API
> * remove redundant modules like key, mouse, and joystick
> * more focus on using the event queue
> * more scaffolding, like a drop in event engine, easier setup for the
> screen, and game loop with less boilerplate cruft
>
> At this point pygame1 is useful for quick prototyping and embedded systems
> because it can use a framebuffer. Beyond that? I'm not so sure that pygame
> can be relevant if it trys to support the old software API.
>
> Even SDL2 dropped the software API, for the most part.
>
> pygame_sdl2, guess what, it is trying to be source compatible, and despite
> being written in cython and compiled into native code, it is slower than
> pygame because of the legacy software renderer sdl2 doesn't optimize like
> the original did. To get pygame1 level performance with the legacy API, you
> will need to patch sdl2 and maintain a fork that contains optimized
> blitting code.
>
> If you want to avoid a long transition and constant bickering about
> breaking changes, then you need to introduce a great feature to get people
> to switch. Implement a solid hardware-accelerated Sprite & Groups API and a
> "click to distribute" script in the std. lib and you will have people
> moving very quickly.
>
> Also, drop python 2 support. Just my thoughts.
> On Sun, Mar 19, 2017 at 8:04 AM René Dudfield  wrote:
>
> There's some more conversation over on the reddit.
>
> https://www.reddit.com/r/pygame/comments/604cxw/pygame_with_sdl2_proposal_pygame_dev_ren%C3%A9/
>
>
> On Sun, Mar 19, 2017 at 8:57 AM, René Dudfield  wrote:
>
> Haha. "import pygumm" definitely does sound better. Seriously.
>
> For *me* pypy is a non goal, and CFFI has some drawbacks. I know pypy also
> has plenty of upsides in certain cases... which has been mentioned a lot,
> so I won't repeat the good parts about it here.
>
>
> This was my reasoning...
>
>- CFFI is slower on CPython. CPython is what 99% of people use.
>- People don't really contribute if something is in python which
>interfaces in C - and they only know python. This has been proven by other
>cffi and ctypes projects. Ctypes, and CFFI is a much rarer skill than
>standard platform tools. C still happens to be very widely known.
>- CFFI has issues on weird platforms... like iOS.
>- Cython, numba, numexpr are available. Numpy is not hard to install
>any more. These are faster than pypy in throughput, and latency.
>- Shaders in GLSL are pretty damn amazing if you need cross platform

Re: [pygame] pygame with SDL2 proposal

[Leif Theden]

I don't follow your idea about mistakes in Kivy. It's not a tight coupling,
it supports several backends and runs on many platforms, from PC to Rpi. I
love kivy and have been using it for a long time. It's not extremely stable
(API changes), but it is light years ahead of pygame in terms of usability
and functionality.

It may be a bit more cumbersome in Kivy for use with games or extreme
beginners, but I don't think it would take much to have a games API if the
community put effort in to it.

I'm all for a simple pygame too, and I don't think the comparison to Kivy
is appropriate. Kivy is a framework for touch applications primarily.
On Sun, Mar 19, 2017 at 9:28 AM Daniel Pope  wrote:

> Something that I think is important is that we should aim to avoid putting
> experimental stuff into Pygame.
>
> I think it's a mistake Kivy made: tightly coupling excellent work in
> OpenGL ES bindings and deployment on mobile, with a crude UI framework and
> runtime.
>
> I guess all I'm saying is that we should keep Pygame simple, and let other
> projects build the ecosystem on top of it.
>
> On Sun, 19 Mar 2017, 13:27 Leif Theden,  wrote:
>
> My comment from the Reddit:
>
> It has always been my feeling that pygame2 break compatibility with
> pygame1 and embrace modern computer features, namely the GPU. Shoehorning
> the clunky surface & blit API over sdl2 is a major regression. As is, no
> modern game library uses a system like this.
>
> If it is moved to sdl2, then I would like to see it completely move to a
> modern rendering backend, without legacy features. Allow new programmers to
> try out shaders, experiment with opencl, maybe include a full featured SDL2
> backend that you can drop into.
>
> Also:
>
> * first class gamepad support
> * easier to understand sound API
> * remove redundant modules like key, mouse, and joystick
> * more focus on using the event queue
> * more scaffolding, like a drop in event engine, easier setup for the
> screen, and game loop with less boilerplate cruft
>
> At this point pygame1 is useful for quick prototyping and embedded systems
> because it can use a framebuffer. Beyond that? I'm not so sure that pygame
> can be relevant if it trys to support the old software API.
>
> Even SDL2 dropped the software API, for the most part.
>
> pygame_sdl2, guess what, it is trying to be source compatible, and despite
> being written in cython and compiled into native code, it is slower than
> pygame because of the legacy software renderer sdl2 doesn't optimize like
> the original did. To get pygame1 level performance with the legacy API, you
> will need to patch sdl2 and maintain a fork that contains optimized
> blitting code.
>
> If you want to avoid a long transition and constant bickering about
> breaking changes, then you need to introduce a great feature to get people
> to switch. Implement a solid hardware-accelerated Sprite & Groups API and a
> "click to distribute" script in the std. lib and you will have people
> moving very quickly.
>
> Also, drop python 2 support. Just my thoughts.
> On Sun, Mar 19, 2017 at 8:04 AM René Dudfield  wrote:
>
> There's some more conversation over on the reddit.
>
> https://www.reddit.com/r/pygame/comments/604cxw/pygame_with_sdl2_proposal_pygame_dev_ren%C3%A9/
>
>
> On Sun, Mar 19, 2017 at 8:57 AM, René Dudfield  wrote:
>
> Haha. "import pygumm" definitely does sound better. Seriously.
>
> For *me* pypy is a non goal, and CFFI has some drawbacks. I know pypy also
> has plenty of upsides in certain cases... which has been mentioned a lot,
> so I won't repeat the good parts about it here.
>
>
> This was my reasoning...
>
>- CFFI is slower on CPython. CPython is what 99% of people use.
>- People don't really contribute if something is in python which
>interfaces in C - and they only know python. This has been proven by other
>cffi and ctypes projects. Ctypes, and CFFI is a much rarer skill than
>standard platform tools. C still happens to be very widely known.
>- CFFI has issues on weird platforms... like iOS.
>- Cython, numba, numexpr are available. Numpy is not hard to install
>any more. These are faster than pypy in throughput, and latency.
>- Shaders in GLSL are pretty damn amazing if you need cross platform
>CPU/GPU acceleration.
>- pypy has jit warm up, jankiness because of jit and GC, and also
>doesn't work on weird platforms like iOS.
>- Converting everything to shared libraries, and supporting pypy is a
>whole lot more effort. However, in general I support sending things
>upstream and separating the C/asm code from the python code. So that it's
>easier for other people to use them, and there is less maintenance on
>pygame itself. However, packaging up shared libraries for multiple
>platforms is a lot of work. If those shared libraries are not already
>packaged for the 24 platforms, that 

Re: [pygame] pygame with SDL2 proposal

[Daniel Pope]

Something that I think is important is that we should aim to avoid putting
experimental stuff into Pygame.

I think it's a mistake Kivy made: tightly coupling excellent work in OpenGL
ES bindings and deployment on mobile, with a crude UI framework and runtime.

I guess all I'm saying is that we should keep Pygame simple, and let other
projects build the ecosystem on top of it.

On Sun, 19 Mar 2017, 13:27 Leif Theden,  wrote:

> My comment from the Reddit:
>
> It has always been my feeling that pygame2 break compatibility with
> pygame1 and embrace modern computer features, namely the GPU. Shoehorning
> the clunky surface & blit API over sdl2 is a major regression. As is, no
> modern game library uses a system like this.
>
> If it is moved to sdl2, then I would like to see it completely move to a
> modern rendering backend, without legacy features. Allow new programmers to
> try out shaders, experiment with opencl, maybe include a full featured SDL2
> backend that you can drop into.
>
> Also:
>
> * first class gamepad support
> * easier to understand sound API
> * remove redundant modules like key, mouse, and joystick
> * more focus on using the event queue
> * more scaffolding, like a drop in event engine, easier setup for the
> screen, and game loop with less boilerplate cruft
>
> At this point pygame1 is useful for quick prototyping and embedded systems
> because it can use a framebuffer. Beyond that? I'm not so sure that pygame
> can be relevant if it trys to support the old software API.
>
> Even SDL2 dropped the software API, for the most part.
>
> pygame_sdl2, guess what, it is trying to be source compatible, and despite
> being written in cython and compiled into native code, it is slower than
> pygame because of the legacy software renderer sdl2 doesn't optimize like
> the original did. To get pygame1 level performance with the legacy API, you
> will need to patch sdl2 and maintain a fork that contains optimized
> blitting code.
>
> If you want to avoid a long transition and constant bickering about
> breaking changes, then you need to introduce a great feature to get people
> to switch. Implement a solid hardware-accelerated Sprite & Groups API and a
> "click to distribute" script in the std. lib and you will have people
> moving very quickly.
>
> Also, drop python 2 support. Just my thoughts.
> On Sun, Mar 19, 2017 at 8:04 AM René Dudfield  wrote:
>
> There's some more conversation over on the reddit.
>
> https://www.reddit.com/r/pygame/comments/604cxw/pygame_with_sdl2_proposal_pygame_dev_ren%C3%A9/
>
>
> On Sun, Mar 19, 2017 at 8:57 AM, René Dudfield  wrote:
>
> Haha. "import pygumm" definitely does sound better. Seriously.
>
> For *me* pypy is a non goal, and CFFI has some drawbacks. I know pypy also
> has plenty of upsides in certain cases... which has been mentioned a lot,
> so I won't repeat the good parts about it here.
>
>
> This was my reasoning...
>
>- CFFI is slower on CPython. CPython is what 99% of people use.
>- People don't really contribute if something is in python which
>interfaces in C - and they only know python. This has been proven by other
>cffi and ctypes projects. Ctypes, and CFFI is a much rarer skill than
>standard platform tools. C still happens to be very widely known.
>- CFFI has issues on weird platforms... like iOS.
>- Cython, numba, numexpr are available. Numpy is not hard to install
>any more. These are faster than pypy in throughput, and latency.
>- Shaders in GLSL are pretty damn amazing if you need cross platform
>CPU/GPU acceleration.
>- pypy has jit warm up, jankiness because of jit and GC, and also
>doesn't work on weird platforms like iOS.
>- Converting everything to shared libraries, and supporting pypy is a
>whole lot more effort. However, in general I support sending things
>upstream and separating the C/asm code from the python code. So that it's
>easier for other people to use them, and there is less maintenance on
>pygame itself. However, packaging up shared libraries for multiple
>platforms is a lot of work. If those shared libraries are not already
>packaged for the 24 platforms, that actually creates maintenance burden as
>well.
>- pygame_cffi is slower on pypy than on CPython for many apps where
>the bottlenecks are already in the C/asm/platform code. Before the pypy
>project took funding, forked pygame, removed credits and copyright info,
>they were warned that blit was the bottleneck. So, like in a lot of things,
>it looks good in their benchmarks, but for real world things it doesn't
>perform so well - in many cases.
>- pypy uses significantly larger amounts of memory. Which is important
>for some older, or low memory systems.
>- pypy is slower than CPython where it matters for real time apps.
>Where pypy is faster, there are faster extensions available for CPython,
> 

Re: [pygame] pygame with SDL2 proposal

[Leif Theden]

My comment from the Reddit:

It has always been my feeling that pygame2 break compatibility with pygame1
and embrace modern computer features, namely the GPU. Shoehorning the
clunky surface & blit API over sdl2 is a major regression. As is, no modern
game library uses a system like this.

If it is moved to sdl2, then I would like to see it completely move to a
modern rendering backend, without legacy features. Allow new programmers to
try out shaders, experiment with opencl, maybe include a full featured SDL2
backend that you can drop into.

Also:

* first class gamepad support
* easier to understand sound API
* remove redundant modules like key, mouse, and joystick
* more focus on using the event queue
* more scaffolding, like a drop in event engine, easier setup for the
screen, and game loop with less boilerplate cruft

At this point pygame1 is useful for quick prototyping and embedded systems
because it can use a framebuffer. Beyond that? I'm not so sure that pygame
can be relevant if it trys to support the old software API.

Even SDL2 dropped the software API, for the most part.

pygame_sdl2, guess what, it is trying to be source compatible, and despite
being written in cython and compiled into native code, it is slower than
pygame because of the legacy software renderer sdl2 doesn't optimize like
the original did. To get pygame1 level performance with the legacy API, you
will need to patch sdl2 and maintain a fork that contains optimized
blitting code.

If you want to avoid a long transition and constant bickering about
breaking changes, then you need to introduce a great feature to get people
to switch. Implement a solid hardware-accelerated Sprite & Groups API and a
"click to distribute" script in the std. lib and you will have people
moving very quickly.

Also, drop python 2 support. Just my thoughts.
On Sun, Mar 19, 2017 at 8:04 AM René Dudfield  wrote:

> There's some more conversation over on the reddit.
>
> https://www.reddit.com/r/pygame/comments/604cxw/pygame_with_sdl2_proposal_pygame_dev_ren%C3%A9/
>
>
> On Sun, Mar 19, 2017 at 8:57 AM, René Dudfield  wrote:
>
> Haha. "import pygumm" definitely does sound better. Seriously.
>
> For *me* pypy is a non goal, and CFFI has some drawbacks. I know pypy also
> has plenty of upsides in certain cases... which has been mentioned a lot,
> so I won't repeat the good parts about it here.
>
>
> This was my reasoning...
>
>- CFFI is slower on CPython. CPython is what 99% of people use.
>- People don't really contribute if something is in python which
>interfaces in C - and they only know python. This has been proven by other
>cffi and ctypes projects. Ctypes, and CFFI is a much rarer skill than
>standard platform tools. C still happens to be very widely known.
>- CFFI has issues on weird platforms... like iOS.
>- Cython, numba, numexpr are available. Numpy is not hard to install
>any more. These are faster than pypy in throughput, and latency.
>- Shaders in GLSL are pretty damn amazing if you need cross platform
>CPU/GPU acceleration.
>- pypy has jit warm up, jankiness because of jit and GC, and also
>doesn't work on weird platforms like iOS.
>- Converting everything to shared libraries, and supporting pypy is a
>whole lot more effort. However, in general I support sending things
>upstream and separating the C/asm code from the python code. So that it's
>easier for other people to use them, and there is less maintenance on
>pygame itself. However, packaging up shared libraries for multiple
>platforms is a lot of work. If those shared libraries are not already
>packaged for the 24 platforms, that actually creates maintenance burden as
>well.
>- pygame_cffi is slower on pypy than on CPython for many apps where
>the bottlenecks are already in the C/asm/platform code. Before the pypy
>project took funding, forked pygame, removed credits and copyright info,
>they were warned that blit was the bottleneck. So, like in a lot of things,
>it looks good in their benchmarks, but for real world things it doesn't
>perform so well - in many cases.
>- pypy uses significantly larger amounts of memory. Which is important
>for some older, or low memory systems.
>- pypy is slower than CPython where it matters for real time apps.
>Where pypy is faster, there are faster extensions available for CPython,
>and more appropriate for game JITs. Pypy has many performance cliffs, where
>it is really fast for some things after lots of warmup, but then for some
>magic un-obvious reason you fall into the valley of slow. The baseline pure
>python code performance is always faster in CPython when the jit can't
>work. Lower bound performance, and consistent performance turns out to be
>really important to real time apps. This means you can write a lot more
>code in python, without falling into the valley of 

Re: [pygame] pygame with SDL2 proposal

[René Dudfield]

There's some more conversation over on the reddit.
https://www.reddit.com/r/pygame/comments/604cxw/pygame_with_sdl2_proposal_pygame_dev_ren%C3%A9/


On Sun, Mar 19, 2017 at 8:57 AM, René Dudfield  wrote:

> Haha. "import pygumm" definitely does sound better. Seriously.
>
> For *me* pypy is a non goal, and CFFI has some drawbacks. I know pypy also
> has plenty of upsides in certain cases... which has been mentioned a lot,
> so I won't repeat the good parts about it here.
>
>
> This was my reasoning...
>
>- CFFI is slower on CPython. CPython is what 99% of people use.
>- People don't really contribute if something is in python which
>interfaces in C - and they only know python. This has been proven by other
>cffi and ctypes projects. Ctypes, and CFFI is a much rarer skill than
>standard platform tools. C still happens to be very widely known.
>- CFFI has issues on weird platforms... like iOS.
>- Cython, numba, numexpr are available. Numpy is not hard to install
>any more. These are faster than pypy in throughput, and latency.
>- Shaders in GLSL are pretty damn amazing if you need cross platform
>CPU/GPU acceleration.
>- pypy has jit warm up, jankiness because of jit and GC, and also
>doesn't work on weird platforms like iOS.
>- Converting everything to shared libraries, and supporting pypy is a
>whole lot more effort. However, in general I support sending things
>upstream and separating the C/asm code from the python code. So that it's
>easier for other people to use them, and there is less maintenance on
>pygame itself. However, packaging up shared libraries for multiple
>platforms is a lot of work. If those shared libraries are not already
>packaged for the 24 platforms, that actually creates maintenance burden as
>well.
>- pygame_cffi is slower on pypy than on CPython for many apps where
>the bottlenecks are already in the C/asm/platform code. Before the pypy
>project took funding, forked pygame, removed credits and copyright info,
>they were warned that blit was the bottleneck. So, like in a lot of things,
>it looks good in their benchmarks, but for real world things it doesn't
>perform so well - in many cases.
>- pypy uses significantly larger amounts of memory. Which is important
>for some older, or low memory systems.
>- pypy is slower than CPython where it matters for real time apps.
>Where pypy is faster, there are faster extensions available for CPython,
>and more appropriate for game JITs. Pypy has many performance cliffs, where
>it is really fast for some things after lots of warmup, but then for some
>magic un-obvious reason you fall into the valley of slow. The baseline pure
>python code performance is always faster in CPython when the jit can't
>work. Lower bound performance, and consistent performance turns out to be
>really important to real time apps. This means you can write a lot more
>code in python, without falling into the valley of slow.
>
> Happy to take patches for pygame to help make it easier for anyone who
> wants to share code. Rect is mainly an SDL thing, with a whole bunch of
> niceties mostly at the python integration level. I'm not sure how to
> separate any of that really. There are pure python implementations of Rect,
> and perhaps you could use that to implement something in RPython for
> integration with pypy? But I think perhaps this runs into the case where
> integrating with C is slower in CFFI when there are lots of calls which
> take very little time. I'm sure the pypy CFFI people could help you there.
>
> Again, there are definitely some good use cases for pypy, and CFFI. Even
> in games. Like in your game. But for me, and for the reasons above, I don't
> think it's a good idea for pygame. At the moment.
>
>
> CPython has had some really nice speed improvements recently (since 2015).
> Python 3.6 is good, and 3.7 is looking significantly faster for some
> benchmarks.
> https://speed.python.org/comparison/?exe=5%2BL%
> 2Bdefault%2C5%2BL%2B2.7=223%2C224%2C225%2C226%2C227%
> 2C228%2C229%2C230%2C231%2C232%2C233%2C234%2C235%2C236%2C237%
> 2C238%2C239%2C287%2C240%2C241%2C242%2C243%2C244%2C245%2C246%
> 2C247%2C248%2C249%2C250%2C251%2C252%2C253%2C254%2C255%2C288%
> 2C256%2C257%2C258%2C259%2C260%2C261%2C262%2C263%2C264%2C265%
> 2C266%2C267%2C268%2C289%2C269%2C270%2C271%2C272%2C273%2C274%
> 2C276%2C275%2C277%2C278%2C279%2C280%2C281%2C282%2C285%2C284%
> 2C283%2C286=1=true=none=normal+bars
>
> Especially with all the FASTCALL work.
> https://haypo.github.io/fastcall-issues.html
> http://faster-cpython.readthedocs.io/fat_python.html
> Accepted CPython jit API pep.
> https://www.python.org/dev/peps/pep-0523/
>
>
> I like this trend where people have decided to work together to get things
> into the CPython project, rather than do forks.
>
>
> cheers,
>
>
>
>
> On Sun, Mar 19, 2017 at 6:32 AM, bw 

Re: [pygame] pygame with SDL2 proposal

[René Dudfield]

Haha. "import pygumm" definitely does sound better. Seriously.

For *me* pypy is a non goal, and CFFI has some drawbacks. I know pypy also
has plenty of upsides in certain cases... which has been mentioned a lot,
so I won't repeat the good parts about it here.


This was my reasoning...

   - CFFI is slower on CPython. CPython is what 99% of people use.
   - People don't really contribute if something is in python which
   interfaces in C - and they only know python. This has been proven by other
   cffi and ctypes projects. Ctypes, and CFFI is a much rarer skill than
   standard platform tools. C still happens to be very widely known.
   - CFFI has issues on weird platforms... like iOS.
   - Cython, numba, numexpr are available. Numpy is not hard to install any
   more. These are faster than pypy in throughput, and latency.
   - Shaders in GLSL are pretty damn amazing if you need cross platform
   CPU/GPU acceleration.
   - pypy has jit warm up, jankiness because of jit and GC, and also
   doesn't work on weird platforms like iOS.
   - Converting everything to shared libraries, and supporting pypy is a
   whole lot more effort. However, in general I support sending things
   upstream and separating the C/asm code from the python code. So that it's
   easier for other people to use them, and there is less maintenance on
   pygame itself. However, packaging up shared libraries for multiple
   platforms is a lot of work. If those shared libraries are not already
   packaged for the 24 platforms, that actually creates maintenance burden as
   well.
   - pygame_cffi is slower on pypy than on CPython for many apps where the
   bottlenecks are already in the C/asm/platform code. Before the pypy project
   took funding, forked pygame, removed credits and copyright info, they were
   warned that blit was the bottleneck. So, like in a lot of things, it looks
   good in their benchmarks, but for real world things it doesn't perform so
   well - in many cases.
   - pypy uses significantly larger amounts of memory. Which is important
   for some older, or low memory systems.
   - pypy is slower than CPython where it matters for real time apps. Where
   pypy is faster, there are faster extensions available for CPython, and more
   appropriate for game JITs. Pypy has many performance cliffs, where it is
   really fast for some things after lots of warmup, but then for some magic
   un-obvious reason you fall into the valley of slow. The baseline pure
   python code performance is always faster in CPython when the jit can't
   work. Lower bound performance, and consistent performance turns out to be
   really important to real time apps. This means you can write a lot more
   code in python, without falling into the valley of slow.

Happy to take patches for pygame to help make it easier for anyone who
wants to share code. Rect is mainly an SDL thing, with a whole bunch of
niceties mostly at the python integration level. I'm not sure how to
separate any of that really. There are pure python implementations of Rect,
and perhaps you could use that to implement something in RPython for
integration with pypy? But I think perhaps this runs into the case where
integrating with C is slower in CFFI when there are lots of calls which
take very little time. I'm sure the pypy CFFI people could help you there.

Again, there are definitely some good use cases for pypy, and CFFI. Even in
games. Like in your game. But for me, and for the reasons above, I don't
think it's a good idea for pygame. At the moment.


CPython has had some really nice speed improvements recently (since 2015).
Python 3.6 is good, and 3.7 is looking significantly faster for some
benchmarks.

https://speed.python.org/comparison/?exe=5%2BL%2Bdefault%2C5%2BL%2B2.7=223%2C224%2C225%2C226%2C227%2C228%2C229%2C230%2C231%2C232%2C233%2C234%2C235%2C236%2C237%2C238%2C239%2C287%2C240%2C241%2C242%2C243%2C244%2C245%2C246%2C247%2C248%2C249%2C250%2C251%2C252%2C253%2C254%2C255%2C288%2C256%2C257%2C258%2C259%2C260%2C261%2C262%2C263%2C264%2C265%2C266%2C267%2C268%2C289%2C269%2C270%2C271%2C272%2C273%2C274%2C276%2C275%2C277%2C278%2C279%2C280%2C281%2C282%2C285%2C284%2C283%2C286=1=true=none=normal+bars

Especially with all the FASTCALL work.
https://haypo.github.io/fastcall-issues.html
http://faster-cpython.readthedocs.io/fat_python.html
Accepted CPython jit API pep.
https://www.python.org/dev/peps/pep-0523/


I like this trend where people have decided to work together to get things
into the CPython project, rather than do forks.


cheers,




On Sun, Mar 19, 2017 at 6:32 AM, bw  wrote:

> 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 

Re: [pygame] pygame with SDL2 proposal

[bw]

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