Wednesday, August 17, 2005

Another pygame release at last.

There is finally a new release for pygame out. I was the one who did this release(with lots of help from others), and below are some notes on how it went, and what is next for pygame.

What is pygame?

Pygame is a is a set of Python modules designed for writing games. It is written on top of the excellent SDL library. This allows you to create fully featured games and multimedia programs in the python language. Pygame is highly portable and runs on nearly every platform and operating system.

Compared to the 1.7.0 release, there is a whole bunch of bug fixes. Compared to the commonly used pygame 1.6.2 there are heaps of changes. A different version of SDL, a different compiler used for the windows version, and a rewrite of the sprite classes.

Lots of new people have begun to submit patches and test things out. Which is really nice. We also followed a release plan. Which was made necessary because of the multiple people working on the release compared to one person previously.

There is also a new website which allows people to register, and show people their projects using pygame. Along with the upcoming pyweek competition with over 150 entrants, pygame continues to live and grow.


What is there to do for the next release?

For me I want to improve what is already in pygame. I want to speed up some areas, and fix up any remaining bugs. For example pygame on linux requires X libraries. Where it should be able to just use the frame buffer.

One place that could do with speed improvements is the transform module. For things like scaling, rotation, flipping, and rotozooming.

I would like to make them quicker by improving the api, and by optimizing the C code, as well as doing asm versions.

However first we need benchmark programs for all of these features. Games can be used, as well as writing programs which stress test the features. For example a rotation benchmark which rotates 30 different images of different sizes, and then blits them to the screen. Another part of the test would be to rotate different same size images without blitting them.

Repeatable benchmarks are important to test the speed on different computers, and to compare between different versions of pygame. The benchmarks can also be used of examples on how to use that functionality.


How ASM(mmx, sse, 3dnow, altivec) optimizations will be done.

I am going to do the asm versions just like the SDL blitters are done. That is detect what cpu features are available and then register the fastest function with the processor features available. This way the same version of the code will run on different processors.

def rotate_C(...):
pass
def rotate_mmx(...):
pass
def rotate_sse(...):
pass

if(has_mmx() and not has_sse()):
rotate = rotate_mmx
elif(has_sse()):
rotate = rotate_sse
else:
rotate = rotate_C

Using vectorizing compilers to make first versions of optimized code.

To start with I am going to use vectorising compilers to make the first pass at the optimized ASM. gcc4. vectorC, msvcc, and icc are all ones which can do auto vectorization. Some compilers are better at vectorizing than others.

Once the first pass is done with those compilers I can see which ones were able to successfuly vectorize the code. Then run them through the benchmark to see which is faster.

Then I can see if changing the algorithm can speed them up at all.

The final pass at optimization would be to change the asm code itself for optimizations.



Rotation as an example of API optimization.

As an example of an api change that could improve the speed, I will describe the rotate api and a way that it can be improved.

The rotate function could be made to do its thing inplace. So instead of this:
newsurf = pygame.transform.rotate(surf, 90)

A new api that could do things 'in place' could be made. ie:
pygame.transform.rotate_ip(angle, src_surf, dest_surf, dest_rect)

Where the destination surface could be reused on each call to rotate. Therefore saving memory allocations, and reusing memory. The given api could even be used to rotate directly onto the screen. Ie a rotating blitter :)

One problem with this api is that a rotated image can use up more space than the original image. Therefore we need to make sure that the destination surface is large enough to hold the rotated image.

Therefore we may need a helper function to calculate the maximum size of a rotated image.
arect = pygame.transform.rotate_maxsize(src_surf, angle = None)

If an angle is given then we get the size of the image that will be created for that angle.

Such a rotation function is going to be quite complex to implement in a way which is easy for the user.

Friday, August 12, 2005

Pretendpaper. Making pretend webs.

Pretend Paper is an arts/music, not for profit website meant to be a place where people can see what is on, and what people are doing. Pretend paper is also a place where you can tell people what creative things you are doing. As well as a place where people can post articles, and reviews of creative things.

Pretend paper is a site that has been made with two other people, and I. With contributions from many others. All of us have been taking a break from it since our launch party in July. Which means that it has been a month and a half since my last major code update.

What makes pretendpaper interesting from a web development point of view, is the new interface ideas. There are two sides of the site. A tab area on the left, and a tab area on the right. When you are viewing stuff on the left you can click to see something related on the right side of the screen. All without reloading the page.

One good use for the tabs is when you are reading the details for an event you will be able to click on a band, or artist listed in the event, and have it pop up the artists profile on the right side of the page.

Interface experiments, and standard controls.

Apart from the tabs, there are a bunch of other interface things in pretend paper too. Some more successful than the others, and some more developed than others. When making new interfaces you need to be able to have people be able to use them right away. So if you are going to include advanced things in your user interface then they need to act how things normally would act.

Standard behaviour is why for the events listing we made it click to change which event you are viewing. People are used to clicking to change things. So having mouseover change the event being viewed can really confuse some people. However, some of the people who used it really prefer viewing things that way. To view 30 different event descriptions with clicking requires 30 clicks. To view them with mouse over requires none. So we made a compomise. The default behaviour is clicking. However if you click on the same event that is highlighted, then it goes into mouse over mode. Give the event listing interface a try.

The scrollbars for example were done with javascript. The reason why they were done with javascript is for consistency accross browsers, and to avoid bugs with iframes in different browsers. Unfortunately the scrollbars are not quite up to par with the standard scrollbars. Standard scrollbars have so many features built in. For example mouse scrolling, variable width thumb controllers, variable speeds depending on the speed of the computer, and keyboard navigation. I have mouse scrolling in there, for those browsers that support it. IE, and Safari 2 support getting events from the mouse scroller. However firefox doesn't. Which annoys me the most as firefox is my current favourite browser.


What has been happening with pretendpaper?

There are still posts going up, and reviews being written. However each bit of content has a manual review process where I put stuff into the database. The interesting thing is that almost every time something is added I make the code a little more tolerant of errors. So that slowly it is getting better at doing what it does.

During this time I have been thinking of what things need to be done to fix up pretendpaper. I have spoken with the others breifly about it. The list of things to fix I have is a mile long, but there are two main things that need to be fixed.

Pretend paper needs to be faster, and it needs to work better at showing people what is going on.


Pretend paper needs to be Better at showing people what is on.

More events, and linking events to profiles are what is needed. As well as searching, and sorting.

Linking to profiles. There needs to be better links to profiles from the events. So people can find out who the people are that are playing. Being able to pop the band profiles up in the right hand tab set whilst skiming through the events would be great. Want to know if a band is uk pop influenced, a noise band, or a death metal band?


For more events to be in the database a few things can be done. The event adding interface needs to be *very* streamlined. So it is as easy as possible for people to add events. Including the site admins. Typing the band names/artist names, and venue into the description box should automatically fill in the fields for you. It should do a search for the venue, and finding any matches show you a list of them, with the most likely ones at the top. It should search through the profiles listed in the site, and

When more people start using the site, there should also be more people adding events to it. However it is the old chicken and egg thing.


Pretend paper needs to be Faster.

Pretendpaper loads slow. With only a couple of sections loading the method I used worked fast enough. However after all five sections were added it started to slow down. If another five sections were added, things would really start to crawl.

How it works is this; at the moment the website makes separate requests for each of the sections. Pretendpaper uses xmlrpc to do the separate requests. Xmlrpc takes quite a bit of cpu power to decode using javascript. So the slowdown is not on the server side of things, it is on the client side.

It should be able to load the whole default front page with one request. So I need to grab everything in one big request. Which is a batching/pipelining optimization. You can often do several things at once faster than doing them one at a time.

Also the front sections should be populated first. So the events tab, and the latest tab should be populated, and then the rest should be.


A work in progress continues.

Lots and lots of work left to do. The site itself is a work of art, one which is not nearly finished. There are so many planned features that have not been implemented, and so many little things that need to be improved.


Monday, August 08, 2005

Work on holepit continues.

Work on my shareware game holepit continues. After about a year break from it, recently I have decided to continue to do things on it when I have time.

The premise of the game is to move blocks into a hole. Every other part of the game comes from there.

To make the game more interesting I am adding a number of incentives to keep playing. One of them is this tunnel special bonus stage. It is kind of like a few different games have used before, where you run down a tunnel collecting things.


I am also adding another character modeled by Geoffrey Bantle. The transvestite cleaning lady. Complete with vacuume, and eventually stubble. She should add a bunch more game-play opportunaties, and make it more interesting overall. She will be the fifth character in the game. As the game involves playing against the other characters, there really does need to be more of them for holepit to be fun.

The character still needs a lot of work. Maybe another five hours painting. Then another 30 hours animating. Then I have to work on the characters AI. Which may take ten hours. Then I need to fit her into the character selection screen, as well as do any other graphical elements she may add to the game. All up, she will probably take a couple of months to get into the game in my spare time.

For the improvements I am listening very carefully to the advice of a select few people I think have a very good understanding of making games. Then I took this list of improvements and just started working on what interests me in my spare time.

An older version of the game got these review scores:
Graphics 69%
Sound 75%
Playability 33%
Longevity 20%

So with these review scores in mind I have been working on playability and longevity features of the game. The tunnel bonus round, and the extra character should make it a better game to play. I am also introducing scoring, and telling people which level they are on out of the total amount of levels. So that they have something to move towards. Not just playing the game for mindless fun. Instead they will have something to achieve.


Play testing the game has also been done during these changes. People play for the first time, and I watch them very closely to see what troubles they are having, and what game play options they like the best. Now I have chosen those options as the default.


The look of the game is one thing which needs improving a lot too. I have had a bunch of people tell me the game looks crude and not very well done. That the top down view is old, and does not provide a good look at the characters. You can't see much of them only looking at thier heads.

The top down view has been changed to a 45 degree view. Giving the player a much better view of the characters. I have also made the arena enclosed within the screen boundaries. This makes it easier for people to realise that there is a barrier there where the blocks will bounce off.


I am attacking each of the things which does not look so good one at a time. All these changes are small, and only make a small contribution to the look of the game. However when all added up they are slowly making the game look better. One of these things I have done is taken away the system mouse cursor, and replaced it with a cool looking 3D hand in the menu screen.


Another gameplay/graphical improvement has been to make the game play in window mode by default, and have the mouse cursor constrained to within the border of the window. By being in a window the graphics look better than full screen. I think this may have something to do with the way it was developed in a window. Windowed mode is the way I like to play it, so naturally I think this may be the way others like to play it too.

Many more things are needed for holepit. Lots and lots of polish. Then I *hope* other people will start to like it as much as me.