[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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.kasak@xxxxxxxxx> 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
>