Re: [pygame] C/C++ and Python

[René Dudfield <renesd@xxxxxxxxx>]

hi,

The main reasons not to use opengl, and instead use pygame graphics are:
    - opengl is not as portable.
    - it's harder to write opengl code that'll work everywhere because of bugs in various opengl drivers, cards and python bindings.
    - it's more complex to write opengl code.

So if you're just wanting to write a game, I'd avoid opengl.  If you want to play around with graphics, then definitely give opengl a go.  It'll be educational too.





To answer your original question...

Some times you need the extra speed, and then writing C can be a good
way to go.  Or if you need to wrap an existing C library, so you can
use it from python.

pygame tries to keep the minimal amount of things needed done in C/asm so you don't need to write so much C yourself for games.  If there's some code that is useful for lots of games, it might be a good idea to contribute it to pygame, to keep all the C in one place.  So you get the benefit of fast C/asm code, callable from python.

Using C, asm, and python appropriately you get the best of all worlds.  Make the 0%-5% of your code that really needs it be C/asm... if it needs it.


Combined with things lke psyco, and numpy - you can avoid doing a lot of things in C.

The hope is that eventually python itself will come close to C speed, so you'll need less C... However that hope has been with me for over 10 years, and I see no real progress speeding python itself up.  Where as C in the meantime has gotten a lot faster.  C compilers available now can do autovectorization, profile guided optimisations, and all sorts of magic, that python is a long way from.  There's even compilers that help with auto SMPing, and auto MIMDing your code.  I see no reason why this will not continue to be the case.  C has a lot more smarter people working on it compared to python, so will always be a lot faster until that changes(which will not happen in our lifetimes).

However, there is a lot more knowledge in the python community now about jit, and asm stuff than previously... so it'll be interesting to see where we are at with that in 1-5 years.

Having said that, things like pycuda, and pygpu begin to close the gap.  Since they offload a lot of the work to the GPU - which work in an array like manner.  The native language for GPUs is increasingly looking like C - with vector SIMD, and MIMD extensions.  Most C compilers for CPUs also have vector extensions these days too.

Is C still worth learning today?  Yes, for all the reasons above.  


Is it worth using C all the time?  Probably not so much.  I think the best approach is to try and work together on fundamental building blocks in C, and wrap them in your favourite high level language.

This approach is better than using 'pure' java/python/ruby/haskell/lua/etc since all of the different communities can collaborate on a base.  Imagine the size of all the separate communities all contributing to one set of base codes - that's a lot more developers than a 'pure' (I like to call it inbred, not pure) approach will ever achieve.

Most people only use python with pygame, however there are a number of people who mix languages.

Most of the things I work on use a combination of C/asm/python/opengl/pygame and even other languages(c++, obc, js, etc), so I'm biased to this approach.



cu,

... hrmm, that's a lot of words... sorry.

On Mon, Apr 20, 2009 at 4:09 PM, Knapp <magick.crow@xxxxxxxxx> wrote:

On Mon, Apr 20, 2009 at 1:53 AM, Yanom Mobis <yanom@xxxxxxxxxxxxxx> wrote:
> won't using OpenGL in pygame add more dependencies?

But, what is wrong with that? It is not like modern computers have a
lack of free space or it costs extra.

--
Douglas E Knapp

Why do we live?