Greetings pygame-users, I'm a second year undergraduate student at the Faculty of Electrotechnical Engineering in Croatia, Osijek. I was a participant in the last year's GSOC under the PSF (working on the tinypy project, more specifically) and would like to reapply again this year. My project last year was sandboxing the tinypy interpreter (I suspect there are some tinypy mailing list users here that may know me).
I've looked through the ideas page for pygame and found the one about porting pygame to tinypy very interesting. As it is, tinypy is already an interesting platform with much potential and a great deal of it is still to be unlocked. Porting pygame would be one major step in that direction. Combining such a great game library with such a neatly packed interpreter is definitely a winning combination, particularly when you think of all the CPython's baggage you needn't carry anymore :-) The benefits of such a project are rather obvious; pygame would support another cool platform and expand its userbase/usefulness, tinypy would become a much more interesting game development platform and it would be of interest to the entire game development community. The "how" part of the project is pretty straightforward. Most of the CPython's API functions pygame uses has a direct (or nearly direct) counterpart in tinypy so porting would be a pretty smooth process. As to the order of submodules to be ported, I already have a general idea of how it should be done, i.e. 1. first the stub for the pygame "metamodule" would be implemented 2. then the most important submodules to support basic drawing, along with relevant helper modules (the surface, display, draw, color, locals etc. submodules) 3. then some of the more advanced graphical features, like the ability to render fonts and images (obviously, the font and image submodules along with transform and rect) 4. the next goal would be to make pygame really useful by adding interactive features (key, time, event, mouse; probably mask too, to support collisions) 5. some more "usability" modules (like pixelarray and overlay) 6. and finally, the more "high-level" features (like mixer, music, movie, cdrom, etc) The order of the last two items should possibly be inverted. Concerning documentation, most of the original pygame docs should apply but all things that differ would, of course, be documented. Tests would also be added along the way as tinypy already has a testing framework implemented; this will probably save a lot of bug-induced pain in the long run. :-) As for my schedule, last year was a bit of a turmoil for me (because of an incompatible university schedule and some personal problems) but this year I'm taking (and mostly have already) care of exams earlier so I don't get caught up with them in the summer, meaning I'll be available full time, more or less. I'll be writing the proposal today; I just wanted to share this with the list beforehand in case anyone has any suggestions, corrections or anything that could help me write a better proposal. Thanks in advance, -- Denis Kasak