Skip to main content

gsoc2008ideas — wiki

These are some ideas for projects for pygame in the google summer of code 2008.

Here are the different mentoring organisations that would be interested in doing pygame related projects.

Please have a look at their ideas pages for pygame related ideas. Best to join up with their mailing lists if you're not already, as well as the pygame mailing list to discuss your ideas.

Webcam Support

Most laptops come with webcams, so they present a new form of input from the computer, even more common than joysticks.

Simple, and portable to at least to linux, windows, and Mac OSX. Implemented in C so it can be shared with the wider SDL community.

Have a look at existing python, SDL, and other webcam libraries for inspiration:

vidcapture (windows only)
opencv (windows, linux, OSX)
CVtypes (windows, linux, OSX) using ctypes to wrap OpenCV
portvideo http://reactable.iua.upf.edu/?portvideo
SDL_bgrab http://www.ferzkopp.net/joomla/content/view/20/14/

Sound Input Support

Line in, microphone, streaming from external media through pygame and so forth.

Pygame on Flash

During the europython 2007 pypy sprints some people made a proof of concept pygame running on the flash vm. Another sprint is going to continue this work at pycon 2008 to get pygame games running unmodified (or mostly unmodified) on flash.

Pygame for Tinypy

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.

Better Tests

  • Lots of tests for everything - at least 90% of the API should feature decent tests.
  • Web based system to get people to write tests for pygame - like the doc comments :-).
  • Specialized tests for things like py3k, pypy, flashpygame, pygame-ctypes, tinypy-pygame, SDL 1.3
  • As part of the tests measure how long things take. This helps to find possible bottlenecks.

OSC Networking

OSC is like the new midi protocol for networks. This would let pygame talk to a ot 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.

Links about it:

Easy Networking

There were something like 12 student applications for this in 2006.

Easy Simple Software 3D

Possibly tinyGL, and a few extra parts, or just something like a textured polygon drawer. Basically: model = load_model();model.render(screen, (0,0))

Improved Graphics Format Support

Alpha channel of 8-bit palettes

Float formats

Stuff like mjpeg, animated GIF support, etc.

Math Support, Graphics Types

  • vector (2,3,4)
  • matrix (2x2,3x3,4x4)
  • quaternion

Math for pygame, like vectors, basic matrix, line polygon intersection, etc.

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

  • there's always the problem of people having to have numpy installed.
  • game specific optimized routines. Some stuff is quite a bit faster than what numpy can do.
  • Some people find numpy a bit difficult to get theirs heads around, and find stuff like http://pygame.org/wiki/2DVectorClass simpler.
  • lots of algorithms for games are written in a way that is hard to do with numpy.
  • exposing the routines from something like tinyGL would be pretty easy to do.
  • There's a few existing libraries too: http://cgkit.sourceforge.net/doc2/module-cgkit.cgtypes.html
  • GLSL vector types would be good to look at. To support things like swizzles, v.xy += 1 where it only increments the x and y members.

AI Module

ai. A*, flocking etc.

Optimize Functions

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).

Decent Movie Support

ffmpeg ripoff or something like that.

Better Drawing Primitives

SDL_gfx integration, long promised to work on it by Marcus but still not started with it. Andreas (the SDL_gfx author) is highly interested in a better SDL_gfx, which in turn can enrich pygame.draw and pygame.transform.

Integrate Anti-Grain Geometry

http://antigrain.com/ - only suitable up to version 2.4 due to the license change to GPL for 2.5 and above.

Improved font support

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.

Improved Sprite and Scene System

Generalize the sprite system to make it more flexible without its current overhead that does not fit for many games.

Add a basic scene and state system support for 2D stuff and keep itas generic as possible.

pygame-ctypes

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

Video Effect Plugins.

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.

http://www.piksel.no/pwiki/LiViDO

http://effectv.sourceforge.net/

Also some of the video stuff from freej (an SDL based VJ software) could be cool to place into pygame. Of course freej uses livido plugins for effects too.

pygame.sdl

Create a complete SDL wrapper under pygame.sdl. Low-level objects such as the Surface could be enhanced to reflect the full capabilities of its corresponging SDL implementation.