Hacking on android and pygame.
For the last couple of weeks I've been hacking on my new android tablet in my spare time.
It's one of those cheap 25cm ones (10 inches). Dual core, nvidia graphics, and all of that stuff. Not a bad little device really.
One project has been to port an old game of mine to it using PyGame subset for android(pgs4a). It's a package of a subset of the pygame modules - along with a bundled port of CPython for android. You can either package your apps standalone, or simply install the launcher from the android market, then upload your game to your SD card. Simples.
So far it's been pretty fun, and the other weekend I got something running. Next up is to work on the UI parts. Already it supports keyboard, mouse, mouse+keyboard, and also joystick mode. However, none of them really work with the touch screen on my tablet. I'm not a very big fan of the touch joypad approach. Where they make a virtual joypad on each side of the screen to touch. There are two main actions in [TheGame]... move, and shoot. You can click somewhere, and [MainCharactor] will try and move there. You can also charge up your steam cannon to fire a cannon ball - which requires aiming. There's a few interfaces which could work I think... I'll just have to try them out and see which I like best.
I hacked on the game to the point where I needed to add some missing python modules into the mix, so had to compile the pgs4a myself. That's taken a few days getting used to the tools, coming up against errors and then trying again the next day. The other day I got it compiling... now the next step is to try uploading the creation to the device.
The game in question is Zanthor, and for it I've done some major refactoring in order to modernise the packaging of it a little bit. Now there is a make, and configure script. The code is in the zanthor directory rather than a lib directory, and of course packaged it so it can run on android... the list of packaging changes is quite large but worthwhile. I hope to use it as a test case to improve packaging for games on python. The idea is to automate packaging for multiple platforms from any of the platforms. So that you can create a package for all supported platforms from any of them. This is a project that I've been talking about for *years*... but releasing an actual game with it is the only way to make it actually happen I think.
Whilst on the pygame audio side, a really nice patch was posted to the pygame mailing list for the midi module by Christopher Arndt. It cleans up the the midi module some more, fixes some bugs, and adds some more documentation for the C level API. I still have to push his change up to the portmidi repository... which is a todo I've got for this weekend. This is the sort of polish that I hope we can apply to the other modules in the 1.9.2 release.
A pygame release is planned for soonish. The focus will be a polish release. Hopefully mainly polishing up existing stuff, and finishing off modules that are in an experimental or unfinished state. My main task is to get the documentation under control.
There's over 400 comments on the documentation to work through, so I expect this will take at least 40 hours time. I'm going to improve the comment system on the website to improve the work flow. To add the ability to mark a comment as 'dealt with', or 'example'. So when going through them, the options are 'delete', 'dealt with' or ignore for later.
I've ordered a new dedicated webserver to help out with pygame.org tasks. This should allow us to do some more things than with just the current host. I paid for a year up front, so hopefully don't have to worry about it again for a while. It has an old nvidia graphics card in it, so I hope to do some graphical webserver tasks on it, as well as take some other heavy processing tasks off the main web host.
The new webserver should help us work in some countries where our current web host for pygame.org is blocked too. Our current host does some things governments don't like... so I think that's why pygame is banned there. Or else governments find the zombies on the website scary.
Lenard Lindstrom has been working on some cleanups over the last number of months on some pygame modules. Especially the numpy integration, which is much improved and is finally up to a similar speed compared to the old Numeric implementation. Lenard has also explored converting our documentation system to use a different one. He's started a conversion tool for this, so if it turns out good we should be able to convert our docs over easily.
New binary installers for pygame on OSX is another task I've been working on. I mainly did this for a few people who were attending the London Python Dojo - who wanted pygame working on their Apple supplied python. However there are still a few bugs in it that I need to fix up. The main one being that SDL_image now does not link to libpng and libjpeg by default. That is sort of awesome... in that it can reduce file size. However, it's also sort of not awesome... since OSX does not support a few types of png files that are commonly used in pygame applications. Also pygame uses those libraries to save to png and save to jpeg. The other major change is that this package I made works with the Apple supplied version of python. Increasingly people on OSX don't bother getting the python from python.org. So now we're going to have multiple packages for OSX. One for Apple python on x864, and one for 10.4 ppc/x86 python.org python. I'd also like to allow including the frameworks in the site-packages/pygame/Frameworks/ directory rather than in the system or users Framework directory. This will make installing better, since we won't need to ask for a password, and people should be able to bundle pygame more easily... since it won't be spread all over the file systems.
It's one of those cheap 25cm ones (10 inches). Dual core, nvidia graphics, and all of that stuff. Not a bad little device really.
One project has been to port an old game of mine to it using PyGame subset for android(pgs4a). It's a package of a subset of the pygame modules - along with a bundled port of CPython for android. You can either package your apps standalone, or simply install the launcher from the android market, then upload your game to your SD card. Simples.
So far it's been pretty fun, and the other weekend I got something running. Next up is to work on the UI parts. Already it supports keyboard, mouse, mouse+keyboard, and also joystick mode. However, none of them really work with the touch screen on my tablet. I'm not a very big fan of the touch joypad approach. Where they make a virtual joypad on each side of the screen to touch. There are two main actions in [TheGame]... move, and shoot. You can click somewhere, and [MainCharactor] will try and move there. You can also charge up your steam cannon to fire a cannon ball - which requires aiming. There's a few interfaces which could work I think... I'll just have to try them out and see which I like best.
I hacked on the game to the point where I needed to add some missing python modules into the mix, so had to compile the pgs4a myself. That's taken a few days getting used to the tools, coming up against errors and then trying again the next day. The other day I got it compiling... now the next step is to try uploading the creation to the device.
The game in question is Zanthor, and for it I've done some major refactoring in order to modernise the packaging of it a little bit. Now there is a make, and configure script. The code is in the zanthor directory rather than a lib directory, and of course packaged it so it can run on android... the list of packaging changes is quite large but worthwhile. I hope to use it as a test case to improve packaging for games on python. The idea is to automate packaging for multiple platforms from any of the platforms. So that you can create a package for all supported platforms from any of them. This is a project that I've been talking about for *years*... but releasing an actual game with it is the only way to make it actually happen I think.
zanthor on my android tabletI also started messing around with a jack sound driver for SDL 1.3. Jack is the "professional" low latency sound system for linux(+osx). So far I've got it compiling, but still have a bunch more work to do on that. My todo list for that is still quite long. It's going to be tricky. Jack clients have high requirements to not pull down a jack server if they misbehave. I think I probably need to read through the jack developer documentation a few more times. One difficulty will be loading the modules dynamically... even though usually they are linked in with the "pkg-config --libs jack" tool at compilation time. Not too hard though, since SDL provides some nice cross platform dynamic library loading code.
Whilst on the pygame audio side, a really nice patch was posted to the pygame mailing list for the midi module by Christopher Arndt. It cleans up the the midi module some more, fixes some bugs, and adds some more documentation for the C level API. I still have to push his change up to the portmidi repository... which is a todo I've got for this weekend. This is the sort of polish that I hope we can apply to the other modules in the 1.9.2 release.
A pygame release is planned for soonish. The focus will be a polish release. Hopefully mainly polishing up existing stuff, and finishing off modules that are in an experimental or unfinished state. My main task is to get the documentation under control.
There's over 400 comments on the documentation to work through, so I expect this will take at least 40 hours time. I'm going to improve the comment system on the website to improve the work flow. To add the ability to mark a comment as 'dealt with', or 'example'. So when going through them, the options are 'delete', 'dealt with' or ignore for later.
I've ordered a new dedicated webserver to help out with pygame.org tasks. This should allow us to do some more things than with just the current host. I paid for a year up front, so hopefully don't have to worry about it again for a while. It has an old nvidia graphics card in it, so I hope to do some graphical webserver tasks on it, as well as take some other heavy processing tasks off the main web host.
The new webserver should help us work in some countries where our current web host for pygame.org is blocked too. Our current host does some things governments don't like... so I think that's why pygame is banned there. Or else governments find the zombies on the website scary.
Lenard Lindstrom has been working on some cleanups over the last number of months on some pygame modules. Especially the numpy integration, which is much improved and is finally up to a similar speed compared to the old Numeric implementation. Lenard has also explored converting our documentation system to use a different one. He's started a conversion tool for this, so if it turns out good we should be able to convert our docs over easily.
New binary installers for pygame on OSX is another task I've been working on. I mainly did this for a few people who were attending the London Python Dojo - who wanted pygame working on their Apple supplied python. However there are still a few bugs in it that I need to fix up. The main one being that SDL_image now does not link to libpng and libjpeg by default. That is sort of awesome... in that it can reduce file size. However, it's also sort of not awesome... since OSX does not support a few types of png files that are commonly used in pygame applications. Also pygame uses those libraries to save to png and save to jpeg. The other major change is that this package I made works with the Apple supplied version of python. Increasingly people on OSX don't bother getting the python from python.org. So now we're going to have multiple packages for OSX. One for Apple python on x864, and one for 10.4 ppc/x86 python.org python. I'd also like to allow including the frameworks in the site-packages/pygame/Frameworks/ directory rather than in the system or users Framework directory. This will make installing better, since we won't need to ask for a password, and people should be able to bundle pygame more easily... since it won't be spread all over the file systems.
Comments