Yeah, with the python community moved to github, it's really past time to move. I recently gathered some stats from pypi and found almost a 10 to 1 ratio of python packages on github.
Dirty updates, and better blitters are definitely options. There's even code already written to do multi core blits with openmp, and faster blitters. The cpus on pi3 can sometimes outperform the video core for some things I've tried (eg, image classification tasks). Also, there is SDL_gpu(which works with sdl1 too), which some people are having good luck with, and an SDL2 based pygame. Finally there's imgblit from Lenard... which is a jit blitter he's been working on (but I haven't tried yet). My hope is to gather a few python game related projects under the pygame organization so it's easier to contribute. So we can pool resources. They can be separate projects, but share some infrastructure. See this thread for discussion on a pygame with SDL2. https://bitbucket.org/pygame/p ygame/issues/174/pygame-20-the-sdl2-edition <https://bitbucket.org/pygame/pygame/issues/174/pygame-20-the-sdl2-edition#comment-32989585> There's a few options to go ahead with a pygame on SDL2. Either through patches Lenard Lindstrom has made, or with pygame_sdl2 from Tom and co (which is already on github), or even based on PySDL2 from Marcus. So far I think people are leaning towards pygame_sdl2, but I'm waiting to hear back from Lenard. No matter which way we go, there's options which you could use today for better performance on pi. I'm also personally doing projects with raspberry pi, and want to make performance and packaging better there. If you wanted to change from pygame later however, I don't see a problem doing that if it's in the pygame organisation. Either way, I think it would give pygame zero more visibility, and more potential contributions on gh. cheers, On Thu, Mar 16, 2017 at 9:43 AM, Daniel Pope <ma...@mauveweb.co.uk> wrote: > My interest in moving to Github is to help solicit contributions etc. > Bitbucket was never good at this and my impression is that it has become > worse. > > The main concern I have with formally moving it into the Pygame project is > Pygame Zero may need to separate from Pygame at some point. I've known > since the beginning that Pygame Zero doesn't have a great performance > story. To make it easy to learn - this is the rationale behind everything > we did - pgzero uses a simple "render everything every frame" approach. > This works fine for simple games on desktop, but it's not good on Raspberry > Pis, for example. There are plenty of clever tricks that one could try to > use to improve this, but the ultimate one is to get more into Pi-compatible > GPU rendering, and thus move away from Pygame and of course change the name > slightly (maybe Pi Game Zero or just PGZero). > > On the other hand, if more native code would help, then Pygame would be an > excellent place to put that code for mutual benefit. For example, the Pi 3 > is quad-core: I thought about maybe queuing all blits into a separate, > native thread from the Python. Perhaps this would use some sort of > reference-counted copy-on-write system to ensure surfaces aren't updated > while queued for blitting. Pygame is a better place to build this kind of > thing than Pygame Zero (which is pure Python). > > On the other hand perhaps there are way more important things to worry > about in Pygame Zero than performance. > > On Wed, 15 Mar 2017 at 10:06 René Dudfield <ren...@gmail.com> wrote: > >> Hello, >> >> What is Pygame Zero? >> """Pygame Zero is for creating games without boilerplate. >> >> It is intended for use in education, so that teachers can teach basic >> programming without needing to explain the Pygame API or write an event >> loop.""" >> http://pygame-zero.readthedocs.io/en/latest/ >> https://bitbucket.org/lordmauve/pgzero >> >> Was just chatting on twitter with @lordmauve about bringing pygamezero >> into the pygame organization on github. >> >> So far we have the website, pygame mirror, and solarwolf (which is acting >> as an example game). >> https://github.com/pygame >> >> So this is a thread where we can begin to discuss, and coordinate moving >> it there. >> >> Some steps... >> >> 1. Add team members to pygame gh org. >> 2. Create pygamezero team on pygame gh org >> 3. Convert hg to git, and create repo. Move issues across. (there's a >> tool in github to do this almost automagically once all team members are on >> gh) >> 4. update various build tools. >> 5. update docs to point to gh >> 6. Leave notes on bitbucket about moving, leaving a link there. >> >> >> >> cheers, >> >
