gsoc2009ideas

Students should adhere to this application format when submitting their final proposals, and it is also a useful set of guidelines to consider when forming and discussing a project proposal.

1. Your Name
2. Contact Information. This should include your email address and IRC nick; Gtalk, AIM, MSN, or other modes of communication are optional.
3. Time Zone and Preferred Language (spoken, not programming)
4. Time Commitment. Briefly explain how much time you would have over the summer to complete your project, and any significant other time commitments.
5. Programming Experience. This can include personal, open source, school, or professional projects you have undertaken or helped with. URLs would be very helpful.
6. Pygame Experience. Describe any experience you have using or developing Pygame.
7. Other skills and experience that are of interest for your aplication (e.g. in-depth math knowledge, excellent writing and documentation skills, etc.)

1. Please explain in 2 to 3 paragraphs the project you intend to complete.
2. What existing or future need does your proposed project fulfill?
3. Provide a rough timeline for how you intend to complete your project, test it, and document it within the allotted time period.
4. Describe how you have brought your project proposal to the Pygame community, their reactions to your proposal, and revisions you have made based on those reactions. (Hint: This is something you really want to do before submitting your application.)

This is a list of projects, sorted by difficulty, that students could take on for GSoC 2009. Feel free to suggest other projects, keeping in mind that they need to be doable in one summer.

These projects can be completed mostly or entirely in Python, or involving porting existing work.

Revive pygame-ctypes for fast prototyping and a better idea flow in both directions (there's a large user base interested in pygame-ctypes)

• Refactor pygame-ctypes.
• Add test targets and test anything available to flesh out all the tiny bugs.
• As it is unmaintained for quite some time now, bring it up to date with the latest development efforts of pygame.

Reading and understanding C code as well as being familiar with Python and ideally ctypes should be no matter for interested developers.

The sprite system of pygame is currently very specific and does not fit the requirements for many games.

• Generalize the sprite system to make it more flexible without its current overhead
• Add a basic scene and state system support for 2D stuff and keep it as generic as possible

This involves a lot of prototyping, sharing design ideas and to communicate a lot with the whole community. You should have made your first steps with Python already and be highly communicative.

pgreloaded is a complete rewrite of pygame, featuring a different API and ABI. Its documentation system is at a very early stage and requires several improvements.

pgreloaded is a complete rewrite of pygame, featuring a different API and ABI. It currently does not have many (not to say no) examples suitable for learning the API.

• Create well-written Python examples covering each area of pgreloaded.
• Create an overall suite based on pgreloaded for pgreloaded that allows users to choose examples quickly, learn about what they do, etc.

This is a good task for Python and pygame beginners. You will have to communicate a lot with the developers and to think about how to improve the API to make it easier for both, the examples you write and users who choose pgreloaded for their project.

These projects are deeper and would require using the C Python API, and coding in C and Python.

Pygame currently supports camera access for v4l2 cameras in Linux. Adding Windows support would require knowledge of Video for Windows, DirectShow, or Direct3D. The goal would be to make cameras usable in Windows under the same API as Linux. This project would require using the Python C API. Below are some references:

Improved font support (BDF, PCF, TTF, bitmap tables). Especially BDF and PCF are interesting for low resource platforms, such as embedded devices, which also can be interesting for pygame.

• Research upon the font specifications and standards
• Design a good, generic font management API for pygame
• Create or port font loaders for different formats

You should also have good C coding skills as most of this will have to be done in C and Python

tinypy is a tiny version of python, with less than 64K of source code. Porting pygame so it works on tinypy would mean a very minimal python optimised for pygame games. Your journey will take you to the land where bits and bytes are counted, so be sure to fasten your C belt and have your good C coding skills around.

Software 3D with the possible option of adding hardware 3D support would be nice to have. Possibly something like tinyGL being used by pygame , and a few extra parts, or just something like a textured polygon drawer. Basically... model = load_model();model.render(screen, (0,0))

You will require some knowledge about 3D APIs and techniques, good C skills and to be strong enough to survive the 2D vs. 3D debates.

Using numpy is always an option, but there's a few reasons to include some types useful in graphics and games:

Pygame could deal with even more graphics formats. This would widen its usage fields and allow developers to stick with their preferred graphics requirements.

The pygame.org website needs to have a redesign and rewrite in python. This includes

• A new, shiny look and feel.
• feed(rss, atom) for wiki recent changes.
• Menu to use alternating background colours - to make it easier to read.
• Optional email notification on project change, including release and comment. A per user, per project option.
• Nicer urls for projects. eg projects/512/zanthor/
• detect tabs in code blocks, and convert to spaces. Either ask to convert to 4 or 8 spaces, or do some magic to figure out how many spaces.
• Browsing projects in more ways. By ranking, by date.
• Spotlight projects changeable from management area.
• Fix website for looking ok in any resolution - currently the header(s) do not scale well.
• Ability to have multiple members for projects
• Members can delete their own projects

Very good webdesign skills, knowledge about content management systems and wiki systems are mandatory. As you will have to write anything in Python, a reasonable knowledge about it is required as well.

A pure C library port based on some parts of pygame has been started recently. It aims to clearly isolate certain parts of pygame and wrap them up in a set of functions and modules for C/SDL developers.

These are extremely difficult projects, and are recommended to be undertaken only if the student has significant prior experience in the subject matter.

Very unstable movie support already exists using smpeg. It has become unusable for several reasons and a completely new solution would be required. Ideally this would be based on some cross-platform backend, such as ffmpeg.

• create an easy to use ffmpeg library wrapper including as many features as possible

Interested developers should have some experience in threaded development and design and be familiar with audio and video streaming. Strong C coding skills as well as some knowledge about cross-platform development are likely to be required.

OSC is like the new midi protocol for networks. This would let pygame talk to a lot of synths, and music programs. It's a latency aware protocol, so it has high resolution time stamps, and bundles of atomic operations, and you can schedule events in the future etc.

All things which are useful for interactive music stuff, but also for games. There's already code that does this, and pygame would then be more useful for multimedia and art type applications.

Please help complete these project ideas and categorize their difficulty. Include references to pages with more information if possible, and give a rough outline of what the project would involve, like where to start, and what languages the coding would be in.

Get a decent vectorizing compiler like vectorC or an intel compiler to help generate mmx assembly for a lot of stable functions.

Architecture specific modules compiled. This could even take advantage of normal gcc optimization flags, which can give a nice speed boost, eg. surface.so, surface_686.so, surface_x86_64.so.

So the setup.py could be changed to compile with different CFLAGS, and then have the modules load the correct one for the particular cpu at runtime(if the module is available).

Using some of the real time video effect plugins would be good. There's a video effect plugins that would also be kind of fun for games too :)

Probably be a pretty simple module to write to allow using the video effect plugins.