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 <sanjur...@gmail.com> 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 <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 >>>> >>>> >>>
