Posts

Showing posts from August, 2007

PyWeek #5 theme voting on now! 84 entries so far.

84 entries so far for the pyweek game development competition. Some entries are teams, and some are solo efforts. The themes for this pyweek game development competition are: Twinkle Turmoil Ticking Twisted Tyger, Tyger So join up, and vote for a theme . The Pyweek game competition starts soon. Friday 2007/08/03 Registration open Sunday 2007/08/26 Theme voting underway Sunday 2007/09/02 Challenge start Sunday 2007/09/09 Challenge end, judging begins Sunday 2007/09/23 Judging closes, winners announced

Delight at my new-old recycled laptop

I don't like to contribute too much to all the pollution that getting new hardware contributes too. There's lots of perfectly good old hardware being given away or sold at low prices in second hand stores and online auction sites. A couple of months ago I got a Dell latitude C610 laptop from a place down the road from me that restores and sells old laptops. With only 20 gigs of HD space, and 256 megs of ram it's not anything close to what you'd buy new. However it seems to do ok. I also like to use older hardware for developing software - because it's like 'eating my own dogfood' in a way. If I see the performance problems that the slow computers experience - then I can fix them up. All too often I see websites that perform slowly on old machines, or don't fit important information on their small resolution screens. My franken box The laptop is so nice, that I've mostly retired my old duron 850mhz desktop machine... which I've had since 1997

plone 3 released

Plone 3 has been released!!! Plone is not beta like those other toy frameworks (django, pylons, paste, turbogears). I guess there are more python web frame works out there after all than some people would like you to believe ;) kidding, kidding ... don't eat me. Should be fun to play with... I haven't used it since the 2.x series - so I'm looking forward to seeing all the improvements. Congratulations to the plone team.

Pygame weekly mini sprint 2007/08/22

This week we found and fixed a long time problem with the SRCALPHA flag. Which is the flag used for per pixel alpha (transparent images). In fixing that it turned up a few other issues with Surface. There were problems with error checking, and keyword arguments didn't work. So we got the error checking working, as well as keyword arguments. The major piece of work that went in was the PixelArray from Marcus. This will be what we use to replace surfarray. A PixelArray is like a basic numeric/numpy array, and like what you'd expect returned from a surf.tobuffer() call. With it we will be able to support Numeric, and Numpy by loading them dynamically. I still need to write the surfarray.py which will replace the compiled surfarray. There will be a surfarray_numeric, and surfarray_numpy. So it will be backwards compatible, and you'll be able to use the array type you choose. We will include a frombuffer() method for Numeric arrays - which won't require Numeric to b

javascript for templates - it's happening.

It seems like javascript for template languages might be the way forward. designer friendly. lots of web designers know a little javascript or actionscript. can run in a browser. javascript can be sandboxed. most web developers know a little js too. Web developers that don't know javascript will most likely at know at least a little C/php/perl/java to be able to do a lot of things with javascript. Tenjin allows javascript templates. It also allows many other scripting languages to be used in templates... but that's not really what I'm talking about. Fast, small(200k), opensource and widely deployed javascript/emca script interpreters exist. Tamarin is a emca JIT optimized virtual machine from flash 9, that mozilla is using in upcoming versions of firefox. There is also spidermonkey - the current firefox javascript implementation. Finally there is haxe , which is a emca script like language - that can output .js files, flash swf files, and also neko which runs as a

Don't trust database input either.

The database is just another form of input into your program which you should not trust. You should validate the data coming from your database as much as you do validating the data going into the database. How do you know the database has not been corrupted, or compromised? Or some script on your website is not validating data properly when it updates the database. Or an DB admin decides to edit the database directly and puts in some invalid data. What if someone a year from now hooks up another program to the database, which doesn't use the same data validation that you do? Then your program not validating input data from the database will start to fail. There are many ways data from the database might not be what you are expecting. Not including people putting data in there maliciously. Like if they somehow get your database password. Or if they find an SQL injection. Executing code from the database surely sounds a bit crazy... right? People execute code when they use py

collections in python - using less memory

Each object in python takes up far more memory than you might think. An int object for example does not take up 4 bytes. So creating python objects for each element of a collection of data can use up far more memory than is needed. A simple pattern for avoiding this wasted memory is to store the data in a array.array() then construct an object from the part of the data as you need it. Using python classes to store an int. Virtual 23992 Resident 21176 Constructing python classes to store an int dynamically. Virtual 6572 Resident 3992 As you can see this method can save a *lot* of memory. Here's some basic code demonstrating this technique... this isn't necessarily the API to use, but just demonstrates the memory savings. You can make a nicer to use API on top of that... or use your existing api with get magic properties. wget http://rene.f0o.com/~rene/stuff/collection_memory.py # using python objects... python collection_memory.py 100000 -object & sleep 2 ; ps aux | grep

Pygame weekly mini sprint 2007/08/15

There's been a few new things going into pygame recently. Today two things came off the 'todo before release list'. The first was the pygame.mask module was finished - the remaining from_surface function was implemented. It is 128x faster than the version written in python. It could still be optimized more, but I think it should be fast enough. The second was the new sprite code from DR0ID. This has been a long time in development, and allows some pretty useful functionality for the pygame.sprite module. Like support for layers, blend modes, as well as automatic detection of what is faster - full screen update, or dirty rect update. Now the 'todo before release list' is a lot shorter: windows+mingw compilation instructions remove current C based surfarray which uses Numeric. Replace it with a PixelArray C type. Then implement Numeric and Numpy support in python. Mac OSX scrap fixes - using the new scrap api for clip board support. Marcus has the basics of the

timing and unittests - graphing speed regressions/improvements

Are there any python tools which allow you to run timing tests inside of unittests, and then see a useful report? I'd like to see a report of how long each timing test took, and also see differences between runs. When comparing two runs I'd like to see visually which is faster. Timing information is a very important thing to time for gui applications like games, and websites. As so many machines are very different, it's useful to be able to time things as they run on different machines. A game or website can quite easily run 10-30 times slower even on machines with the same CPU. Many other factors like OS, hard drive speed, available memory, installed drivers, directx/opengl/X/frame buffer, different browser speed, different installed versions of libraries or plugins like flash. Testing all these things manually is almost impossible, testing them manually every time something changes is definitely impossible. So I want to use this tool pygame unittests specifically, an

Pyweek 5 - make a game in a week

pyweek registration is open. For the biannual game jam. http://www.pyweek.org/5/ Which means you can join, and put your self in a team, or join up as a solo entrant. Spend a week(part time) finishing a game using python. Sunday 2nd September to Sunday 9th of September. It is inspired by the ludumdare 48h comps, but people only use python, it is a week long, and there can be teams. Over 100 entrants joined in on the fun previous competitions. Enter to have a chance to prototype your next game, or see if working in a team will work on a small project. Or just have a break, to get your creative juices going, and to feel all of the energy of 100+ people simultaneously feeding off each others creations. http://www.pyweek.org/5/ It's also a great way to learn, and have fun with python. It's possibly the best way to improve your programming skills, and game making skills there is.