Re: [pygame] Pygame_SDL2 Nightly Builds

[dvp1964]

Wow, Tom rothmal.  Haven't seen that name sine LILUG years ago, Tim sailor too, 
but I think he isn't at bnl.gov any more.  I'm sure you do not remember me. Any 
way, hi.

Sent from my Galaxy Tab® A Original message From: Tom Rothamel 
<t...@rothamel.us> Date: 01/24/2016  4:09 PM  (GMT-05:00) To: 
pygame-users@seul.org Subject: Re: [pygame] Pygame_SDL2 Nightly Builds 
On Sun, Jan 24, 2016 at 3:35 PM Wout Goud <wbertr...@gmail.com> wrote:
Nice to see a proper release of Pygame_SDL2!

Thanks. Pygame handles multiple screens on another way than Pygame_SDL2... (at 
least ~5 months ago)

I'm not sure what you mean by this. Are you talking about the recent changes to 
list_modes? Or something else? Do you mean RAPT with "the Android version of 
Pygame_SDL2"?

If yes, is it still as slow as ~5 months ago on Android?
It really depends on what you're doing. Startup time should be significantly 
improved, but at the end of the day a mobile device can't push as many pixels 
as a desktop can - especially when using the software renderer, which is what 
pygame assumes.
 

Re: [pygame] Pygame_SDL2 Nightly Builds

[Wout Goud]

That Pygame handles multiple screens on another way than Pygame_SDL2 can be
seen on i.imgur.com/MaLrwBx.jpg. At the left side is is Pygame_SDL2 and at
the right side is Pygame. Everything in the blue box is on my laptop's
screen (left-under) and above it is my external screen and right-under is
something which isn't on a screen. Pygame_SDL2 returns the width and height
of the most above screen, but Pygame returns the total width and height of
both screens. I don't know if it's related to SDL(2).
Op 25 jan. 2016 07:19 schreef "DiliupG" :

> Great news. Waitingforthe Windows stable
>
> 
>  This
> email has been sent from a virus-free computer protected by Avast.
> www.avast.com
> 
> <#1367478485_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, Jan 25, 2016 at 2:39 AM, Tom Rothamel  wrote:
>
>> On Sun, Jan 24, 2016 at 3:35 PM Wout Goud  wrote:
>>
>>> Nice to see a proper release of Pygame_SDL2!
>>>
>>>
>> Thanks.
>>
>>
>>> Pygame handles multiple screens on another way than Pygame_SDL2... (at
>>> least ~5 months ago)
>>>
>>>
>> I'm not sure what you mean by this. Are you talking about the recent
>> changes to list_modes? Or something else?
>>
>>
>>> Do you mean RAPT with "the Android version of Pygame_SDL2"?
>>> If yes, is it still as slow as ~5 months ago on Android?
>>>
>>
>> It really depends on what you're doing. Startup time should be
>> significantly improved, but at the end of the day a mobile device can't
>> push as many pixels as a desktop can - especially when using the software
>> renderer, which is what pygame assumes.
>>
>>
>>>
>
>
> --
> Diliup Gabadamudalige
>
> http://www.diliupg.com
> http://soft.diliupg.com/
>
>
> **
> This e-mail is confidential. It may also be legally privileged. If you are
> not the intended recipient or have received it in error, please delete it
> and all copies from your system and notify the sender immediately by return
> e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited and may
> be unlawful. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability for any
> errors or omissions.
>
> **
>
>

Re: [pygame] Pygame_SDL2 Nightly Builds

[DiliupG]

Great news. Waitingforthe Windows stable

This
email has been sent from a virus-free computer protected by Avast.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Jan 25, 2016 at 2:39 AM, Tom Rothamel  wrote:

> On Sun, Jan 24, 2016 at 3:35 PM Wout Goud  wrote:
>
>> Nice to see a proper release of Pygame_SDL2!
>>
>>
> Thanks.
>
>
>> Pygame handles multiple screens on another way than Pygame_SDL2... (at
>> least ~5 months ago)
>>
>>
> I'm not sure what you mean by this. Are you talking about the recent
> changes to list_modes? Or something else?
>
>
>> Do you mean RAPT with "the Android version of Pygame_SDL2"?
>> If yes, is it still as slow as ~5 months ago on Android?
>>
>
> It really depends on what you're doing. Startup time should be
> significantly improved, but at the end of the day a mobile device can't
> push as many pixels as a desktop can - especially when using the software
> renderer, which is what pygame assumes.
>
>
>>


-- 
Diliup Gabadamudalige

http://www.diliupg.com
http://soft.diliupg.com/

**
This e-mail is confidential. It may also be legally privileged. If you are
not the intended recipient or have received it in error, please delete it
and all copies from your system and notify the sender immediately by return
e-mail. Any unauthorized reading, reproducing, printing or further
dissemination of this e-mail or its contents is strictly prohibited and may
be unlawful. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
**

[pygame] Pygame_SDL2 Nightly Builds

[Tom Rothamel]

Hello again. I'm getting ready to make the first proper release of
Pygame_SDL2, a mostly compatible reimplementation of the Pygame API on top
of the SDL2 libraries.

As part of that, I've been fixing a number of outstanding of issues, and
I've set things up so that we're producing nightly builds of the source
tarball, and nightly wheels for 32- and 64-bit versions of Python 2.7 and
3.5 on Windows.

Pygame_SDL2 can be found on github:

https://github.com/renpy/pygame_sdl2

And the nightlies can be found at:

http://nightly.renpy.org/pygame_sdl2/

The eventual goal - in the next couple of weeks - is to get Pygame_SDL2 up
on pypi so that it can be installed via pip on Windows.

While I think Pygame_SDL2 is getting to be usable for other projects, more
work can be done. Testing is still ad-hoc and minimal, so any help getting
the pygame test suite working would be appreciated, as would any other
contributions people want to supply.

Ps. I was able to use the Android Runtime for Chrome to get the Android
version of Pygame_SDL2 working inside the Chrome web browser. While it
still needs some work in order to properly handle things like
multiple-button mice, this paves the way for Chrome OS joining iOS and
Android as a new platform the Pygame API runs on.

Re: [pygame] Pygame_SDL2 Nightly Builds

[Tom Rothamel]

On Sun, Jan 24, 2016 at 3:35 PM Wout Goud  wrote:

> Nice to see a proper release of Pygame_SDL2!
>
>
Thanks.


> Pygame handles multiple screens on another way than Pygame_SDL2... (at
> least ~5 months ago)
>
>
I'm not sure what you mean by this. Are you talking about the recent
changes to list_modes? Or something else?


> Do you mean RAPT with "the Android version of Pygame_SDL2"?
> If yes, is it still as slow as ~5 months ago on Android?
>

It really depends on what you're doing. Startup time should be
significantly improved, but at the end of the day a mobile device can't
push as many pixels as a desktop can - especially when using the software
renderer, which is what pygame assumes.


>

Re: [pygame] Pygame_SDL2 Nightly Builds

[Wout Goud]

Nice to see a proper release of Pygame_SDL2!

Pygame handles multiple screens on another way than Pygame_SDL2... (at
least ~5 months ago)

Do you mean RAPT with "the Android version of Pygame_SDL2"?
If yes, is it still as slow as ~5 months ago on Android?
Op 24 jan. 2016 21:00 schreef "Tom Rothamel" :

> Hello again. I'm getting ready to make the first proper release of
> Pygame_SDL2, a mostly compatible reimplementation of the Pygame API on top
> of the SDL2 libraries.
>
> As part of that, I've been fixing a number of outstanding of issues, and
> I've set things up so that we're producing nightly builds of the source
> tarball, and nightly wheels for 32- and 64-bit versions of Python 2.7 and
> 3.5 on Windows.
>
> Pygame_SDL2 can be found on github:
>
> https://github.com/renpy/pygame_sdl2
>
> And the nightlies can be found at:
>
> http://nightly.renpy.org/pygame_sdl2/
>
> The eventual goal - in the next couple of weeks - is to get Pygame_SDL2 up
> on pypi so that it can be installed via pip on Windows.
>
> While I think Pygame_SDL2 is getting to be usable for other projects, more
> work can be done. Testing is still ad-hoc and minimal, so any help getting
> the pygame test suite working would be appreciated, as would any other
> contributions people want to supply.
>
> Ps. I was able to use the Android Runtime for Chrome to get the Android
> version of Pygame_SDL2 working inside the Chrome web browser. While it
> still needs some work in order to properly handle things like
> multiple-button mice, this paves the way for Chrome OS joining iOS and
> Android as a new platform the Pygame API runs on.
>

Re: [pygame] Pygame_SDL2 Extensions

[Michael Lutinsky]

Yes, very nice! I like how it’s a very minimal set of additions over pygame. 

And thinking about it more, I can see how keeping as much of the API the same 
will keep the goodwill and momentum for pygame going, especially with the books 
that have been written with it in mind.

~ Michael



 I've made a little bit of documentation for Pygame_SDL2 available at:
 
 http://pygame-sdl2.readthedocs.org/en/latest/
 
 Right now, it focuses on the places where Pygame_SDL2 extends the Pygame
 API. A goal of these extensions has been to be backwards-compatible - an
 application that is ignorant of the new features should be able to run
 unchanged.
 
 Comment on these extensions is welcome.

Re: [pygame] Pygame_SDL2 Extensions

[tom arnall]

Tom,

thanks very much.

Regards,

Tom Arnall

.
I suddenly realized I had joined the wrong mob. Lucky Luciano, after
spending a day on Wall Street


On 8/4/15, Tom Rothamel t...@rothamel.us wrote:
 I've made a little bit of documentation for Pygame_SDL2 available at:

 http://pygame-sdl2.readthedocs.org/en/latest/

 Right now, it focuses on the places where Pygame_SDL2 extends the Pygame
 API. A goal of these extensions has been to be backwards-compatible - an
 application that is ignorant of the new features should be able to run
 unchanged.

 Comment on these extensions is welcome.



-- 
.

[pygame] Pygame_SDL2 Extensions

[Tom Rothamel]

I've made a little bit of documentation for Pygame_SDL2 available at:

http://pygame-sdl2.readthedocs.org/en/latest/

Right now, it focuses on the places where Pygame_SDL2 extends the Pygame
API. A goal of these extensions has been to be backwards-compatible - an
application that is ignorant of the new features should be able to run
unchanged.

Comment on these extensions is welcome.

Re: [pygame] Pygame_sdl2

[shirish शिरीष]

at bottom :-

On 4/9/15, Tom Rothamel t...@rothamel.us wrote:
 On Wed, Apr 8, 2015 at 12:22 PM diliup gabadamudalige dili...@gmail.com
 wrote:

 This is too good to be true! May I ask if we can bundle the current
 Pygame
 2.7 / Pygame 1.9.2 with this?


 I'm not sure if I understand the question.

 The whole point of doing pygame_sdl2 was that trying to maintain an SDL1
 port for Android and iOS was painful and impossible (respectively), so we
 wanted to get the pygame API working on SDL2.

 That being said, your current code might be able to run if you add

 import pygame_sdl2; pygame_sdl2.import_as_pygame()

 before the first import of pygame. (You might as well try it on the desktop
 before attempting an Android or iOS port.)

 In retrospect, I'm not sure what the sound story is on Android and iOS - I
 don't think we're currently compiling the format dependencies.

Hi Tom,
Newbie and a user here. While this is a welcome development, could you
clarify few queries :-

a. AFAI seem to understand from this thread, there is going to be a
maintenance release of Pygame 1.

b. There is move to pygame 2, which will have the additional
feature-set of it being compatible with SDL2.

c. Is there going to be some sort of audio manipulation also
bundled/worked upon so people could  make sound go up, down or mute.
There is this app. called pysycache  which has audio but needs to be
manipulated by pavucontrol to move the music either way we want to. It
is not a elegant solution and needs another app. to move music up and
down. It would be better if pygame had it own audio controls

Looking foward to hearing from you.
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Re: [pygame] Pygame_sdl2

[diliup gabadamudalige]

Sorry! My question is if my code is using Python 2.7.9 / Pygame 1.9.2 will
I be able to port it to Android using your packaging or does the Pygame
code need to adjust to the new one. ( which means less options?)

On Thu, Apr 9, 2015 at 7:08 AM, shirish शिरीष shirisha...@gmail.com wrote:

 at bottom :-

 On 4/9/15, Tom Rothamel t...@rothamel.us wrote:
  On Wed, Apr 8, 2015 at 12:22 PM diliup gabadamudalige dili...@gmail.com
 
  wrote:
 
  This is too good to be true! May I ask if we can bundle the current
  Pygame
  2.7 / Pygame 1.9.2 with this?
 
 
  I'm not sure if I understand the question.
 
  The whole point of doing pygame_sdl2 was that trying to maintain an SDL1
  port for Android and iOS was painful and impossible (respectively), so we
  wanted to get the pygame API working on SDL2.
 
  That being said, your current code might be able to run if you add
 
  import pygame_sdl2; pygame_sdl2.import_as_pygame()
 
  before the first import of pygame. (You might as well try it on the
 desktop
  before attempting an Android or iOS port.)
 
  In retrospect, I'm not sure what the sound story is on Android and iOS -
 I
  don't think we're currently compiling the format dependencies.

 Hi Tom,
 Newbie and a user here. While this is a welcome development, could you
 clarify few queries :-

 a. AFAI seem to understand from this thread, there is going to be a
 maintenance release of Pygame 1.

 b. There is move to pygame 2, which will have the additional
 feature-set of it being compatible with SDL2.

 c. Is there going to be some sort of audio manipulation also
 bundled/worked upon so people could  make sound go up, down or mute.
 There is this app. called pysycache  which has audio but needs to be
 manipulated by pavucontrol to move the music either way we want to. It
 is not a elegant solution and needs another app. to move music up and
 down. It would be better if pygame had it own audio controls

 Looking foward to hearing from you.
 --
   Regards,
   Shirish Agarwal  शिरीष अग्रवाल
   My quotes in this email licensed under CC 3.0
 http://creativecommons.org/licenses/by-nc/3.0/
 http://flossexperiences.wordpress.com
 EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8




-- 
Diliup Gabadamudalige

http://www.diliupg.com
http://soft.diliupg.com/

**
This e-mail is confidential. It may also be legally privileged. If you are
not the intended recipient or have received it in error, please delete it
and all copies from your system and notify the sender immediately by return
e-mail. Any unauthorized reading, reproducing, printing or further
dissemination of this e-mail or its contents is strictly prohibited and may
be unlawful. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
**

Re: [pygame] Pygame_sdl2

[Gino Ingras]

you mentioned that it is better to use pygame_sdl2 for mobile apps.
how do you do that?

2015-04-08 5:01 GMT+02:00 Michael Lutynski 
mich...@callthecomputerdoctor.com:

  I too am very stoked to hear about the pygame1 release and the
 pygame_sdl2! This is wonderful!!



 ~ Michael



 On Tue : Apr 7, 2015 3:13:02 PM you wrote:

  pps. yes, I think it would be nice to join forces. Including testing,

  porting, doing missing modules, and re-licensing or rewriting LGPL code

  where needed. Maybe moving the repo under the pygame organisation on

  bitbucket (perhaps?).

 

  I have holidays in 3 weeks, which I've planned to try and push the
 pygame1

  release out the door. Probably the last major pygame 1 release.

 

  Trying to port existing games to pygame_sdl2 is probably a nice effort

  everyone can do to help :) I'll report back on my games later.

 

 

  best,

Re: [pygame] Pygame_sdl2

[diliup gabadamudalige]

This is too good to be true! May I ask if we can bundle the current Pygame
2.7 / Pygame 1.9.2 with this?

On Wed, Apr 8, 2015 at 7:44 PM, Tom Rothamel t...@rothamel.us wrote:

 For now, you have to use a pair of packaging tools we've written to
 package Ren'Py apps for Android and iOS. Despite the names, they're both
 intended to package arbitrary pygame_sdl2 apps. (For now, there is some
 Ren'Py branding, especially in the iOS tool, but that branding should
 probably be changed before release anyway.)

 You can get them both from http://nightly.renpy.org/current/ , as
 version-rapt.zip and version-renios.zip.

 RAPT (Ren'Py Android Packaging Tool) still works approximately as
 documented at http://pygame.renpy.org/, especially when it comes to
 building android applications. The big change is that the lifecycle events
 are now different  - see below. (Some other modules, like lifecycle
 management, are also different.)

 Renios is the iOS packaging tool. You can create a new project by running

 ./ios.py create MyProject

 That will copy the prototype directory to MyProject, and make some changes
 to the various plist files. You can then place a main.py in MyProject/base,
 and use Xcode to build the project.


 We've exposed the SDL2 application lifecycle events to pygame_sdl2 users:

 https://wiki.libsdl.org/SDL_EventType#Android_and_iOS_Events

 The mapping is pretty straightforward - SDL_APP_TERMINATING becomes
 pygame_sdl2.APP_TERMINATING. In Ren'Py, I handle these as follows:

 On APP_TERMINATING, we save the game (in a special save file) and
 immediately quit.

 On APP_WILLENTERBACKGROUND, we stop all sound, timers, and screen updates;
 save the game (in a special save file), and sit in a tight
 pygame.event.wait() loop. If that loop gets an APP_DIDENTERFOREGROUND
 event, we delete the save file, and resume screen updates and sound. If the
 loop gets an APP_TERMINATING event, we just quit.

 When Ren'Py starts, it checks for the special save file, and if found
 loads it, restoring the player's state.


 Right now, the mobile stuff is still somewhat raw. RAPT has been used to
 ship a number of Android apps, so it works well enough - but I haven't
 spent a lot of time trying it with arbitrary pygame_sdl2 games, so there
 might be some minor problems there. Renios is still quite beta. Both are
 Python 2.7-only at the moment - making the version of python configurable
 will be a challenge.




 On Wed, Apr 8, 2015 at 2:13 AM Gino Ingras ginoing...@gmail.com wrote:

 you mentioned that it is better to use pygame_sdl2 for mobile apps.
 how do you do that?

 2015-04-08 5:01 GMT+02:00 Michael Lutynski 
 mich...@callthecomputerdoctor.com:

  I too am very stoked to hear about the pygame1 release and the
 pygame_sdl2! This is wonderful!!



 ~ Michael



 On Tue : Apr 7, 2015 3:13:02 PM you wrote:

  pps. yes, I think it would be nice to join forces. Including testing,

  porting, doing missing modules, and re-licensing or rewriting LGPL code

  where needed. Maybe moving the repo under the pygame organisation on

  bitbucket (perhaps?).

 

  I have holidays in 3 weeks, which I've planned to try and push the
 pygame1

  release out the door. Probably the last major pygame 1 release.

 

  Trying to port existing games to pygame_sdl2 is probably a nice effort

  everyone can do to help :) I'll report back on my games later.

 

 

  best,





-- 
Diliup Gabadamudalige

http://www.diliupg.com
http://soft.diliupg.com/

**
This e-mail is confidential. It may also be legally privileged. If you are
not the intended recipient or have received it in error, please delete it
and all copies from your system and notify the sender immediately by return
e-mail. Any unauthorized reading, reproducing, printing or further
dissemination of this e-mail or its contents is strictly prohibited and may
be unlawful. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
**

Re: [pygame] Pygame_sdl2

[Tom Rothamel]

For now, you have to use a pair of packaging tools we've written to package
Ren'Py apps for Android and iOS. Despite the names, they're both intended
to package arbitrary pygame_sdl2 apps. (For now, there is some Ren'Py
branding, especially in the iOS tool, but that branding should probably be
changed before release anyway.)

You can get them both from http://nightly.renpy.org/current/ , as
version-rapt.zip and version-renios.zip.

RAPT (Ren'Py Android Packaging Tool) still works approximately as
documented at http://pygame.renpy.org/, especially when it comes to
building android applications. The big change is that the lifecycle events
are now different  - see below. (Some other modules, like lifecycle
management, are also different.)

Renios is the iOS packaging tool. You can create a new project by running

./ios.py create MyProject

That will copy the prototype directory to MyProject, and make some changes
to the various plist files. You can then place a main.py in MyProject/base,
and use Xcode to build the project.


We've exposed the SDL2 application lifecycle events to pygame_sdl2 users:

https://wiki.libsdl.org/SDL_EventType#Android_and_iOS_Events

The mapping is pretty straightforward - SDL_APP_TERMINATING becomes
pygame_sdl2.APP_TERMINATING. In Ren'Py, I handle these as follows:

On APP_TERMINATING, we save the game (in a special save file) and
immediately quit.

On APP_WILLENTERBACKGROUND, we stop all sound, timers, and screen updates;
save the game (in a special save file), and sit in a tight
pygame.event.wait() loop. If that loop gets an APP_DIDENTERFOREGROUND
event, we delete the save file, and resume screen updates and sound. If the
loop gets an APP_TERMINATING event, we just quit.

When Ren'Py starts, it checks for the special save file, and if found loads
it, restoring the player's state.


Right now, the mobile stuff is still somewhat raw. RAPT has been used to
ship a number of Android apps, so it works well enough - but I haven't
spent a lot of time trying it with arbitrary pygame_sdl2 games, so there
might be some minor problems there. Renios is still quite beta. Both are
Python 2.7-only at the moment - making the version of python configurable
will be a challenge.




On Wed, Apr 8, 2015 at 2:13 AM Gino Ingras ginoing...@gmail.com wrote:

 you mentioned that it is better to use pygame_sdl2 for mobile apps.
 how do you do that?

 2015-04-08 5:01 GMT+02:00 Michael Lutynski 
 mich...@callthecomputerdoctor.com:

  I too am very stoked to hear about the pygame1 release and the
 pygame_sdl2! This is wonderful!!



 ~ Michael



 On Tue : Apr 7, 2015 3:13:02 PM you wrote:

  pps. yes, I think it would be nice to join forces. Including testing,

  porting, doing missing modules, and re-licensing or rewriting LGPL code

  where needed. Maybe moving the repo under the pygame organisation on

  bitbucket (perhaps?).

 

  I have holidays in 3 weeks, which I've planned to try and push the
 pygame1

  release out the door. Probably the last major pygame 1 release.

 

  Trying to port existing games to pygame_sdl2 is probably a nice effort

  everyone can do to help :) I'll report back on my games later.

 

 

  best,

Re: [pygame] Pygame_sdl2

[Tom Rothamel]

On Wed, Apr 8, 2015 at 12:22 PM diliup gabadamudalige dili...@gmail.com
wrote:

 This is too good to be true! May I ask if we can bundle the current Pygame
 2.7 / Pygame 1.9.2 with this?


I'm not sure if I understand the question.

The whole point of doing pygame_sdl2 was that trying to maintain an SDL1
port for Android and iOS was painful and impossible (respectively), so we
wanted to get the pygame API working on SDL2.

That being said, your current code might be able to run if you add

import pygame_sdl2; pygame_sdl2.import_as_pygame()

before the first import of pygame. (You might as well try it on the desktop
before attempting an Android or iOS port.)

In retrospect, I'm not sure what the sound story is on Android and iOS - I
don't think we're currently compiling the format dependencies.

Re: [pygame] Pygame_sdl2

[René Dudfield]

Hi Tom,

is there a blog post, or web page somewhere I can link to? The announcement
is a bit too long for the website as is.

best,

ps. AWESOME



On Sat, Apr 4, 2015 at 8:42 PM, Tom Rothamel t...@rothamel.us wrote:

 I mentioned this in passing a few months ago, but I think it's time to
 formally announce Pygame_sdl2.

 Pygame_sdl2 starts with the premise that the Pygame API is important. The
 Pygame API has been used by thousands of games, libraries, and engines, and
 is being taught to beginning programmers. Preserving the Pygame API is
 important, as it means that those games, libraries, and engines will keep
 running, and those programmers' experience will not become obsolete.

 At the same time, SDL2 support is beneficial for a number of reasons. SDL
 1.2 is now obsolete, and has been for a while. New features, and ports to
 new platforms - especially the important mobile platforms - have been added
 to SDL2, and SDL2 only. For a while, I tried to add Android support by
 maintaining, as part of PGS4A, a port of SDL 1.2 to Android,
 but that proved to be very difficult as mobile platforms keep evolving.

 In October of last year, Patrick Dawson and myself began work on
 Pygame_sdl2, a reimplementation of the Pygame API using SDL2 and related
 libraries. The goal of the project is to allow games written to the Pygame
 API to run, using SDL2, on desktop and mobile platforms. We've also exposed
 some SDL2-provided functionality in a way that remains compatible with
 older code.

 At least for now, Pygame_sdl2 is available at:

 https://github.com/renpy/pygame_sdl2

 It's been used - as part of my Ren'Py engine - to release multiple games
 on Windows, Mac OS X, Linux, and Android, and I've been able to get
 Pygame_sdl2 to run on iOS, but haven't submitted to the App Store yet. This
 process, which included at least one Steam release, helped to
 shake out the more obvious problems.

 Pygame_sdl2 is written in a mix of Python, Cython, and C. Use of the
 Cython code massively simplified the project - by not having to worry about
 the details of python bindings, we were able to get the initial version of
 Pygame_sdl2 running in a short amount of time. Newly-written code is
 licensed under SDL2's Zlib license, while the code we imported from Pygame
 is licensed under the LGPL. (The LGPL's terms control distribution.)

 Pygame_sdl2 implements a large portion of pygame, but not all of it.
 Currently implemented modules are:

 * pygame_sdl2.color
 * pygame_sdl2.display
 * pygame_sdl2.draw
 * pygame_sdl2.event
 * pygame_sdl2.font
 * pygame_sdl2.gfxdraw
 * pygame_sdl2.image
 * pygame_sdl2.joystick
 * pygame_sdl2.key
 * pygame_sdl2.locals
 * pygame_sdl2.mixer (including mixer.music)
 * pygame_sdl2.mouse
 * pygame_sdl2.scrap
 * pygame_sdl2.sprite
 * pygame_sdl2.surface
 * pygame_sdl2.sysfont
 * pygame_sdl2.time
 * pygame_sdl2.transform
 * pygame_sdl2.version

 Experimental new modules include:

 * pygame_sdl2.render

 Current omissions include:

 * Modules not listed above.

 * APIs that expose pygame data as buffers or arrays.

 * Support for non-32-bit surface depths. Our thinking is that 8, 16, and
 (to some extent) 24-bit surfaces are legacy formats, and not worth
 duplicating code four or more times to support. This only applies to
 in-memory formats - when an image of lesser color depth is loaded, it is
 converted to a 32-bit image.

 * Support for palette functions, which only apply to 8-bit surfaces.

 There are a few additions to the pygame API, including support for the
 application lifecycle events on Android and iOS, IME-based text input, and
 SDL2 renderers.


 While I plan to, at the very least, maintain this indefinitely to support
 Ren'Py, my hope is that it could be useful to the larger Pygame community.
 For now, Pygame_sdl2 could probably benefit from testing, both informal
 reports of missing APIs and incorrect implementations, and someone helping
 to integrate the relevant portions of the pygame test suite.

 The modules that have not been implemented are often that
 way because we don't have much experience with them - for example, I've
 never been able to wrap my head around the thingarray modules. So help
 implementing those, or porting the Pygame implementations, would be
 appreciated.


 For now, pygame_sdl2 has been maintained as part of the Ren'Py github
 organization, but if there's enough interest in contributing and expanding
 it, it might make sense to break it out into its own project.

 Anyway, thank you for reading through this message, and for trying out
 pygame_sdl2.

Re: [pygame] Pygame_sdl2

[René Dudfield]

pps. yes, I think it would be nice to join forces. Including testing,
porting, doing missing modules, and re-licensing or rewriting LGPL code
where needed. Maybe moving the repo under the pygame organisation on
bitbucket (perhaps?).

I have holidays in 3 weeks, which I've planned to try and push the pygame1
release out the door. Probably the last major pygame 1 release.

Trying to port existing games to pygame_sdl2 is probably a nice effort
everyone can do to help :) I'll report back on my games later.


best,

Re: [pygame] Pygame_sdl2

[diliup gabadamudalige]

This conversation is the best thing I heard since I joined this group. So
PYGAME 2 is around the corner! Great work gentlemen! Great work indeed.

On Tue, Apr 7, 2015 at 6:43 PM, René Dudfield ren...@gmail.com wrote:

 pps. yes, I think it would be nice to join forces. Including testing,
 porting, doing missing modules, and re-licensing or rewriting LGPL code
 where needed. Maybe moving the repo under the pygame organisation on
 bitbucket (perhaps?).

 I have holidays in 3 weeks, which I've planned to try and push the pygame1
 release out the door. Probably the last major pygame 1 release.

 Trying to port existing games to pygame_sdl2 is probably a nice effort
 everyone can do to help :) I'll report back on my games later.


 best,




-- 
Diliup Gabadamudalige

http://www.diliupg.com
http://soft.diliupg.com/

**
This e-mail is confidential. It may also be legally privileged. If you are
not the intended recipient or have received it in error, please delete it
and all copies from your system and notify the sender immediately by return
e-mail. Any unauthorized reading, reproducing, printing or further
dissemination of this e-mail or its contents is strictly prohibited and may
be unlawful. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
**

Re: [pygame] Pygame_sdl2

[Michael Lutynski]

I too am very stoked to hear about the pygame1 release and the pygame_sdl2! 
This is wonderful!!

~ Michael 

On Tue : Apr 7, 2015 3:13:02 PM you wrote:
 pps. yes, I think it would be nice to join forces. Including testing,
 porting, doing missing modules, and re-licensing or rewriting LGPL code
 where needed. Maybe moving the repo under the pygame organisation on
 bitbucket (perhaps?).
 
 I have holidays in 3 weeks, which I've planned to try and push the pygame1
 release out the door. Probably the last major pygame 1 release.
 
 Trying to port existing games to pygame_sdl2 is probably a nice effort
 everyone can do to help :) I'll report back on my games later.
 
 
 best,

Re: [pygame] Pygame_sdl2

[Michael Lutynski]

This is great news, and thank you for sharing this. How do we get this on the 
news feed on the main pygame.org site so that there isn’t a perception that 
“nothing’s happening” with PyGame?

~ Michael 

On Sat : Apr 4, 2015 6:42:36 PM you wrote:
 I mentioned this in passing a few months ago, but I think it's time to
 formally announce Pygame_sdl2.
 
 Pygame_sdl2 starts with the premise that the Pygame API is important. The
 Pygame API has been used by thousands of games, libraries, and engines, and
 is being taught to beginning programmers. Preserving the Pygame API is
 important, as it means that those games, libraries, and engines will keep
 running, and those programmers' experience will not become obsolete.
 
 At the same time, SDL2 support is beneficial for a number of reasons. SDL
 1.2 is now obsolete, and has been for a while. New features, and ports to
 new platforms - especially the important mobile platforms - have been added
 to SDL2, and SDL2 only. For a while, I tried to add Android support by
 maintaining, as part of PGS4A, a port of SDL 1.2 to Android,
 but that proved to be very difficult as mobile platforms keep evolving.
 
 In October of last year, Patrick Dawson and myself began work on
 Pygame_sdl2, a reimplementation of the Pygame API using SDL2 and related
 libraries. The goal of the project is to allow games written to the Pygame
 API to run, using SDL2, on desktop and mobile platforms. We've also exposed
 some SDL2-provided functionality in a way that remains compatible with
 older code.
 
 At least for now, Pygame_sdl2 is available at:
 
 https://github.com/renpy/pygame_sdl2
 
 It's been used - as part of my Ren'Py engine - to release multiple games on
 Windows, Mac OS X, Linux, and Android, and I've been able to get
 Pygame_sdl2 to run on iOS, but haven't submitted to the App Store yet. This
 process, which included at least one Steam release, helped to
 shake out the more obvious problems.
 
 Pygame_sdl2 is written in a mix of Python, Cython, and C. Use of the Cython
 code massively simplified the project - by not having to worry about the
 details of python bindings, we were able to get the initial version of
 Pygame_sdl2 running in a short amount of time. Newly-written code is
 licensed under SDL2's Zlib license, while the code we imported from Pygame
 is licensed under the LGPL. (The LGPL's terms control distribution.)
 
 Pygame_sdl2 implements a large portion of pygame, but not all of it.
 Currently implemented modules are:
 
 * pygame_sdl2.color
 * pygame_sdl2.display
 * pygame_sdl2.draw
 * pygame_sdl2.event
 * pygame_sdl2.font
 * pygame_sdl2.gfxdraw
 * pygame_sdl2.image
 * pygame_sdl2.joystick
 * pygame_sdl2.key
 * pygame_sdl2.locals
 * pygame_sdl2.mixer (including mixer.music)
 * pygame_sdl2.mouse
 * pygame_sdl2.scrap
 * pygame_sdl2.sprite
 * pygame_sdl2.surface
 * pygame_sdl2.sysfont
 * pygame_sdl2.time
 * pygame_sdl2.transform
 * pygame_sdl2.version
 
 Experimental new modules include:
 
 * pygame_sdl2.render
 
 Current omissions include:
 
 * Modules not listed above.
 
 * APIs that expose pygame data as buffers or arrays.
 
 * Support for non-32-bit surface depths. Our thinking is that 8, 16, and
 (to some extent) 24-bit surfaces are legacy formats, and not worth
 duplicating code four or more times to support. This only applies to
 in-memory formats - when an image of lesser color depth is loaded, it is
 converted to a 32-bit image.
 
 * Support for palette functions, which only apply to 8-bit surfaces.
 
 There are a few additions to the pygame API, including support for the
 application lifecycle events on Android and iOS, IME-based text input, and
 SDL2 renderers.
 
 
 While I plan to, at the very least, maintain this indefinitely to support
 Ren'Py, my hope is that it could be useful to the larger Pygame community.
 For now, Pygame_sdl2 could probably benefit from testing, both informal
 reports of missing APIs and incorrect implementations, and someone helping
 to integrate the relevant portions of the pygame test suite.
 
 The modules that have not been implemented are often that
 way because we don't have much experience with them - for example, I've
 never been able to wrap my head around the thingarray modules. So help
 implementing those, or porting the Pygame implementations, would be
 appreciated.
 
 
 For now, pygame_sdl2 has been maintained as part of the Ren'Py github
 organization, but if there's enough interest in contributing and expanding
 it, it might make sense to break it out into its own project.
 
 Anyway, thank you for reading through this message, and for trying out
 pygame_sdl2.

Re: [pygame] Pygame_sdl2

[adam . hasvers]

I think I can speak for anyone making medium-to-big games with pygame when I 
say: thanks a LOT, Tom! Your work and support on Ren'Py is exemplary, and it's 
awesome to let other pygame users benefit from it.

Finally I might be able to stop passing buffers back and forth between three 
libraries to run shaders on pygame surfaces and stuff like that.
I will definitely start testing this soon and report what i can. I wish I were 
good enough at bindings and arcane stuff to help with the XXXarray libraries, 
as they can be pretty convenient.

Cheers,
Adam

- Mail original -
De: Tom Rothamel t...@rothamel.us
À: pygame-users pygame-users@seul.org
Envoyé: Samedi 4 Avril 2015 14:42:36
Objet: [pygame] Pygame_sdl2



I mentioned this in passing a few months ago, but I think it's time to formally 
announce Pygame_sdl2. 


Pygame_sdl2 starts with the premise that the Pygame API is important. The 
Pygame API has been used by thousands of games, libraries, and engines, and is 
being taught to beginning programmers. Preserving the Pygame API is important, 
as it means that those games, libraries, and engines will keep running, and 
those programmers' experience will not become obsolete. 


At the same time, SDL2 support is beneficial for a number of reasons. SDL 1.2 
is now obsolete, and has been for a while. New features, and ports to new 
platforms - especially the important mobile platforms - have been added to 
SDL2, and SDL2 only. For a while, I tried to add Android support by 
maintaining, as part of PGS4A, a port of SDL 1.2 to Android, 
but that proved to be very difficult as mobile platforms keep evolving. 


In October of last year, Patrick Dawson and myself began work on Pygame_sdl2, a 
reimplementation of the Pygame API using SDL2 and related libraries. The goal 
of the project is to allow games written to the Pygame API to run, using SDL2, 
on desktop and mobile platforms. We've also exposed some SDL2-provided 
functionality in a way that remains compatible with older code. 


At least for now, Pygame_sdl2 is available at: 


https://github.com/renpy/pygame_sdl2 


It's been used - as part of my Ren'Py engine - to release multiple games on 
Windows, Mac OS X, Linux, and Android, and I've been able to get Pygame_sdl2 to 
run on iOS, but haven't submitted to the App Store yet. This process, which 
included at least one Steam release, helped to 
shake out the more obvious problems. 


Pygame_sdl2 is written in a mix of Python, Cython, and C. Use of the Cython 
code massively simplified the project - by not having to worry about the 
details of python bindings, we were able to get the initial version of 
Pygame_sdl2 running in a short amount of time. Newly-written code is licensed 
under SDL2's Zlib license, while the code we imported from Pygame is licensed 
under the LGPL. (The LGPL's terms control distribution.) 


Pygame_sdl2 implements a large portion of pygame, but not all of it. Currently 
implemented modules are: 


* pygame_sdl2.color 
* pygame_sdl2.display 
* pygame_sdl2.draw 
* pygame_sdl2.event 
* pygame_sdl2.font 
* pygame_sdl2.gfxdraw 
* pygame_sdl2.image 
* pygame_sdl2.joystick 
* pygame_sdl2.key 
* pygame_sdl2.locals 
* pygame_sdl2.mixer (including mixer.music) 
* pygame_sdl2.mouse 
* pygame_sdl2.scrap 
* pygame_sdl2.sprite 
* pygame_sdl2.surface 
* pygame_sdl2.sysfont 
* pygame_sdl2.time 
* pygame_sdl2.transform 
* pygame_sdl2.version 


Experimental new modules include: 


* pygame_sdl2.render 


Current omissions include: 


* Modules not listed above. 


* APIs that expose pygame data as buffers or arrays. 


* Support for non-32-bit surface depths. Our thinking is that 8, 16, and (to 
some extent) 24-bit surfaces are legacy formats, and not worth duplicating code 
four or more times to support. This only applies to in-memory formats - when an 
image of lesser color depth is loaded, it is converted to a 32-bit image. 


* Support for palette functions, which only apply to 8-bit surfaces. 


There are a few additions to the pygame API, including support for the 
application lifecycle events on Android and iOS, IME-based text input, and SDL2 
renderers. 




While I plan to, at the very least, maintain this indefinitely to support 
Ren'Py, my hope is that it could be useful to the larger Pygame community. For 
now, Pygame_sdl2 could probably benefit from testing, both informal reports of 
missing APIs and incorrect implementations, and someone helping to integrate 
the relevant portions of the pygame test suite. 


The modules that have not been implemented are often that 
way because we don't have much experience with them - for example, I've never 
been able to wrap my head around the thingarray modules. So help implementing 
those, or porting the Pygame implementations, would be appreciated. 




For now, pygame_sdl2 has been maintained as part of the Ren'Py github 
organization, but if there's enough interest in contributing and expanding it, 
it might make sense to break it out

Re: [pygame] Pygame_sdl2

[Rob Hagemans]

Hi Tom, thanks for sharing this, and it's great that you're blowing new life 
and SDL2 into PyGame! I see great advantages to moving to SDL2 and would love 
to test it in my project (pcbasic.sourceforge.net) - somewhat unfortunately, it 
makes critical use of palettes and 8-bit surfaces, as I'm emulating precisely 
the sort of old-fashioned hardware for which they were designed. 
So here's a vote of interest in those features, though I understand your 
reasoning for not having included them. 
Rob


 On Monday, 6 April 2015, 8:17, adam.hasv...@free.fr 
adam.hasv...@free.fr wrote:
   

 I think I can speak for anyone making medium-to-big games with pygame when I 
say: thanks a LOT, Tom! Your work and support on Ren'Py is exemplary, and it's 
awesome to let other pygame users benefit from it.

Finally I might be able to stop passing buffers back and forth between three 
libraries to run shaders on pygame surfaces and stuff like that.
I will definitely start testing this soon and report what i can. I wish I were 
good enough at bindings and arcane stuff to help with the XXXarray libraries, 
as they can be pretty convenient.

Cheers,
Adam

- Mail original -
De: Tom Rothamel t...@rothamel.us
À: pygame-users pygame-users@seul.org
Envoyé: Samedi 4 Avril 2015 14:42:36
Objet: [pygame] Pygame_sdl2



I mentioned this in passing a few months ago, but I think it's time to formally 
announce Pygame_sdl2. 


Pygame_sdl2 starts with the premise that the Pygame API is important. The 
Pygame API has been used by thousands of games, libraries, and engines, and is 
being taught to beginning programmers. Preserving the Pygame API is important, 
as it means that those games, libraries, and engines will keep running, and 
those programmers' experience will not become obsolete. 


At the same time, SDL2 support is beneficial for a number of reasons. SDL 1.2 
is now obsolete, and has been for a while. New features, and ports to new 
platforms - especially the important mobile platforms - have been added to 
SDL2, and SDL2 only. For a while, I tried to add Android support by 
maintaining, as part of PGS4A, a port of SDL 1.2 to Android, 
but that proved to be very difficult as mobile platforms keep evolving. 


In October of last year, Patrick Dawson and myself began work on Pygame_sdl2, a 
reimplementation of the Pygame API using SDL2 and related libraries. The goal 
of the project is to allow games written to the Pygame API to run, using SDL2, 
on desktop and mobile platforms. We've also exposed some SDL2-provided 
functionality in a way that remains compatible with older code. 


At least for now, Pygame_sdl2 is available at: 


https://github.com/renpy/pygame_sdl2 


It's been used - as part of my Ren'Py engine - to release multiple games on 
Windows, Mac OS X, Linux, and Android, and I've been able to get Pygame_sdl2 to 
run on iOS, but haven't submitted to the App Store yet. This process, which 
included at least one Steam release, helped to 
shake out the more obvious problems. 


Pygame_sdl2 is written in a mix of Python, Cython, and C. Use of the Cython 
code massively simplified the project - by not having to worry about the 
details of python bindings, we were able to get the initial version of 
Pygame_sdl2 running in a short amount of time. Newly-written code is licensed 
under SDL2's Zlib license, while the code we imported from Pygame is licensed 
under the LGPL. (The LGPL's terms control distribution.) 


Pygame_sdl2 implements a large portion of pygame, but not all of it. Currently 
implemented modules are: 


* pygame_sdl2.color 
* pygame_sdl2.display 
* pygame_sdl2.draw 
* pygame_sdl2.event 
* pygame_sdl2.font 
* pygame_sdl2.gfxdraw 
* pygame_sdl2.image 
* pygame_sdl2.joystick 
* pygame_sdl2.key 
* pygame_sdl2.locals 
* pygame_sdl2.mixer (including mixer.music) 
* pygame_sdl2.mouse 
* pygame_sdl2.scrap 
* pygame_sdl2.sprite 
* pygame_sdl2.surface 
* pygame_sdl2.sysfont 
* pygame_sdl2.time 
* pygame_sdl2.transform 
* pygame_sdl2.version 


Experimental new modules include: 


* pygame_sdl2.render 


Current omissions include: 


* Modules not listed above. 


* APIs that expose pygame data as buffers or arrays. 


* Support for non-32-bit surface depths. Our thinking is that 8, 16, and (to 
some extent) 24-bit surfaces are legacy formats, and not worth duplicating code 
four or more times to support. This only applies to in-memory formats - when an 
image of lesser color depth is loaded, it is converted to a 32-bit image. 


* Support for palette functions, which only apply to 8-bit surfaces. 


There are a few additions to the pygame API, including support for the 
application lifecycle events on Android and iOS, IME-based text input, and SDL2 
renderers. 




While I plan to, at the very least, maintain this indefinitely to support 
Ren'Py, my hope is that it could be useful to the larger Pygame community. For 
now, Pygame_sdl2 could probably benefit from testing, both informal reports of 
missing

Re: [pygame] Pygame_sdl2

[Patrick Mullen]

I'm looking forward to trying this out. I used your PGS4A for my pywright
engine which was pretty helpful. I've recently ported my current game to
pysfml because pygame seems like a sinking ship. I made it abstractly
compatible so I can toggle the library pretty easily, so I'll see if I can
get a build running on this to try it out. SFML is pretty good, but I've
had platform related issues. Most other attempts to make a better pygame
change the api too much - which kind of makes sense for a new project, but
having one actually be compatible would be great.

On Sat, Apr 4, 2015 at 11:42 AM, Tom Rothamel t...@rothamel.us wrote:

 I mentioned this in passing a few months ago, but I think it's time to
 formally announce Pygame_sdl2.

 Pygame_sdl2 starts with the premise that the Pygame API is important. The
 Pygame API has been used by thousands of games, libraries, and engines, and
 is being taught to beginning programmers. Preserving the Pygame API is
 important, as it means that those games, libraries, and engines will keep
 running, and those programmers' experience will not become obsolete.

 At the same time, SDL2 support is beneficial for a number of reasons. SDL
 1.2 is now obsolete, and has been for a while. New features, and ports to
 new platforms - especially the important mobile platforms - have been added
 to SDL2, and SDL2 only. For a while, I tried to add Android support by
 maintaining, as part of PGS4A, a port of SDL 1.2 to Android,
 but that proved to be very difficult as mobile platforms keep evolving.

 In October of last year, Patrick Dawson and myself began work on
 Pygame_sdl2, a reimplementation of the Pygame API using SDL2 and related
 libraries. The goal of the project is to allow games written to the Pygame
 API to run, using SDL2, on desktop and mobile platforms. We've also exposed
 some SDL2-provided functionality in a way that remains compatible with
 older code.

 At least for now, Pygame_sdl2 is available at:

 https://github.com/renpy/pygame_sdl2

 It's been used - as part of my Ren'Py engine - to release multiple games
 on Windows, Mac OS X, Linux, and Android, and I've been able to get
 Pygame_sdl2 to run on iOS, but haven't submitted to the App Store yet. This
 process, which included at least one Steam release, helped to
 shake out the more obvious problems.

 Pygame_sdl2 is written in a mix of Python, Cython, and C. Use of the
 Cython code massively simplified the project - by not having to worry about
 the details of python bindings, we were able to get the initial version of
 Pygame_sdl2 running in a short amount of time. Newly-written code is
 licensed under SDL2's Zlib license, while the code we imported from Pygame
 is licensed under the LGPL. (The LGPL's terms control distribution.)

 Pygame_sdl2 implements a large portion of pygame, but not all of it.
 Currently implemented modules are:

 * pygame_sdl2.color
 * pygame_sdl2.display
 * pygame_sdl2.draw
 * pygame_sdl2.event
 * pygame_sdl2.font
 * pygame_sdl2.gfxdraw
 * pygame_sdl2.image
 * pygame_sdl2.joystick
 * pygame_sdl2.key
 * pygame_sdl2.locals
 * pygame_sdl2.mixer (including mixer.music)
 * pygame_sdl2.mouse
 * pygame_sdl2.scrap
 * pygame_sdl2.sprite
 * pygame_sdl2.surface
 * pygame_sdl2.sysfont
 * pygame_sdl2.time
 * pygame_sdl2.transform
 * pygame_sdl2.version

 Experimental new modules include:

 * pygame_sdl2.render

 Current omissions include:

 * Modules not listed above.

 * APIs that expose pygame data as buffers or arrays.

 * Support for non-32-bit surface depths. Our thinking is that 8, 16, and
 (to some extent) 24-bit surfaces are legacy formats, and not worth
 duplicating code four or more times to support. This only applies to
 in-memory formats - when an image of lesser color depth is loaded, it is
 converted to a 32-bit image.

 * Support for palette functions, which only apply to 8-bit surfaces.

 There are a few additions to the pygame API, including support for the
 application lifecycle events on Android and iOS, IME-based text input, and
 SDL2 renderers.


 While I plan to, at the very least, maintain this indefinitely to support
 Ren'Py, my hope is that it could be useful to the larger Pygame community.
 For now, Pygame_sdl2 could probably benefit from testing, both informal
 reports of missing APIs and incorrect implementations, and someone helping
 to integrate the relevant portions of the pygame test suite.

 The modules that have not been implemented are often that
 way because we don't have much experience with them - for example, I've
 never been able to wrap my head around the thingarray modules. So help
 implementing those, or porting the Pygame implementations, would be
 appreciated.


 For now, pygame_sdl2 has been maintained as part of the Ren'Py github
 organization, but if there's enough interest in contributing and expanding
 it, it might make sense to break it out into its own project.

 Anyway, thank you for reading through this message, and for trying out
 pygame_sdl2.

[pygame] Pygame_sdl2

[Tom Rothamel]

I mentioned this in passing a few months ago, but I think it's time to
formally announce Pygame_sdl2.

Pygame_sdl2 starts with the premise that the Pygame API is important. The
Pygame API has been used by thousands of games, libraries, and engines, and
is being taught to beginning programmers. Preserving the Pygame API is
important, as it means that those games, libraries, and engines will keep
running, and those programmers' experience will not become obsolete.

At the same time, SDL2 support is beneficial for a number of reasons. SDL
1.2 is now obsolete, and has been for a while. New features, and ports to
new platforms - especially the important mobile platforms - have been added
to SDL2, and SDL2 only. For a while, I tried to add Android support by
maintaining, as part of PGS4A, a port of SDL 1.2 to Android,
but that proved to be very difficult as mobile platforms keep evolving.

In October of last year, Patrick Dawson and myself began work on
Pygame_sdl2, a reimplementation of the Pygame API using SDL2 and related
libraries. The goal of the project is to allow games written to the Pygame
API to run, using SDL2, on desktop and mobile platforms. We've also exposed
some SDL2-provided functionality in a way that remains compatible with
older code.

At least for now, Pygame_sdl2 is available at:

https://github.com/renpy/pygame_sdl2

It's been used - as part of my Ren'Py engine - to release multiple games on
Windows, Mac OS X, Linux, and Android, and I've been able to get
Pygame_sdl2 to run on iOS, but haven't submitted to the App Store yet. This
process, which included at least one Steam release, helped to
shake out the more obvious problems.

Pygame_sdl2 is written in a mix of Python, Cython, and C. Use of the Cython
code massively simplified the project - by not having to worry about the
details of python bindings, we were able to get the initial version of
Pygame_sdl2 running in a short amount of time. Newly-written code is
licensed under SDL2's Zlib license, while the code we imported from Pygame
is licensed under the LGPL. (The LGPL's terms control distribution.)

Pygame_sdl2 implements a large portion of pygame, but not all of it.
Currently implemented modules are:

* pygame_sdl2.color
* pygame_sdl2.display
* pygame_sdl2.draw
* pygame_sdl2.event
* pygame_sdl2.font
* pygame_sdl2.gfxdraw
* pygame_sdl2.image
* pygame_sdl2.joystick
* pygame_sdl2.key
* pygame_sdl2.locals
* pygame_sdl2.mixer (including mixer.music)
* pygame_sdl2.mouse
* pygame_sdl2.scrap
* pygame_sdl2.sprite
* pygame_sdl2.surface
* pygame_sdl2.sysfont
* pygame_sdl2.time
* pygame_sdl2.transform
* pygame_sdl2.version

Experimental new modules include:

* pygame_sdl2.render

Current omissions include:

* Modules not listed above.

* APIs that expose pygame data as buffers or arrays.

* Support for non-32-bit surface depths. Our thinking is that 8, 16, and
(to some extent) 24-bit surfaces are legacy formats, and not worth
duplicating code four or more times to support. This only applies to
in-memory formats - when an image of lesser color depth is loaded, it is
converted to a 32-bit image.

* Support for palette functions, which only apply to 8-bit surfaces.

There are a few additions to the pygame API, including support for the
application lifecycle events on Android and iOS, IME-based text input, and
SDL2 renderers.


While I plan to, at the very least, maintain this indefinitely to support
Ren'Py, my hope is that it could be useful to the larger Pygame community.
For now, Pygame_sdl2 could probably benefit from testing, both informal
reports of missing APIs and incorrect implementations, and someone helping
to integrate the relevant portions of the pygame test suite.

The modules that have not been implemented are often that
way because we don't have much experience with them - for example, I've
never been able to wrap my head around the thingarray modules. So help
implementing those, or porting the Pygame implementations, would be
appreciated.


For now, pygame_sdl2 has been maintained as part of the Ren'Py github
organization, but if there's enough interest in contributing and expanding
it, it might make sense to break it out into its own project.

Anyway, thank you for reading through this message, and for trying out
pygame_sdl2.