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 <ren...@gmail.com wrote: > Hello, > > Some updates on where we're up to... > > > https://www.pygame.org/news/2018/11/where-we-are-up-to-with-pygame-2-and-1-9-5 > > > - 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 <https://github.com/alphaCTzo7G>) | Amos Bastian ( > @amosbastian <https://github.com/amosbastian>) | Andrey Lopukhov ( > @andreyx86 <https://github.com/andreyx86>) | Augusto Noronha (@augusto2112 > <https://github.com/augusto2112>) | (@Bottersnike > <https://github.com/Bottersnike>) | (@Cerealdragon > <https://github.com/Cerealdragon>) | (@cmtrapp02 > <https://github.com/cmtrapp02>) | Daniel Molina (@daniel-molina > <https://github.com/daniel-molina>) | David Caughell (@DavidCaughell > <https://github.com/DavidCaughell>) | David L (@dlon > <https://github.com/dlon>) | burmer (@dtschirmer > <https://github.com/dtschirmer>) | René Dudfield (@illume > <https://github.com/illume>) | (@LambdaGoblin > <https://github.com/LambdaGoblin>) | Lenard Lindstrom (@llindstrom > <https://github.com/llindstrom>) | Marius Gedminas (@mgedmin > <https://github.com/mgedmin>) | (@metulburr <https://github.com/metulburr>) > | Dominik George (@Natureshadow <https://github.com/Natureshadow>) | > Nunu-Willump (@Nunu-Willump <https://github.com/Nunu-Willump>) | Nik ( > @nikolas <https://github.com/nikolas>) | Sett (@sw00 > <https://github.com/sw00>) | > > > On Wed, Aug 15, 2018 at 7:00 PM Leif Theden <leif.the...@gmail.com> 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 <ren...@gmail.com> 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 <https://github.com/grimfang4/sdl-gpu/pull/45>]. 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 >>> <https://github.com/grimfang4/sdl-gpu#conversion>]. >>> >>> 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 >>> * [1] https://github.com/grimfang4/sdl-gpu/pull/45 >>> * [2] https://github.com/grimfang4/sdl-gpu#conversion >>> >>> >>
