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 <[email protected]> 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 >
