Strengths and weaknesses of Pygame vs. pyglet vs. PyOpenGL?

[excord80]

Trying to decide which to get started with. Can anyone suggest some
pros and cons to each of them?

Would PyOpenGL be in the same camp as Pygame and pyglet? Do either of
Pygame or pyglet make use of PyOpenGL behind the scenes?

 

[Patrick Mullen]

Trying to decide which to get started with. Can anyone suggest some
pros and cons to each of them?

Would PyOpenGL be in the same camp as Pygame and pyglet? Do either of
Pygame or pyglet make use of PyOpenGL behind the scenes?

PyOpengl - an opengl wrapper. Version 2 is written in c, version 3
instead uses ctypes
Pyglet - an opengl + events/sound/etc wrapper written in ctypes
pygame - an sdl wrapper for 2d rendering, sound, music, events, etc
that can be used with pyopengl if 3d hardware support is desired.

If you want to do 3d, your choice is basically pygame+pyopengl or
pyglet. pyglet is nice because it comes with everything you need,
versus pygame where you have to interact via pyopengl. Pygame
+pyopengl2 is faster than pyglet or pygame+pyopengl3 becuase pyglet
and pyopengl3 take a hit from ctypes.

There is a project with pyopengl3 though to add some c code to speed
things up, I think it works with numeric.

Pyglet will be easiest to start with and use, it seems to be
everyone's favorite choice these days.

 

[excord80]

[snip]
PyOpengl - an opengl wrapper.  Version 2 is written in c, version 3
instead uses ctypes
Pyglet - an opengl + events/sound/etc wrapper written in ctypes

Does pyglet use PyOpenGL as its OpenGL wrapper? If not, any idea why?
Seems like it would be a fairly substantial duplication of effort.

 

[alex23]

Does pyglet use PyOpenGL as its OpenGL wrapper? If not, any idea why?
Seems like it would be a fairly substantial duplication of effort.

Taken from: http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d

That was more or less the original plan. pyglet wraps OpenGL at the
lowest level, so it only provides glVertex3f, glVertex2d, etc.,
whereas PyOpenGL also provides polymorphic functions such as glVertex. [...]
pyglet provides all of the error-checking functionalities that
PyOpenGL does (though these can be disabled for performance). At
last check, pyglet was significantly faster than PyOpenGL 3, but
slower than PyOpenGL 2.

 

[illume]

hello,

PyOpenGL also has a raw module which includes python bindings closer
to the C calls... however mostly you want to use the nicer more
pythonic versions of functions.

Recent pyopengl 3.x versions have been optimized for speed, including
optional C level optimizations. So I imagine they are faster than
pyglets wrappers(profiling/testing needed). PyOpenGL is also used a
lot more by non-game people, so a wider array of functions are used.

It's very unfortunate that pyglet and pyopengl don't share code...
however recent versions of pyopengl tried to reuse some of pyglets
code... not sure how much has been shared though. Maybe at some point
they will come together.

For now pyglet has created a fork in the python+opengl community,
where the same code can't be reused automatically between the two as
the opengl wrappers are slightly different. However it's not terribly
difficult to port code from one to the other, as some projects have
done.



pygame doesn't require opengl be supported by the video card - it can
use many different video drivers to get the job done. It's nice to be
able to avoid using the 3D parts of gfx cards if you can - to reduce
power consumption, and make your game run on more computers.

pygame is also much more portable, has more people using it, has more
developers, and a stable API. Code you wrote 5 years ago will most
likely still work. Code you wrote for older versions of pyglet will
not work without changes.

pygame is simpler to learn, since it doesn't require you to know how
to create classes or functions. Whereas pyglet requires you to sub
class to do anything.

http://pygame.org/wiki/about


* disclaimer - I'm a pygame developer, and have in the past
contributed to pyopengl - so obviously I prefer pygame and pyopengl.

Does pyglet use PyOpenGL as its OpenGL wrapper? If not, any idea why?
Seems like it would be a fairly substantial duplication of effort.

Taken from:http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d

IIRC pyglet tries to minimize dependencies, so PyOpenGL won't be
used.  However, pyglet's wrapping of OpenGL isn't meant to be
complete; it's only what pyglet itself uses.  You'll need to use
PyOpenGL for the rest.

That was more or less the original plan.  pyglet wraps OpenGL at the
lowest level, so it only provides glVertex3f, glVertex2d, etc.,
whereas PyOpenGL also provides polymorphic functions such as glVertex. [...]
pyglet provides all of the error-checking functionalities that
PyOpenGL does (though these can be disabled for performance).  At
last check, pyglet was significantly faster than PyOpenGL 3, but
slower than PyOpenGL 2.

 

[alex23]

pygame is simpler to learn, since it doesn't require you to know how
to create classes or functions.

I'm not sure if I'd be quick to tout that as an advantage...

 

[James Mills]

I'm not sure if I'd be quick to tout that as an advantage...

Neither would i. Classes and Objects
and good OOP practises can benefit
a pygame game just as well as any
other Python app. What's more using
and learning Python's OO semantics
and syntax is really really easy

--JamesMills

 

[illume]

I'm not sure if I'd be quick to tout that as an advantage...

Hi,

It's easier to teach only requiring *using* classes, and functions
than *creating* them. This is important if it's being used to teach
programming - as you don't need to teach people two fairly large
concepts before you can do anything.

People are motivated by seeing results. So it can be good to let
people do things without requiring much learning. Anyone teaching
object oriented program will tell you that it's a hard concept to
present to people. So if you can avoid teaching parts of OO, and a
bunch of other concepts at the same time, it's easier for people to
handle.

It's quite nice to be able to handle events without requiring
callbacks. Everyone hates callbacks, but lots of people use them for
event systems. However callbacks aren't needed at all for event
programming. Instead you can get an event as an object and then
process it.

Callbacks for events made more sense in languages like smalltalk where
events and method calls were closely aligned concepts(method calls are
messages in smalltalk). However in languages where you don't have
such a close conceptual alignment(such as python), making events
objects instead of method calls is much easier to understand.

Also python has very slow function calls, so avoiding using callbacks
is also faster.

Imagine using callbacks for files? So you would have to subclass
file, and make a read_data method. Then your class will call your
read data method when some data arrives. Kind of annoying, and not
needed.

</rant>

 

[alex23]

It's easier to teach only requiring *using* classes, and functions
than *creating* them.  This is important if it's being used to teach
programming - as you don't need to teach people two fairly large
concepts before you can do anything.

I'm just kind of aghast at the idea of "teaching" anyone how to
program games by using large, imperative chunks of code. I don't see
functions as being a "fairly large concept" at all, and utterly vital
to being able to write anything but the most basic 'hello world'
example code.

Also python has very slow function calls, so avoiding using callbacks
is also faster.

Wouldn't it be better to teach people the basics of coding -before-
setting out to optimise their code?

 

[Pierre-Alain Dorange]

pygame is also much more portable, has more people using it, has more
developers, and a stable API. Code you wrote 5 years ago will most
likely still work. Code you wrote for older versions of pyglet will
not work without changes.

I'm a new python and pygame user (i came from C/C++), very easy to learn
and you got results very fast.

I've done a low investigation before choosing pygame over pyglet.
I choose pygame because i only need 2D and also because it seems there
is more documentations, samples, books and developers for pygame.

pygame is really easy to learn and seems fast to me and easy to extend
(derivate class), support image, sound, etc... And can be bundled with
py2app (Mac) : important to distribute the project.
I just run a bug whn using background music, py2app fail ti create the
bundle...

On my iMac intel, i run my small arcade game (a spaceinvader like)
between 800-1400 fps using dirtyrect.
I can also run without modification on Windows and Unbuntu using WMWare
on the same machine.

--
Pierre-Alain Dorange
<http://microwar.sourceforge.net/>

Ce message est sous licence Creative Commons "by-nc-sa-2.0"
<http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>

 

[illume]

I'm just kind of aghast at the idea of "teaching" anyone how to
program games by using large, imperative chunks of code. I don't see
functions as being a "fairly large concept" at all, and utterly vital
to being able to write anything but the most basic 'hello world'
example code.

Yes, teaching hello world without requiring the creation classes is a
*good thing*. Imagine having to create classes to make a hello world
program? You'd have a typical java hello world program. This means
you need to explain the concept of OO before they can do hello world.

It's about teaching concepts separately, rather than requiring them to
be taught all at once. If you don't need to use something, then why
bother using it? Just for purity? Python has a long history of not
making everything classes.

So I see requiring the creation of classes to do 'hello world' as
being un-pythonic and overly complex. I also see it getting in the
way of seeing results, which is important when intially learning
programming.

Wouldn't it be better to teach people the basics of coding -before-
setting out to optimise their code?

I was explaing the advantages of avoiding callbacks, and avoiding
requiring the creation of classes. I think it's simpler, and faster
to avoid callbacks. I was not saying that it's better to optimize
peoples code before teaching people the basics of programming.

 

[Terry Reedy]

Hi,

It's easier to teach only requiring *using* classes, and functions
than *creating* them. This is important if it's being used to teach
programming - as you don't need to teach people two fairly large
concepts before you can do anything.

Every program defines a function that maps input from the external world
(possible null, but not for a game) to output to the external world
(presumable not null, certainly not for a game). So defining internal
function objects is not that big a step.

I agree that creating new classes is a big step, and that using
callbacks can be a mind-twister.

tjr