Posts

Showing posts from January, 2009

pygame, pywebsite -- a website with joystick controls???!??!

Here's a song program written with a pygame style api: import pygame pygame.init() counts = {} going = True while going: events = pygame.event.get() for e in events: if e.type == HTTP: if e.path.startswith('/song/'): song_id = e.path[6:] if e.method == "POST": counts[song_id] = counts.get(song_id, 0) + 1 e.write(counts[song_id]) elif e.path == "/": if e.method == "GET": data = ','.join(['%s=%s' % (k, v) for k, v in counts.iteritems()]) e.write(data) elif e.method == "DELETE": counts.clear() elif e.type in [QUIT, KEYDOWN, JOYBUTTON, MOUSEDOWN]: going = False Note this is not in pygame yet, but is just the possible API. So it can't be benchmarked since it doesn't really exist. It's Vapour-wa

pygame port to S60 nokia phones.

Jussi Toivola has done some more on his pygame port to symbian s60 -- which many nokia phones run. Here's some details of his progress on the port. >>> Jussi Toivola writes: new version is out(SVN 1844): http://jtoivola.googlepages.com/pygame_20090117_signed.sisx New features: - png, jpg, gif and tif image support. - Demo replaced with launcher application -- liquid example ported to s60 -- Comes with initial pen\mouse support( no list scrolling yet ) - Lots of build script configuration - Python embedded as a sis with byte-compiled libraries( PyS60 CE feature ) Detected limitations: While implementing the launcher, I stumbled upon a problem with fonts. Symbian's c-library (estlib) does not allow multiple open file handles on a single file. This causes following code to fail on phone( works on emulator ): font1 = pygame.font.Font( None, 20 ) font2 = pygame.font.Font( None, 30) On the second line pygame tries to open the default font file, but fails in doing so. I worke

pygame.tests and pygame.examples as packages.

As mentioned in pygame.test - moving testing forward the pygame project has moved the tests into the main pygame package(Lenard did all the work). *You* should consider installing the tests for your package too! All the reasons for doing so are listed at pygame.test - moving testing forward ... but I'll repeat them here too: More people will run the tests. people can run the tests to see if everything works in their own programs. Can run tests on a persons computer to see if everything in pygame+ your program is working. Which driver/function combination works, or works fastest? Run tests and find out. Testing a py2exe/pyapp generated binary is much easier. Reuse of our testing enhancements for their own tests. Reporting bugs would be easier. Since everyone could run unittests, since they will be installed everywhere pygame is installed. Result submission of unittests easy. This would result in a much larger base of computers running the unittests and submitting problems.