[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Starting the pygame 2 series



Hi,

I strongly feel that starting with tests is a good idea, and also for "good first issue" issues.
Most projects mark issues which should be fairly easy to get started on.
Definitely choose a project based on your interests, and one where people are willing to help out.

Here's a "good first issue" for you if you want it: https://github.com/pygame/pygame/issues/565
Just say on there something like "I'm working on this".

Also see: https://www.pygame.org/wiki/Contribute
Feel free to drop in the #contributing room where you can get help.



On Mon, Nov 5, 2018 at 11:08 AM Thomas Sanjurjo <sanjurjo7@xxxxxxxxx> wrote:
If I'm getting my feet wet with programming seriously, where should I best focus my efforts? I can do documentation and explain what code does decently well, but I'd also like to actually conteibute some code to the project.

Thanks for pointing me in the right direction .

On Mon, Nov 5, 2018, 5:04 AM René Dudfield <renesd@xxxxxxxxx wrote:
Hello,

Some updates on where we're up to...


  • pygame now compiles with SDL2 from source on at least Mac, Linux, and Windows.
  • SDL2 now does batching with the existing API. Should be in the next release. So no need to integrate SDL_gpu, or to change how we submit surfaces for rendering.
  • Many things are working with SDL2, there are dozens of known issues and test failures however. The main one is color keyed surfaces not working properly. The other big piece of work is getting it to compile on the build bots (travis, appveyor), and making pre releases available.
  • There have been a few more developers contributing (10 in the last month).
  • Work continues on cleanups, making it more developer friendly, and developer out reach. The repo has been cleaned up, removing the clutter, and beginning an internal CAPI refactor. Unit tests have also undergone some cleanups using newer features. python 2.4/2.5/2.6 support has been removed in the code. The contribution guide has been improved. https://www.pygame.org/wiki/Contribute
  • If anyone using pygame in Berlin wants to come along and help talk with people interested in contributing, I am presenting here: https://www.meetup.com/opensourcediversity/events/255369540/
  • We're working toward the 1.9.5 release (the refactor release).
  • There could be 'one more SDL 1.2' release, and we may use that SDL1.2 branch for a 1.9.6 release.

Here's the milestone for pygame 2: https://github.com/pygame/pygame/milestone/4
When is pygame 2 done? TLDR; When the pygame API is mostly running in a backwards compatible way on SDL2. When the few parts that are not working are documented as such. When there are binaries available for python 2.7, 3.4, 3.5, 3.6, 3.7 in 32bit/64bit varieties on at least Mac, Linux, Windows.

Here's the milestone for pygame 1.9.5 (the refactor release). https://github.com/pygame/pygame/milestone/7
The 1.9.5 release is the 'refactor' release, with the SDL2 branch merged and many cleanups. Being able to compile SDL2 support in is possible from source, but there are known issues with it. Binaries (on pypi and otherwise) should be distributed with SDL 1.2.

Thanks to the following people who have been helping out since the last release (sorry if I've missed anyone).

(@alphaCTzo7G) | Amos Bastian (@amosbastian) | Andrey Lopukhov (@andreyx86) | Augusto Noronha (@augusto2112) | (@Bottersnike) | (@Cerealdragon) | (@cmtrapp02) | Daniel Molina (@daniel-molina) | David Caughell (@DavidCaughell) | David L (@dlon) | burmer (@dtschirmer) | René Dudfield (@illume) | (@LambdaGoblin) | Lenard Lindstrom (@llindstrom) | Marius Gedminas (@mgedmin) | (@metulburr) | Dominik George (@Natureshadow) | Nunu-Willump (@Nunu-Willump) | Nik (@nikolas) | Sett (@sw00) |



On Wed, Aug 15, 2018 at 7:00 PM Leif Theden <leif.theden@xxxxxxxxx> wrote:
Is this unrelated to the "Renderer" API?  Just IMO, i'd rather use the Renderer API than trying to work with obsolete opengl and have cross-platform issues.  Not worth getting working if it really has all these issues.

On Mon, Aug 13, 2018 at 1:15 PM, René Dudfield <renesd@xxxxxxxxx> wrote:
Yes! For sure. I think we should seriously consider it.

TLDR; there are a few concerns, but it could be the best way forward.

What do you(ses) think? Anyone want to try it out?



I think we definitely could use something for what sdl-gpu does well. Which is mainly automatic batch rendering to reduce state changes, but also a rotation/scale API along with a nicer way to use shaders.
  • the author and other people have used it in various games, and it's a number of years old now.
  • People have used it on iOS and Android. Which both currently support OpenGL, and these are where you need performance most.
  • It's not in Debian, homebrew, Fedora or... (which is the same as 'is it stable/mature and packaged well?').
  • The releases haven't been 'proper' and versioned yet. There's no .tar.gz with the version in its name for example.
  • it uses CMake (ya! for modern packaging).
  • It's marked as version 0.11.0 (ie. not stable or finished).
  • Currently it only supports OpenGL*[0] (which is still worthwhile).
  • there is a windows/appveyor CI, but it's been broken for five months.
  • it's mainly one author, but quite a few minor contributions.
  • there's lots of interactive tests, but no automated tests.
  • I'm slightly concerned it's too closely coupled to OpenGL, and some of this may leak through.

The best thing about sdl-gpu is that it doesn't require you to batch up your drawing calls first. So people using the API in a naive way can also see performance improvements. However, (c)python has the high python function call overhead, so in some ways we still have to avoid non-batch rendering anyway.

Some of these cons about packaging, and 'proper releases' could perhaps be contributed. However maybe the author doesn't want this(or yet), rather than doesn't know how or hasn't had time. There is a pkg-config script PR been open for two years without comment, so I'm a bit afraid the author doesn't care*[1]. To be fair, that Pr is incomplete, so maybe the author just doesn't want to do this work, or wants to wait a bit longer before things stabalise... who knows? Or just wants to support CMake only. Perhaps asking the main author questions about it would be a good idea :)

I'd feel more confident knowing someone I trusted who had used it, or someone experimenting with it more and reporting back any potential problems we'd have.


Note, however that there are several 'draw 2D things faster on OpenGL' even done in python which are 'pretty good'. Including one I wrote (but that mainly worked at the sprite level). Other groups (renpy, kivy) seem to decide on 'hey lets roll our own!' where SDL is lacking. I think it's better to contribute to a shared solution with the rest of the SDL community.

But perhaps it's worth us considering using or helping out one of the dozen python options? For example, some people already use some of the pyglet OpenGL drawing code on pygame.


The SDL2 option is to try and help get a batched API into SDL2 itself. Then other backends would also be optimized that aren't using OpenGL.
Remember that OpenGL is theoretically deprecated now. Things like Vulkan, Metal, Direct3d, and such.
And there has been some work on that, and discussion on that for some time. But not much movement there.

Note: sdl-gpu could(theoretically) be used from inside a SDL1 pygame :)


If someone has some time, I feel like patching in the 10-30 required alternative function calls and just giving it a go could be a great first step.
Which would be a search replace job with SDL_RenderCopy() into GPU_Blit(). Full list on the github page *[2].

Then we can better figure out the pros and cons... to determine if it's worth us using.
To get around the problems with it not being packaged for Debian/Ubuntu/Etc... we could just make it an optional compilation for now.
Then compile it ourselves in our binary wheels for these platforms, plus contribute towards packaging on Debian/Homebrew.

Maybe it's even possible for us to compile it in, and have some sort of setting to enable/disable it. Not sure if that's possible, but that would be best.



Open questions for me:
  • Is there someone I know who can try it out, and report back?
  • Will this be stable in the future and packaged well? Is this even an aim?
  • Will other backends be supported other than OpenGL ones?
  • Can we include it without tightly coupling ourselves to OpenGL? Will OpenGL leak out?
  • Can we compile it in optionally, so that people can opt in?
  • What other options are there for nice 2d OpenGL renderers? (pyglet, renpy, ...)
  • Can we get a confirmation from Sam/Ryan on if batch SDL2 rendering would be accepted?
  • Who will actually do this work? Does this work have to be done before a pygame 2, or can it come later?



* [0] OpenGL 1.1, 2.0, 3.0, 4.0 OpenGL ES 1.1, 2.0, 3.0