[pygame] GSOC: pygame module for tinypy
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
Re: [pygame] GSOC: pygame module for tinypy
Hi Denis, looks like a good project... I've forwarded your email onto Phil, so hopefully if he has time he will consider being your mentor for this. Definitely submit your application. - to reuse existing pygame tests, a simple port of the module unittest would save your time. It's not such a big module. - Marcus has separated out pygame specific code... so you could use that. - will send you more feedback when you send your proposal. cheers, On Thu, Apr 2, 2009 at 1:55 AM, Denis Kasak denis.ka...@gmail.com wrote: 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
Re: [pygame] GSOC: pygame module for tinypy
Hi René, Here's my proposal. Looking forward to your feedback. -- Denis Kasak About You = 1) Your Name: Denis Kasak 2) Contact Information: denis.ka...@gmail.com IRC nick: dkasak ICQ: 46413957 XMPP: denis.ka...@gmail.com/Laptop Mobile: (+385) 99 / 595 - 2655 3) Time Zone and Preferred Language: UTC+1 (CEST), English 4) Time Commitment: During the three months of GSOC, I would be available full-time, more or less. I've taken care of major commitments (like exams) so they should not be disruptive over the summer. I'm confident I could port the major part (if not everything) of pygame to tinypy. 5) Programming Experience: 10 years experience in C 6 years experience in C++ 6 years experience in Python A few years experience in LISP, Prolog, Pascal (not an expert, but I have a good working knowledge with all) I was GSOC participant last year under tinypy and I've implemented a sandbox feature (memory and time limit) for it. As a result I'm very familiar with tinypy's internals. I'm a teaching assistant for Programming classes in my university I've written a small plotting/linear regression/statistical analysis library for personal use (for laboratory work in Physics classes) A few small personal games like a text adventure and a curses Snake game I've submitted small patches/bugfixes to FOSS projects (like Miranda IM) 6) Pygame Experience: Not much, but I've often played with it and I use it often to demonstrate Python programming in Programming classes mentioned above. I've also ported the aforementioned Snake to Pygame sometime in the past (and subsequently lost the code in a hard disk failure :-( ) 7) Other skills and experience that are of interest for your aplication: A good knowledge of Mathematics, Physics, Electronics, Signal Theory, Game Theory, etc. (my university is a sadistic place :-) ) I believe I can write pretty good documentation and I enjoy doing it Experienced with SVN and some other VCSs (I've particularly been interested in DVCS lately, e.g. Mercurial) A good knowledge of Linux, POSIX, etc. (I'm a 6+ years user) About Your Project == 1) Please explain in 2 to 3 paragraphs the project you intend to complete. My intention is to port pygame to tinypy by using tinypy's C API. This would mean implementing most (possibly all, if the schedule allows it) submodules of pygame. It would also include implementing unit tests to test the new pygame port, either by reimplementing the tests or reimplementing the Python unittest module (more likely). 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. 2) What existing or future need does your proposed project fulfill? My project would help pygame by providing a very small and tightly integrated Python implementation which could potentially be very attractive for game developers (particulary for embedded platforms). tinypy still has a lot of room left for optimization and it could provide pygame a very small, fast and no baggage platform. It would also make tinypy more attractive to game developers. Overall, it would be beneficiary to the whole game development community. 3) Provide a rough timeline for how you intend to complete your project, test it, and document it within the allotted time period. week 1: Reimplement the unittest module to tinypy so pygame's tests can be used directly. Study the code and documentation for pygame to familiarize with the codebase. weeks 2-3: Implement the pygame module stub. Port the most important submodules to support basic drawing, along with relevant helper modules (the surface, display, draw, color, locals etc. submodules) weeks 4-5: Port 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) weeks 6-7: Port interactive features to start being really useful (key, time, event and mouse modules) weeks 8-9: Port other usability modules (like pixelarray, overlay and mask (for collisions)) weeks 10-11: Port high-level features (mixer, music, movie, cdrom modules) - this chunk of work could also be resized (by omitting some of the modules) to be a safety net in case something goes awry and we need to reschedule. week 12: Fix bugs, write documentation, packaging. In the case that some additional unit tests are needed or some need to be reimplemented, this would be implemented incrementally after porting each module.
Re: [pygame] GSOC: pygame module for tinypy
Hi, I spoke to Phil, and I don't think he's interested in mentoring it. Maybe ask on the tinypy list or psf list*[0] to see if anyone else is interested in mentoring. Or instead think of a separate project proposal(maybe python or SDL related). cheers, *[0] http://mail.python.org/mailman/listinfo/soc2009-general On Thu, Apr 2, 2009 at 1:26 PM, Denis Kasak denis.ka...@gmail.com wrote: Hi René, Here's my proposal. Looking forward to your feedback. -- Denis Kasak
Re: [pygame] GSOC: pygame module for tinypy
On Thu, Apr 2, 2009 at 4:41 AM, René Dudfield ren...@gmail.com wrote: Hi, I spoke to Phil, and I don't think he's interested in mentoring it. Maybe ask on the tinypy list or psf list*[0] to see if anyone else is interested in mentoring. Or instead think of a separate project proposal(maybe python or SDL related). Hey, Thanks for the effort. I'll try both of those lists. -- Denis Kasak
