Python.. more than scripting??

Python wasn't designed as an extension language. In fact, when you try to use CPython for extension purposes, you run into a number of difficulties and inconveniences. The language was intended to serve as a standalone programming environment, extensible in C; that it is embeddable is a happy side effect.

In other words, yes, it is powerful enough to do more than script. There are all manner of libraries to provide extensive capabilities to Python, from multimedia libraries to full 3D engines.

Enjoy!

Thanks for the info.. So let me get an idea of its capabilities please. Lets say you knew both Python and C++ extensively. You then took an entirely C++ written sourcecode from a game like.. lets say.. half life 2. Now, If you had access to all the 3d models and maps and all that stuff, could you successfully rewrite the entire game in python? Im guessing you would have to of course use python ready APIs such as pyopengl instead of tools that are only made for C++ like DX or OpenGL. So is something like this possible? What would the outcome be? Im obviously not going to do this lol but its just an example to show me what its capable of.

I'm currently learning Python through building little apps - currently text-based games similar to roguelikes (I'll be posting about this in my journal as I go). I'm evaluating it to see how well it suits my purposes as a general programming language; if it works well I'm planning on moving mainly to Python. At the moment I'm more concerned with development time than how fast the program runs.

As Oluseyi wrote, Python is designed as a stand alone programming language with the capability of writing your own libraries in C. My general plan when I get to speed critical apps like games would be to build the thing in Python first, profile it to see where the bottlenecks are (the bits of code that are executed the most), and rewrite those bits in C. If you build your program like that, I could see your Python with C program being almost as fast as a pure C one, with the added benefit of being much easier to write.

Quote:

Original post by biggjoee5790 What would the outcome be?

It would be marginally slower, but that's about it. The Senshi was telling me during GDC about his game that uses PyOpenGL and PyODE, and how it's surprisingly performant as well as flexible and robust - I thought there might be some slow downs with graphics operations, but he said that's not the case.

Ya I read a lot obout people writing in Python and using C to speed up certain portions.. im not concerned with that now anyways since I only know Python :) Also when you say it would be marginally slower, what do you mean by that? Like the game will run at low fps?

Quote:

Original post by biggjoee5790 Also when you say it would be marginally slower, what do you mean by that? Like the game will run at low fps?

In most cases it wont run noticeably slower, unless you are doing a lot of heavy lifting directly in . For most games, the graphics will be running through an already optimised C/C++ API (OpenGL or DirectX), and physics will also be implemented in C/C++, so most of the python code is high-level logic, AI and glue code — not typically the most expensive parts of a game.

so if you use pyopengl and pyode, you dont need any C++ knowledge do you? Do you just have to learn how to access their functions through the python language instead of C++?

It would be helpful to know a little bit about C/C++ syntax because people don't typically rewrite the complete API documentation with Python in mind. At some point you'll probably have to read docs that give C++ examples of usage and work out for yourself how it should look in Python.

It's valuable to know C++. It will remain valuable to know C++ for a long time to come. However, it is not required to know C++ to create a reasonably complex, performant game.

Re marginally slower: some semantically equivalent operations in Python take a little bit longer to complete than their C++ counterparts because the Python version does more. This is due to the nature of the language - the biggest performance hit is in dynamic type resolution, which isn't used in the majority of Python statements but is insanely valuable when you do need it. A pretty cool project I discovered a while back is StarKiller, which removed the dynamism from objects that it can statically determine don't need it. Unfortunately it appears dormant since the 2004 PyCON presentation, and there's been no attempt at integrating it with any production distribution.

Anyway, the areas where this dynamism constitutes a relevant performance penalty are very few. Generally, doing the semantic equivalent in C++ requires more code, anyway, so using Python turns out not to be much slower in practice. What this means for your game is that you can do slightly less each frame - push a few less polygons, apply a few less effects - while maintaining the same frame rate (or, conversely, generate a few less frames per second). It likely won't be a bottleneck for you for quite a while, anyway, so don't worry about it.

to be honest, my python code has run faster than my C code. It's a byproduct of 2 things, first me being a lousy C programmer, and secondly python code is much easier to read after I've written it, so I'm ten times as likely to revise it, and I find the more I revise my code, the faster it goes, and while my python games start off slower than my C ones, they almost always end up faster in the end.

Thanks for the info guys. Im definetely going to learn C++ after i have really gotten good with python. After I feel comfortable with python and I begin making 2d and 3d games (simple ones nothing too crazy) Im going to dive into C++, which im sure will be easier to pick up after knowing python very well

Quote:

Original post by Oluseyi A pretty cool project I discovered a while back is StarKiller, which removed the dynamism from objects that it can statically determine don't need it. Unfortunately it appears dormant since the 2004 PyCON presentation, and there's been no attempt at integrating it with any production distribution.

Maybe that project has been superseded by Psyco? I think Psyco does the same kind of optimization (as well as some others), and it's pretty popular.

Quote:

Original post by pinacolada Quote: Original post by Oluseyi ...StarKiller... Maybe that project has been superseded by Psyco? I think Psyco does the same kind of optimization (as well as some others), and it's pretty popular.

No, they're seperate projects. Psyco shares an/the same author with PyPy, who talked about using StarKiller's methods on the call graphs that PyPy already generates.

Quote:

Original post by swiftcoder Quote: Original post by biggjoee5790 Also when you say it would be marginally slower, what do you mean by that? Like the game will run at low fps? In most cases it wont run noticeably slower, unless you are doing a lot of heavy lifting directly in . For most games, the graphics will be running through an already optimised C/C++ API (OpenGL or DirectX), and physics will also be implemented in C/C++, so most of the python code is high-level logic, AI and glue code — not typically the most expensive parts of a game.

Sadly, this is just untrue.
Python is more than marginally slower than C++, graphics are much more than just OpenGL doing it all, games are more than just graphics and physics.

So your game can be a little game that does not demand that much CPU power, and Python would be perfectly suited for this ( most 2D casuals games falls into this category ).
Or you can have Python and C++ working together, with embedded or extended Python, and C++ doing most of the CPU intensive jobs.

For any modern commercial-quality 3D game, you will need some C++ involved.

Emmanuel

[Edited by - Emmanuel77 on March 2, 2008 6:57:52 PM]

Quote:

Original post by Emmanuel77 Quote: Original post by swiftcoder Quote: Original post by biggjoee5790 Also when you say it would be marginally slower, what do you mean by that? Like the game will run at low fps? In most cases it wont run noticeably slower, unless you are doing a lot of heavy lifting directly in . For most games, the graphics will be running through an already optimised C/C++ API (OpenGL or DirectX), and physics will also be implemented in C/C++, so most of the python code is high-level logic, AI and glue code — not typically the most expensive parts of a game. Sadly, this is just untrue. Python is more than marginally slower than C++, graphics are much more than just OpenGL doing it all, games are more than just graphics and physics. So your game can be a little game that does not demand that much CPU power, and Python would be perfectly suited for this ( most 2D casuals games falls into this category ). Or you can have Python and C++ working together, with embedded or extended Python, and C++ doing most of the CPU intensive jobs. For any modern commercial-quality 3D game, you will need some C++ involved. Emmanuel

haha well thats a completely different opinion lol.. i wonder what the reality is lol :) I guess Ill just find out myself when it comes time

What are your opinions on learning C#? How does that compare to C++ and Python? Is it more suitable for games than python? if so, is it reasonable for a beginner to start with as a first language?

Quote:

Original post by biggjoee5790 What are your opinions on learning C#? How does that compare to C++ and Python? Is it more suitable for games than python? if so, is it reasonable for a beginner to start with as a first language?

Here's the single most important piece of advice you will receive on this issue: it doesn't matter which language you pick.

What matters is that you pick a language, stick with it, and continue working in it until you have a solid grasp of the fundamentals of programming, which are independent of any particular language. There are no bests, just goods. Python is good for beginners. C# is also good for beginners (depending on your perspective, maybe slightly less good, but still good). C++ is not so good for beginners, but a determined beginner starting with C++ will turn out just fine.

Pick a language. Stick with it.

Quote:

Original post by Emmanuel77 So your game can be a little game that does not demand that much CPU power, and Python would be perfectly suited for this ( most 2D casuals games falls into this category ).

I take a number of exceptions to your post. First, the contention that Python is "more than marginally slower than C++" - on what basis? For equivalent source-level instructions, or for equivalent semantic instructions? For what types of instruction complexity? For instance, integer addition in C++ is much faster than in Python because of the need to resolve the late-bound identifier, but dynamic dispatch is much closer because this is the nature of all Python method dispatch. Without context, the statement is meaningless.

Second, the assertion that Python is only good for "little games" that "do not demand that much CPU power" - what precludes Python from demanding extensive CPU power, and employing it effectively? Given a robust and optimized extension module for known bottlenecks (identified by profiling, not making blanket assertions), core application architecture can be defined in Python and proven not to degrade significantly in performance terms. This is precisely the data - anecdotal, perhaps, but better than unsupported assertions - TheSenshi gave me re his experience developing a full-blown 3D game in Python.

High-performance game development in Python ultimately requires the employ of C++ for extension modules, certainly, but a surprising amount of the game itself can be written in Python.

Quote:

Original post by Oluseyi Second, the assertion that Python is only good for "little games" that "do not demand that much CPU power"

If that's true someone should email the Eve Online guys quick before their (stackless) python powered servers fall over!