On Mon, Apr 20, 2009 at 9:28 AM, René Dudfield <ren...@gmail.com> wrote: > 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.
Have you seen this? http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars Also this makes the python speed point very well. One last thing I would add is that code speed is often not needed anymore. I have never in the last 10 years had to worry about code speed while writing a simple 2d game like pong, tetrus, defender, donky kong or anything else like that. http://www.scipy.org/PerformancePython -- Douglas E Knapp Why do we live?
