Re: [pygame] Python, Pygame and Performance

[Pete Shinners <pete@shinners.org>]

Jacob Schwartz wrote:
> Would anyone be interested in writing an article, or some benchmarks to 
> actually give some *solid* evidence we could direct people to when the 
> 'pygame's too slow' argument comes up?
First off I want to point out that Python is far more than a "glue" 
language. While very good at that task, it does even better at a full 
programming language.

Game's have traditionally lagged behind other programming fields with 
lower level coding. But this doesn't mean they aren't following along 
with the rest of the world.

I remember when Wolf3D was nearing release and everyone was rather 
impressed that the game was written in about 90% C. Such a "high level" 
language to be doing all those fancy graphics.

These days the shift is happening again, from the now "low level" C to 
more powerful options. On that list, Python is probably the slowest out 
there, but it is far from out of the race and brings many advantages.

Now game engines themselves are done as low level as possible. There's a 
big difference between writing an engine and writing a game. While not 
all games are going high level, let's see what is out there.

The next step up from C is probably what you see in all Quake3-based 
games. Games with this engine use actual C code, but it uses a custom 
compiler to generate simple bytecode. This bytecode is platform neutral 
and runs in a bytecode interpreter that probably works like python's 
does. Don't be too fooled on the speed though. Because this is coming 
from C it allows the bytecode to be optimized through all the tricks of 
a regular C compiler. This will still be much quicker than Python can 
execute. I believe when the game was released you could run with native 
compiled DLL's or with the bytecode. There was about a 10% difference if 
i remember, but most people didn't notice.

Probably the biggest argument for high level languages is the Unreal 
engine. This is a bigger step up from Quake's compiled C bytecode. 
Unrealscript is a fairly high level object-oriented scripting language. 
It includes some powerful tools for building state-machines directly in 
the language. What is impressive is that the Unrealscript language 
hasn't changed all that much since the original Unreal and the new 
Unreal Tournament 2004. Unrealscript is compiled into a simple platform 
neutral bytecode, just like the Quake's code. This of course allows all 
those fun mods to work for Linux and Mac with no extra compiling or effort.

By now of course several game engines have shipped to store shelves with 
Python as their scripting language. I know Freedom Force used it 
extensively, and I've wondered how critical it is in their newer MMORPG, 
City of Heroes. Other games like "Backyard Hockey" have been created 
almost entirely in Python. After the developers ditched their previous 
simple scripting language SCUMM. I know the Lua language is also used in 
many game titles. Lua is not as high level a language, and definitely 
more of what I'd consider a "glue" tool.

In reality it is considerably slower than C itself. Python doesn't have 
the speed to get down into the pixels themselves for extensive effects. 
In Pygame's case, SDL is our low level game engine. All the graphics 
code is done in C and even some MMX assembly. But still, the game itself 
will be written in Python, and I think most people underestimate it for 
that task.

The only reason to use Python is if you enjoy using it. It is up to the 
task, so if people want it people should use it. Same as any other 
programming language really.

A common performance problem you are going to see right away is SDL's 
tendancy to do all its operations with software. This is fast and 
flexible, but when you get to doing fullscreen animation and effects the 
software performance is far from what can be done directly on graphics 
card hardware. SDL can get some of it's operations to happen in 
hardware, but then you are limited in what you can do. Realize that the 
C users of SDL have this same situation on their hands, don't be quick 
to determine Python is the performance problem here.

As a last footnote here. There was recently a 48-hour game creation 
contest. There were about 60 entries using just about every type of 
language, 10 or so were done with Python. The python entires did quite 
well, showing up in high spots for all voted categories. But looking at 
the results, most of the top spots were taken by C games. My point here 
is, use Python to write games if it works for you. Don't think it 
necessarily makes you more productive or better than anyone else.

In my personal case, Python takes a programmer who could never get a 
complete game finished with C into someone who enjoys creating, fixing, 
and working on game programming. Performance has not been a problem.