On May 22, 2004, at 8:18 AM, Pete Shinners wrote:
The thing that impressed me about games in those days were how clever the algorithms were. They really cheated on the math, but there were enough constraints (low resolution, hand optimized maps, etc.) that you really didn't notice so much.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.There are also ways to make Python faster when you need to, with extensions such as psyco and numarray.. and then there's Pyrex when you need to drop down to C but want nice syntax and seamless Python integration.
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.One thing that's interesting to note is that bytecode can be more efficient than typical compiled code in some scenarios. With a small VM like Quake's, the whole interpreter is going to sit in the CPU's cache. Python has a pretty hefty VM and lots of bytecodes so it doesn't do too well there (it's pretty much at the point where compilation flags and small patches to the VM can make or break performance just due to code size). Once you start doing JIT like most Java VMs do and psyco does, you can actually do better than naive statically compiled code since you can generate CPU opcodes on the fly based on runtime constraints (types, host CPU architecture, etc). In a few years, I expect Python to have killer performance because of who's working on it and what they intend to do (projects like PyPy, psyco, Starkiller, IronPython, etc). It's really exciting stuff from a computer science perspective.
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.Eve Online is also another big Python user.. they're actually using Stackless Python.
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.For hardware acceleration with SDL semantics, there is an OpenGL backend for SDL in the works (according to the glSDL author, anyway). I have no idea what the status of it is though.
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.
Attachment:
smime.p7s
Description: application/pkcs7-signature