Using PyOpenGL for 2D graphics

[Charles Joseph Christie II]

So, I'm trying to find a single good newbie tutorial for using PyOpenGL for 2D
graphics. I haven't found a single one yet, although I have found a few that
focus on C++. Some people recommended that I take a look at the NEHE
tutorials that were re-coded in python on the python page, but those only go
from 1 to 10. Does anyone know where I could find a good starting point (it
doesn't have to be a super-noobish tutorial, just something to give me
examples on how to start) for using PyOpenGL in conjunction with Pygame for
making something?

[Ian Mallett]

Try looking at glOrtho2D() or something like that... Why do you want to use
PyOpenGL for 2D-ness? It's much better suited to 3D stuff. I've always
found it easier to use pygame for 2D games. Oh, and ummm... Don't tell
Silicon Graphics, but I've found pygame is much much faster at 2D.

Post by Charles Joseph Christie II
So, I'm trying to find a single good newbie tutorial for using PyOpenGL for 2D
graphics. I haven't found a single one yet, although I have found a few that
focus on C++. Some people recommended that I take a look at the NEHE
tutorials that were re-coded in python on the python page, but those only go
from 1 to 10. Does anyone know where I could find a good starting point (it
doesn't have to be a super-noobish tutorial, just something to give me
examples on how to start) for using PyOpenGL in conjunction with Pygame for
making something?

[Ian Mallett]

Try http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=21 (but it's not
in python...)

Post by Ian Mallett
Try looking at glOrtho2D() or something like that... Why do you want to
use PyOpenGL for 2D-ness? It's much better suited to 3D stuff. I've always
found it easier to use pygame for 2D games. Oh, and ummm... Don't tell
Silicon Graphics, but I've found pygame is much much faster at 2D.

Post by Charles Joseph Christie II
So, I'm trying to find a single good newbie tutorial for using PyOpenGL for 2D
graphics. I haven't found a single one yet, although I have found a few that
focus on C++. Some people recommended that I take a look at the NEHE
tutorials that were re-coded in python on the python page, but those only go
from 1 to 10. Does anyone know where I could find a good starting point (it
doesn't have to be a super-noobish tutorial, just something to give me
examples on how to start) for using PyOpenGL in conjunction with Pygame for
making something?

[Dave LeCompte (really)]

Post by Ian Mallett
Try looking at glOrtho2D() or something like that...

Yes, glOrtho() or glOrtho2D() both work.

Post by Ian Mallett
Why do you want to use
PyOpenGL for 2D-ness? It's much better suited to 3D stuff.

Well, just because OpenGL was designed for 3D doesn't mean it's not also a
very good tool for 2D.

Some reasons I prefer OpenGL for 2D to SDL's drawing code:

- performance
- sub-pixel positioning
- scaling/rotation
- blending
- vertex coloring
- lots of good documentation, lots of sample code, lots of tips on
optimizing performance available on the web

Basically, a lot of the graphical features I might want to use in a 3D
renderer, I might also want to use in a 2D renderer.

Post by Ian Mallett
I've always
found it easier to use pygame for 2D games. Oh, and ummm... Don't tell
Silicon Graphics, but I've found pygame is much much faster at 2D.

I'm in the other camp - I find OpenGL easy and fast, and if I want to
reuse code from a 2D game in a later 3D project, the port will be much
easier than if I have to rewrite it from SDL to OpenGL.

-Dave LeCompte

[Ian Mallett]

Post by Dave LeCompte (really)

Post by Ian Mallett
Try looking at glOrtho2D() or something like that...

Yes, glOrtho() or glOrtho2D() both work.

Post by Ian Mallett
Why do you want to use
PyOpenGL for 2D-ness? It's much better suited to 3D stuff.

Well, just because OpenGL was designed for 3D doesn't mean it's not also a
very good tool for 2D.
- performance
- sub-pixel positioning
- scaling/rotation
- blending
- vertex coloring
- lots of good documentation, lots of sample code, lots of tips on
optimizing performance available on the web
Basically, a lot of the graphical features I might want to use in a 3D
renderer, I might also want to use in a 2D renderer.

Post by Ian Mallett
I've always
found it easier to use pygame for 2D games. Oh, and ummm... Don't tell
Silicon Graphics, but I've found pygame is much much faster at 2D.

I'm in the other camp - I find OpenGL easy and fast, and if I want to
reuse code from a 2D game in a later 3D project, the port will be much
easier than if I have to rewrite it from SDL to OpenGL.

Yes, by far an large, OpenGL is better at 3D, but 2D? I don't know. My
experience has been that OpenGL is slower, but then again, I was new to that
sort of thing. It would be good to run a few tests to confirm one way or
the other. And yes, you are right. Porting code would be much easier
without those changes.

-Dave LeCompte

[Jasper]

Using openGL for 2D allows you to take advantage of 3D graphics cards
for smooth scrolling and zooming, or to tilt otherwise 2D game boards
into 2D. I also suspect that it'll let you handle more objects on the
screen at once (especially if they're duplicates), although I haven't
done comparison tests for this.

I posted some code along these lines several years ago, extended from
something that Bob Ippolito had posted earlier. Search through the
archives and you should come across something. If there is enough
interest, I can also post my more recent code, but it's a bit more
special case, lacking in simple examples, and probably more involved
than someone new to OpenGL is looking for (it includes things like
texture tiling, texture animation, billboarding, display list
optimization, etc).

The NeHe tutorials are pretty good (even though their programming style
is weak). You only really need the first 10 or so to get started;
afterwards you can look at the later ones and still follow what they're
doing, even if they aren't in Python.

-Jasper

Post by Ian Mallett
Try looking at glOrtho2D() or something like that... Why do you want
to use PyOpenGL for 2D-ness? It's much better suited to 3D stuff.
I've always found it easier to use pygame for 2D games. Oh, and
ummm... Don't tell Silicon Graphics, but I've found pygame is much
much faster at 2D.
So, I'm trying to find a single good newbie tutorial for using PyOpenGL for 2D
graphics. I haven't found a single one yet, although I have found a few that
focus on C++. Some people recommended that I take a look at the NEHE
tutorials that were re-coded in python on the python page, but those only go
from 1 to 10. Does anyone know where I could find a good starting point (it
doesn't have to be a super-noobish tutorial, just something to give me
examples on how to start) for using PyOpenGL in conjunction with Pygame for
making something?

[Ian Mallett]

Post by Jasper
Using openGL for 2D allows you to take advantage of 3D graphics cards
for smooth scrolling and zooming, or to tilt otherwise 2D game boards
into 2D. I also suspect that it'll let you handle more objects on the
screen at once (especially if they're duplicates), although I haven't
done comparison tests for this.

into 3D, but yes.

I posted some code along these lines several years ago, extended from

Post by Jasper
something that Bob Ippolito had posted earlier. Search through the
archives and you should come across something. If there is enough
interest, I can also post my more recent code, but it's a bit more
special case, lacking in simple examples, and probably more involved
than someone new to OpenGL is looking for (it includes things like
texture tiling, texture animation, billboarding, display list
optimization, etc).
The NeHe tutorials are pretty good (even though their programming style
is weak). You only really need the first 10 or so to get started;
afterwards you can look at the later ones and still follow what they're
doing, even if they aren't in Python.
-Jasper

Post by Ian Mallett
Try looking at glOrtho2D() or something like that... Why do you want
to use PyOpenGL for 2D-ness? It's much better suited to 3D stuff.
I've always found it easier to use pygame for 2D games. Oh, and
ummm... Don't tell Silicon Graphics, but I've found pygame is much
much faster at 2D.
So, I'm trying to find a single good newbie tutorial for using PyOpenGL for 2D
graphics. I haven't found a single one yet, although I have found a few that
focus on C++. Some people recommended that I take a look at the NEHE
tutorials that were re-coded in python on the python page, but those only go
from 1 to 10. Does anyone know where I could find a good starting point (it
doesn't have to be a super-noobish tutorial, just something to give

me

Post by Ian Mallett
examples on how to start) for using PyOpenGL in conjunction with Pygame for
making something?

[Jasper]

Post by Jasper
Using openGL for 2D allows you to take advantage of 3D graphics cards
for smooth scrolling and zooming, or to tilt otherwise 2D game boards
into 2D. I also suspect that it'll let you handle more objects on the
screen at once (especially if they're duplicates), although I haven't
done comparison tests for this.
into 3D, but yes.

Right, sorry about that.

Also, to chime in with further posts after the one I replied to:
In my experience OpenGL also performs vastly better than straight SDL.
I routinely have hundreds of sprites on screen animated at 60 FPS, even
while smoothly zooming/panning large textured maps, which SDL just
doesn't handle.

-Jasper

[Ian Mallett]

Post by Jasper

Post by Jasper
Using openGL for 2D allows you to take advantage of 3D graphics

cards

Post by Jasper
for smooth scrolling and zooming, or to tilt otherwise 2D game

boards

Post by Jasper
into 2D. I also suspect that it'll let you handle more objects on

the

Post by Jasper
screen at once (especially if they're duplicates), although I

haven't

Post by Jasper
done comparison tests for this.
into 3D, but yes.

Right, sorry about that.

OK, just making sure :-)

Post by Jasper
In my experience OpenGL also performs vastly better than straight SDL.
I routinely have hundreds of sprites on screen animated at 60 FPS, even
while smoothly zooming/panning large textured maps, which SDL just
doesn't handle.
-Jasper

[kschnee-SEpB88Xup+CsTnJN9+]

Post by Jasper
Using openGL for 2D allows you to take advantage of 3D graphics cards
for smooth scrolling and zooming, or to tilt otherwise 2D game boards into
2D. I also suspect that it'll let you handle more objects on the
screen at once (especially if they're duplicates), although I haven't done
comparison tests for this.

I came across a set of tutorials besides NeHe that are worth referring to,
but I've not got the link on me at the moment.

I'm probably repeating myself, but:

I've been interested in using OpenGL with Pygame for some time, and got to
the point of writing a cube-based rotating "landscape" and a
triangle-based textured landscape with a billboarded sprite.
Unfortunately, I found that I didn't know how to combine OpenGL 3D
graphics with any sort of 2D graphics operations, since you can't just
draw an OpenGL screen and then use Pygame graphics functions to paint atop
it. That means no interface and no text, hence no game. I've tried several
times to use various libraries purportedly for doing that sort of thing,
but have not been able to make any of them work in the limited time
available to me, especially using Windows and my homebrew GUI module.
Every so often I go at it and give up again.

What I'd like is a stupidly simple textured 3D landscape with billboarded
sprites, maybe even viewed from a constant camera angle, with a
decent-looking skybox and an easy way to draw my interface atop that. I'd
even be happy using a flat landscape, ie. a plane that can be tilted and
zoomed. The particular requirements of my game do require, though, that I
load a really big array of heights at once, or be able to load new points
on the fly. For now I've got a working Pygame 2D system using tiles.

What do you think of PyOgre? I haven't looked into it lately, but the last
time I worked with it:
-Creating a small landscape with a nice sky was easy
-The official interface system, CEGUI, wasn't working in Python and I had
to cobble together a barely-working UI of my own
-It wasn't clear to me how to do sprites

When working with 3D there's also the concern with the use of sprites vs.
3D characters. The latter seem to be a lot harder to do, and don't look as
good for the same level of skill.

[Ian Mallett]

Never tried that... The way I do 2D interfaces is to draw them after
everything else at the near clipping plane after a call to glLoadIdentity()

Post by kschnee-SEpB88Xup+CsTnJN9+

Post by Jasper
Using openGL for 2D allows you to take advantage of 3D graphics cards
for smooth scrolling and zooming, or to tilt otherwise 2D game boards

into

Post by Jasper
2D. I also suspect that it'll let you handle more objects on the
screen at once (especially if they're duplicates), although I haven't

done

Post by Jasper
comparison tests for this.

I came across a set of tutorials besides NeHe that are worth referring to,
but I've not got the link on me at the moment.
I've been interested in using OpenGL with Pygame for some time, and got to
the point of writing a cube-based rotating "landscape" and a
triangle-based textured landscape with a billboarded sprite.
Unfortunately, I found that I didn't know how to combine OpenGL 3D
graphics with any sort of 2D graphics operations, since you can't just
draw an OpenGL screen and then use Pygame graphics functions to paint atop
it. That means no interface and no text, hence no game. I've tried several
times to use various libraries purportedly for doing that sort of thing,
but have not been able to make any of them work in the limited time
available to me, especially using Windows and my homebrew GUI module.
Every so often I go at it and give up again.
What I'd like is a stupidly simple textured 3D landscape with billboarded
sprites, maybe even viewed from a constant camera angle, with a
decent-looking skybox and an easy way to draw my interface atop that. I'd
even be happy using a flat landscape, ie. a plane that can be tilted and
zoomed. The particular requirements of my game do require, though, that I
load a really big array of heights at once, or be able to load new points
on the fly. For now I've got a working Pygame 2D system using tiles.
What do you think of PyOgre? I haven't looked into it lately, but the last
-Creating a small landscape with a nice sky was easy
-The official interface system, CEGUI, wasn't working in Python and I had
to cobble together a barely-working UI of my own
-It wasn't clear to me how to do sprites
When working with 3D there's also the concern with the use of sprites vs.
3D characters. The latter seem to be a lot harder to do, and don't look as
good for the same level of skill.

[Peter Nicolai]

check out Opioid2D

Post by Ian Mallett
Never tried that... The way I do 2D interfaces is to draw them after
everything else at the near clipping plane after a call to glLoadIdentity()

Post by kschnee-SEpB88Xup+CsTnJN9+

Post by Jasper
Using openGL for 2D allows you to take advantage of 3D graphics cards
for smooth scrolling and zooming, or to tilt otherwise 2D game boards

into

Post by kschnee-SEpB88Xup+CsTnJN9+

Post by Jasper
2D. I also suspect that it'll let you handle more objects on the
screen at once (especially if they're duplicates), although I haven't

done

Post by kschnee-SEpB88Xup+CsTnJN9+

Post by Jasper
comparison tests for this.

I came across a set of tutorials besides NeHe that are worth referring to,
but I've not got the link on me at the moment.
I've been interested in using OpenGL with Pygame for some time, and got to
the point of writing a cube-based rotating "landscape" and a
triangle-based textured landscape with a billboarded sprite.
Unfortunately, I found that I didn't know how to combine OpenGL 3D
graphics with any sort of 2D graphics operations, since you can't just
draw an OpenGL screen and then use Pygame graphics functions to paint atop
it. That means no interface and no text, hence no game. I've tried several
times to use various libraries purportedly for doing that sort of thing,
but have not been able to make any of them work in the limited time
available to me, especially using Windows and my homebrew GUI module.
Every so often I go at it and give up again.
What I'd like is a stupidly simple textured 3D landscape with billboarded
sprites, maybe even viewed from a constant camera angle, with a
decent-looking skybox and an easy way to draw my interface atop that. I'd
even be happy using a flat landscape, ie. a plane that can be tilted and
zoomed. The particular requirements of my game do require, though, that I
load a really big array of heights at once, or be able to load new points
on the fly. For now I've got a working Pygame 2D system using tiles.
What do you think of PyOgre? I haven't looked into it lately, but the last
-Creating a small landscape with a nice sky was easy
-The official interface system, CEGUI, wasn't working in Python and I had
to cobble together a barely-working UI of my own
-It wasn't clear to me how to do sprites
When working with 3D there's also the concern with the use of sprites vs.
3D characters. The latter seem to be a lot harder to do, and don't look as
good for the same level of skill.

[Patrick Mullen]

kschnee-SEpB88Xup+CsTnJN9+***@public.gmane.org:

I use python-ogre, which is a more recent much better version of pyogre by a
different team. Cegui works with it and is pretty nice, although feels like
overkill for most things. I have never really looked at sprites or any kind
of 2d stuff with it though, our game is completely 3d. As a robust 3d
rendering engine, nothing else I know of comes close, at least out of things
usable from python. It surely has a learning curve though, and its quite
big (which can be a positive and a negative).

Fonts in opengl aren't too difficult, neither is rendering an interface.
You will want to render the interface AFTER you render all the 3d elements,
and turn off the depth buffer before you render it so it is rendered on top
of everything. There are numerous font systems around, I use some code
treeform gave me on irc which I modified for pygame. I attached it for
you. Openglcontext which is somewhat of an addon for pyopengl also has font
code. Lastly, I once programmed my own font system using the NeHe tutorial
as a guide - it was confusing because there is so much windows api specific
code in that tutorial, but the basic idea is the same - load each letter of
the font as a texture and draw quads with the proper texture.

I attached this code as well, although this is not as well tested or clear.

[kschnee-SEpB88Xup+CsTnJN9+]

Post by Patrick Mullen
I use python-ogre, which is a more recent much better version of pyogre
by a different team. Cegui works with it and is pretty nice, although
feels like overkill for most things. I have never really looked at
sprites or any kind of 2d stuff with it though, our game is completely 3d.
As a robust 3d
rendering engine, nothing else I know of comes close, at least out of
things usable from python. It surely has a learning curve though, and its
quite big (which can be a positive and a negative).

Thanks. CEGUI does look nice (and the X-Com remake advertised on its site
looks promising). I'm also amused that the Python-Ogre site still carries
a code snippet I did on "a crude way to input text" from when people were
still trying to get CEGUI to work in PyOgre. Anyway, the new Python-Ogre
seems worth looking into. One of the tutorials says you can use it with
Pygame in a way that creates the screen with the familiar line:
"self.screen = pygame.display.set_mode((width,height))". Does that mean I
can draw whatever I want on top of the Ogre window, with normal Pygame
blitting functions, or are we still in OpenGL land?

Looks like it does terrain but the "paging" function that would allow a
really big terrain is either not-yet-implemented or available through a
plugin.

[Patrick Mullen]

Yes, there are a lot of things in ogre that are somewhat considered add-ons,
that python-ogre doesnt yet wrap, unfortunately. You can use pygame to
handle windowing, just like you would in an opengl app, and it works the
same way. Opengl is given direct access to the contents of the window, so
you wont be drawing typical sdl stuff to the screen like you would like.

It does wrap an impressive amount of code though, quite often I see someone
suggest another thing that needs to be wrapped on the message board, and the
next week the code is there, so the team behind it is really great. The
future looks very bright, but even as is it feels very complete and
professional to me.

[Charles Joseph Christie II]

Post by Peter Nicolai
check out Opioid2D

One of my friends was using that to make a game engine for shoot-em-ups (I'm
talking arcade shoot-em-ups, not First Person Shooters), and Shang (the
creator of opioid) actually dropped in on us at the thread for the engine and
seemed like he was more than happy to help my buddy get his engine working
fine. That's my second recommendation to use it, so I'll probably look into
it.

Can it be used in conjunction with Pygame, or is it it's own thing? It looks
standalone to me, but I haven't gotten a chance to seriously research it. But
it looks pretty good.

[Sami Hangaslammi]

Post by Charles Joseph Christie II
Can it be used in conjunction with Pygame, or is it it's own thing? It looks
standalone to me, but I haven't gotten a chance to seriously research it. But
it looks pretty good.

The current version of Opioid2D is built on top of pygame, so that you
use the O2D API for on-screen graphics and regular pygame APIs for
sound effects, joysticks, off-screen surfaces etc.

The display is always in opengl mode, so you can't blit or draw
directly to the screen with pygame when using Opioid2D.

[Charles Joseph Christie II]

Post by Sami Hangaslammi

Post by Charles Joseph Christie II
Can it be used in conjunction with Pygame, or is it it's own thing? It
looks standalone to me, but I haven't gotten a chance to seriously
research it. But it looks pretty good.

The current version of Opioid2D is built on top of pygame, so that you
use the O2D API for on-screen graphics and regular pygame APIs for
sound effects, joysticks, off-screen surfaces etc.
The display is always in opengl mode, so you can't blit or draw
directly to the screen with pygame when using Opioid2D.

Awesome. I'll go try it right now!

[Simon Oberhammer]

Post by kschnee-SEpB88Xup+CsTnJN9+
What I'd like is a stupidly simple textured 3D landscape with billboarded
sprites, maybe even viewed from a constant camera angle, with a
decent-looking skybox and an easy way to draw my interface atop that.

you might also want to checkout soya3d, it handles smooth landscape
generation from heightmap, billboards and has several predefined
camera-modes. doesn't offer anything to help you with the interface though.

http://home.gna.org/oomadness/en/soya3d/tutorials/index.html

I used it for a shooter-game. It's alright once you got used to the
sometimes strange nomenclature.

[kschnee-SEpB88Xup+CsTnJN9+]

Post by Simon Oberhammer
you might also want to checkout soya3d, it handles smooth landscape
generation from heightmap, billboards and has several predefined
camera-modes. doesn't offer anything to help you with the interface though.
http://home.gna.org/oomadness/en/soya3d/tutorials/index.html

I looked into Soya. My trouble with that engine was that I wasn't able to
import new models into the thing, and that somebody mentioned having
trouble getting the thing to run.

There's also Panda3D, which is sort of a Python wrapper and actually
includes Python in its download version. That one seems to have its own
special EXE builder, so you can't just build your application your own
way.

[Ian Mallett]

In your call to glViewport() put in (60,60, width-120, height-120) and draw
in the 60 pixel border. Would that work?

Post by kschnee-SEpB88Xup+CsTnJN9+

Post by Jasper
Using openGL for 2D allows you to take advantage of 3D graphics cards
for smooth scrolling and zooming, or to tilt otherwise 2D game boards

into

Post by Jasper
2D. I also suspect that it'll let you handle more objects on the
screen at once (especially if they're duplicates), although I haven't

done

Post by Jasper
comparison tests for this.

I came across a set of tutorials besides NeHe that are worth referring to,
but I've not got the link on me at the moment.
I've been interested in using OpenGL with Pygame for some time, and got to
the point of writing a cube-based rotating "landscape" and a
triangle-based textured landscape with a billboarded sprite.
Unfortunately, I found that I didn't know how to combine OpenGL 3D
graphics with any sort of 2D graphics operations, since you can't just
draw an OpenGL screen and then use Pygame graphics functions to paint atop
it. That means no interface and no text, hence no game. I've tried several
times to use various libraries purportedly for doing that sort of thing,
but have not been able to make any of them work in the limited time
available to me, especially using Windows and my homebrew GUI module.
Every so often I go at it and give up again.
What I'd like is a stupidly simple textured 3D landscape with billboarded
sprites, maybe even viewed from a constant camera angle, with a
decent-looking skybox and an easy way to draw my interface atop that. I'd
even be happy using a flat landscape, ie. a plane that can be tilted and
zoomed. The particular requirements of my game do require, though, that I
load a really big array of heights at once, or be able to load new points
on the fly. For now I've got a working Pygame 2D system using tiles.
What do you think of PyOgre? I haven't looked into it lately, but the last
-Creating a small landscape with a nice sky was easy
-The official interface system, CEGUI, wasn't working in Python and I had
to cobble together a barely-working UI of my own
-It wasn't clear to me how to do sprites
When working with 3D there's also the concern with the use of sprites vs.
3D characters. The latter seem to be a lot harder to do, and don't look as
good for the same level of skill.

[kschnee-SEpB88Xup+CsTnJN9+]

Post by Ian Mallett
In your call to glViewport() put in (60,60, width-120, height-120) and
draw in the 60 pixel border. Would that work?

Not sure, but on further experimentation I was able to adapt some code
posted on GameDev.net, to draw a flat array of 100x100 tiles that could be
scrolled and zoomed, with a 2D rectangle pasted atop the screen using
glOrtho(); all hooked up to Pygame event handling. That would be the
beginning of an OpenGL-based 2D tile engine and UI, given sufficient time
and motivation to figure out text drawing and other interface elements. I
don't think you can just draw the interface by blitting; drawing a
textured window border would probably involve four weirdly-textured quads,
for instance. Overkill!

[Campbell Barton]

this may help?

http://members.optusnet.com.au/cjbarton/jump_run/

wrote a 2 player platform jump'n run.ages ago with pygame and opengl...
I was learning at the time but it may be helpful as a reference when
your starting off...

Has a realy simple level editor and physics function- all in ~600 lines,
pyogl_game.py is the file you might be interested in looking at.

Post by kschnee-SEpB88Xup+CsTnJN9+

Post by Ian Mallett
In your call to glViewport() put in (60,60, width-120, height-120) and
draw in the 60 pixel border. Would that work?

Not sure, but on further experimentation I was able to adapt some code
posted on GameDev.net, to draw a flat array of 100x100 tiles that could be
scrolled and zoomed, with a 2D rectangle pasted atop the screen using
glOrtho(); all hooked up to Pygame event handling. That would be the
beginning of an OpenGL-based 2D tile engine and UI, given sufficient time
and motivation to figure out text drawing and other interface elements. I
don't think you can just draw the interface by blitting; drawing a
textured window border would probably involve four weirdly-textured quads,
for instance. Overkill!

[Simon Wittber]

I've been told pyglet (http://pyglet.org/) is approaching a stable
release. AFAIK, Pyglet works without pygame.

If you're after brain dead simple 2D OpenGL functions only, try gfx.gl
in the GFX package. (http://cheeseshop.python.org/pypi/GFX).

Dumb GFX example:

1 import pygame
2 from pygame.locals import *
3 from gfx import gl
4
5 pygame.init()
6 flags = OPENGL|DOUBLEBUF|HWSURFACE
7 pygame.display.set_mode((800,600), flags)
8 gl.init((800,600))
9 image = pygame.image.load('ball.png')
10 texture_id = gl.load_texture(pygame.image.tostring(image, 'RGBA'),
image.get_size())
11 running = True
12 w,h = image.get_size()
13 while running:
14 if QUIT in (i.type for i in pygame.event.get()):
15 running = False
16 gl.draw_quad((0,0),((0,0),(0,h),(w,h),(w,0)), texture_id=texture_id)
17 pygame.display.flip()
18

[Matthew Marshall]

I'll also throw in a mention of my own project, Rabbyt
(http://matthewmarshall.org/projects/rabbyt/) Like Simon's GFX, it's done in
Pyrex for speed. (The two libraries can actually be used simultaneously
without problems.)

Here's a port of Simon's "dumb" example (quick, untested):

import pygame
import rabbyt

rabbyt.init_display()

ball = rabbyt.Sprite("ball.png")

# Make the ball bounce up and down :-)
ball.y = rabbyt.lerp(0, 100, dt=1000, extend="reverse")

running = True
while running:
if QUIT in (i.type for i in pygame.event.get()):
running = False
rabbyt.clear()
rabbyt.set_time(pygame.time.get_ticks())
ball.render()
pygame.display.flip()

Post by Simon Wittber
I've been told pyglet (http://pyglet.org/) is approaching a stable
release. AFAIK, Pyglet works without pygame.
If you're after brain dead simple 2D OpenGL functions only, try gfx.gl
in the GFX package. (http://cheeseshop.python.org/pypi/GFX).
1 import pygame
2 from pygame.locals import *
3 from gfx import gl
4
5 pygame.init()
6 flags = OPENGL|DOUBLEBUF|HWSURFACE
7 pygame.display.set_mode((800,600), flags)
8 gl.init((800,600))
9 image = pygame.image.load('ball.png')
10 texture_id = gl.load_texture(pygame.image.tostring(image, 'RGBA'),
image.get_size())
11 running = True
12 w,h = image.get_size()
15 running = False
16 gl.draw_quad((0,0),((0,0),(0,h),(w,h),(w,0)),
texture_id=texture_id) 17 pygame.display.flip()
18

[Charles Joseph Christie II]

Post by Matthew Marshall
I'll also throw in a mention of my own project, Rabbyt
(http://matthewmarshall.org/projects/rabbyt/) Like Simon's GFX, it's done
in Pyrex for speed. (The two libraries can actually be used simultaneously
without problems.)
import pygame
import rabbyt
rabbyt.init_display()
ball = rabbyt.Sprite("ball.png")
# Make the ball bounce up and down :-)
ball.y = rabbyt.lerp(0, 100, dt=1000, extend="reverse")
running = True
running = False
rabbyt.clear()
rabbyt.set_time(pygame.time.get_ticks())
ball.render()
pygame.display.flip()

Post by Simon Wittber
I've been told pyglet (http://pyglet.org/) is approaching a stable
release. AFAIK, Pyglet works without pygame.
If you're after brain dead simple 2D OpenGL functions only, try gfx.gl
in the GFX package. (http://cheeseshop.python.org/pypi/GFX).
1 import pygame
2 from pygame.locals import *
3 from gfx import gl
4
5 pygame.init()
6 flags = OPENGL|DOUBLEBUF|HWSURFACE
7 pygame.display.set_mode((800,600), flags)
8 gl.init((800,600))
9 image = pygame.image.load('ball.png')
10 texture_id = gl.load_texture(pygame.image.tostring(image, 'RGBA'),
image.get_size())
11 running = True
12 w,h = image.get_size()
15 running = False
16 gl.draw_quad((0,0),((0,0),(0,h),(w,h),(w,0)),
texture_id=texture_id) 17 pygame.display.flip()
18

I've got so many choices...

Too bad I suck at making decisions. :P

I have actually decided that I'd try to use Opioid2D for my first game...

I have decided to make a simple strategy RPG for my first game idea. I'm
leaning toward making it a Touhou doujin game. OK, gotta go... See ya later!

[altern]

Post by Jasper
I posted some code along these lines several years ago, extended from
something that Bob Ippolito had posted earlier. Search through the
archives and you should come across something. If there is enough
interest, I can also post my more recent code, but it's a bit more
special case, lacking in simple examples, and probably more involved
than someone new to OpenGL is looking for (it includes things like
texture tiling, texture animation, billboarding, display list
optimization, etc).

please post it. it is always interesting to see this kind of code.

enrike

[Greg Ewing]

Don't tell Silicon Graphics, but I've found pygame is much much faster
at 2D.

That's rather surprising, assuming you have hardware acceleration.

It probably has to do with how you're sending the coordinates
to OpenGL. Making lots of calls to glVertex() from Python will
be inefficient, even more so than it would in C, due to the
slowness of Python function calls.

Putting your coordinates into an array and using one of the
array-oriented calls ought to be a lot better.

Another useful technique is to put frequently-used sequences
of operations into display lists, then you can invoke them
with just a single Python call.

--
Greg

[Jasper]

Post by Greg Ewing
Another useful technique is to put frequently-used sequences
of operations into display lists, then you can invoke them
with just a single Python call.

This last optimization gave me my biggest improvement in OpenGL speed,
dramatically increasing the FPS when drawing lots of identical sprites.
It ended up being the only optimization I needed.

-Jasper

[JoN]

Post by Jasper

Post by Greg Ewing
Another useful technique is to put frequently-used sequences
of operations into display lists, then you can invoke them
with just a single Python call.

This last optimization gave me my biggest improvement in OpenGL speed,
dramatically increasing the FPS when drawing lots of identical sprites.
It ended up being the only optimization I needed.
-Jasper

Gives you an idea of the hoops game-houses go through to squeeze every drop of
performance out of big scenes, eh!

Jon



--------------------------------------------------------------------
Come and visit Web Prophets Website at http://www.webprophets.net.au

[Dave LeCompte (really)]

Post by Greg Ewing
Making lots of calls to glVertex() from Python will
be inefficient, even more so than it would in C, due to the
slowness of Python function calls.

And it's not just the Python function calls (which we know are slow) - the
PyOpenGL wrapper actually does error checking for you on every call, so it
can raise an assertion if something goes wrong. The overhead of this error
checking adds to the function call slowness.

Even more reason to use display lists or otherwise group your data.


-Dave LeCompte

[Charles Joseph Christie II]

Post by Dave LeCompte (really)

Post by Greg Ewing
Making lots of calls to glVertex() from Python will
be inefficient, even more so than it would in C, due to the
slowness of Python function calls.

And it's not just the Python function calls (which we know are slow) - the
PyOpenGL wrapper actually does error checking for you on every call, so it
can raise an assertion if something goes wrong. The overhead of this error
checking adds to the function call slowness.
Even more reason to use display lists or otherwise group your data.
-Dave LeCompte

All of this information is very helpful! I'm glad I asked you guys ;)

I've downloaded the Python version of NeHe 1-10, and I'll take a look at it
soon.

One of the reasons I wanted to get into OpenGL, although I probably won't be
learning it until A LOT later, is things like particle effects and other
types of visual effects (I know a lot of people who used Direct3D in their 2D
games to do such things), and plus I had assumed that OpenGL draws more
things much quicker if you have Direct Rendering and code it properly.

Plus, I'm learning 3D modeling and, although 3D graphics for games don't seem
as good as well polished 2D graphics to me, I'd like to at least experiment
with the idea as soon as I stop sucking at Blender. Plus, if I ever want to
make that Tetris Attack clone (in the far future) with the 3D mode, well, it
has to be in 3D :P

Also, kinda off-topic, I've found an idea for my first game that is so simple,
that even I can't screw it up.
...I think. (Plus, the game is awesomely addictive)
http://jayisgames.com/archives/2007/05/speed_cluster_2.php

A simple game concept, yes? I think I could do it. I'm positive, in fact. I
could practice all sorts of simple concepts, like randomization, 2D graphics,
simple logic, and different types of input, like keyboard and mouse. Oh, and
I can finally learn how to make a menu. I still have no clue how to do that
(or make any other screens, scenes and popup menus in games).

[Ian Mallett]

Blender! Wow! I've been looking all over for something like that! (I had
heard of it, but I thought it cost money). Here I've been making
gigantically detailed objects (ex: airplane with 3D wings complete with
those little supporting cross-sections on the inside that no one can
remember the name of). Thanks!

Post by Charles Joseph Christie II

Post by Dave LeCompte (really)

Post by Greg Ewing
Making lots of calls to glVertex() from Python will
be inefficient, even more so than it would in C, due to the
slowness of Python function calls.

And it's not just the Python function calls (which we know are slow) -

the

Post by Dave LeCompte (really)
PyOpenGL wrapper actually does error checking for you on every call, so

it

Post by Dave LeCompte (really)
can raise an assertion if something goes wrong. The overhead of this

error

Post by Dave LeCompte (really)
checking adds to the function call slowness.
Even more reason to use display lists or otherwise group your data.
-Dave LeCompte

All of this information is very helpful! I'm glad I asked you guys ;)
I've downloaded the Python version of NeHe 1-10, and I'll take a look at it
soon.
One of the reasons I wanted to get into OpenGL, although I probably won't be
learning it until A LOT later, is things like particle effects and other
types of visual effects (I know a lot of people who used Direct3D in their 2D
games to do such things), and plus I had assumed that OpenGL draws more
things much quicker if you have Direct Rendering and code it properly.
Plus, I'm learning 3D modeling and, although 3D graphics for games don't seem
as good as well polished 2D graphics to me, I'd like to at least experiment
with the idea as soon as I stop sucking at Blender. Plus, if I ever want to
make that Tetris Attack clone (in the far future) with the 3D mode, well, it
has to be in 3D :P
Also, kinda off-topic, I've found an idea for my first game that is so simple,
that even I can't screw it up.
...I think. (Plus, the game is awesomely addictive)
http://jayisgames.com/archives/2007/05/speed_cluster_2.php
A simple game concept, yes? I think I could do it. I'm positive, in fact. I
could practice all sorts of simple concepts, like randomization, 2D graphics,
simple logic, and different types of input, like keyboard and mouse. Oh, and
I can finally learn how to make a menu. I still have no clue how to do that
(or make any other screens, scenes and popup menus in games).

[Greg Ewing]

Post by Ian Mallett
3D wings complete with
those little supporting cross-sections on the inside that no one can
remember the name of

Ribs?

--
Greg

[Ian Mallett]

Perhaps. They're those things that look like cross-sections. See attached
for what I made them look like.

Post by Ian Mallett
3D wings complete with
those little supporting cross-sections on the inside that no one can
remember the name of

Ribs?
--
Greg

[Ian Mallett]

Yes, display lists were the single thing that increased my speed as well-
tripling it to over 60fps with huge maps and objects with my thousands of
quads (I really must start using triangles).

Post by Dave LeCompte (really)

Post by Greg Ewing
Making lots of calls to glVertex() from Python will
be inefficient, even more so than it would in C, due to the
slowness of Python function calls.

And it's not just the Python function calls (which we know are slow) - the
PyOpenGL wrapper actually does error checking for you on every call, so it
can raise an assertion if something goes wrong. The overhead of this error
checking adds to the function call slowness.
Even more reason to use display lists or otherwise group your data.
-Dave LeCompte

[Ian Mallett]

Right. Read the entire thing; I had an older computer where that was true,
but my new one's record fps is over 600 (nothing on the screen).

Post by Greg Ewing

Don't tell Silicon Graphics, but I've found pygame is much much faster
at 2D.

That's rather surprising, assuming you have hardware acceleration.
It probably has to do with how you're sending the coordinates
to OpenGL. Making lots of calls to glVertex() from Python will
be inefficient, even more so than it would in C, due to the
slowness of Python function calls.
Putting your coordinates into an array and using one of the
array-oriented calls ought to be a lot better.
Another useful technique is to put frequently-used sequences
of operations into display lists, then you can invoke them
with just a single Python call.
--
Greg

[Benjamin Hess]

Hi Charles

Maybe you can use one of these OpenGL 2D libraries for pygame:

LGT Lightweight Game Toolkit: http://www.pygame.org/projects/9/20/
SiGL: http://www.pygame.org/projects/9/176/
Mirra: http://www.pygame.org/projects/9/117/
pygext: http://www.pygame.org/projects/9/103/
ogl: http://www.pygame.org/projects/9/280/


Ben

[Patrick Mullen]

Opengl will be slower than sdl on computers with either bad graphics cards
or bad graphics drivers, but in general it is much much faster. On the
order of 10 times faster or more for some things. But you have to code the
opengl way, and not the sdl way.

Directly modifying pixels in a texture is going to be slower than blitting
pixels to the screen, so you will want to use another interface to draw
pixels to a texture and then replace the texture for it to be update on the
screen. If you can find a way to accomplish what you want without changing
or editing textures, it will probably work a bit better. On more advanced
cards you can use pixel rendering functions to offset this issue, but that
is less portable.

Another common slowdown with using opengl for 2d is badly sized textures.
Most cards will either have graphical errors or run slowly if any texture is
not a power of 2 in size (256x256, 512x512 etc). This is not much of a
problem, since you can use scaling of polygons rather than scaling of a
textures pixels in order to make anything look the right size on screen.

Finally, polygon count does matter. If you use tiles and make a giant map,
say, 10,000 x 10,000, and then blit that whole map to the screen, it will
run incredibly slow. You have to be just as careful in opengl on how much
data you pass to the renderer as you would have to watch the number and size
of your blits in sdl.

Lastly, display lists or other batch techniques to limit the amount of
functions python has to call are a must. Python function calls are slow, so
if you are telling opengl to draw each vertex of the entire scene every
frame, it could possibly be slower than the blits would just due to the
python overhead.

I'd like to see what your test was that ran slower in opengl than sdl.
Everything I've done has ran 100-300 fps in opengl versus 40-60fps being
about the max I've EVER seen SDL run anything.

[Ian Mallett]

Hmmm. Well, you seem to be right. I ran the test and OpenGL was faster.
I'm guessing it's my graphics card (I got a new laptop).

Post by Patrick Mullen
Opengl will be slower than sdl on computers with either bad graphics cards
or bad graphics drivers, but in general it is much much faster. On the
order of 10 times faster or more for some things. But you have to code the
opengl way, and not the sdl way.
Directly modifying pixels in a texture is going to be slower than blitting
pixels to the screen, so you will want to use another interface to draw
pixels to a texture and then replace the texture for it to be update on the
screen. If you can find a way to accomplish what you want without changing
or editing textures, it will probably work a bit better. On more advanced
cards you can use pixel rendering functions to offset this issue, but that
is less portable.
Another common slowdown with using opengl for 2d is badly sized textures.
Most cards will either have graphical errors or run slowly if any texture is
not a power of 2 in size (256x256, 512x512 etc). This is not much of a
problem, since you can use scaling of polygons rather than scaling of a
textures pixels in order to make anything look the right size on screen.
Finally, polygon count does matter. If you use tiles and make a giant
map, say, 10,000 x 10,000, and then blit that whole map to the screen, it
will run incredibly slow. You have to be just as careful in opengl on how
much data you pass to the renderer as you would have to watch the number and
size of your blits in sdl.
Lastly, display lists or other batch techniques to limit the amount of
functions python has to call are a must. Python function calls are slow, so
if you are telling opengl to draw each vertex of the entire scene every
frame, it could possibly be slower than the blits would just due to the
python overhead.
I'd like to see what your test was that ran slower in opengl than sdl.
Everything I've done has ran 100-300 fps in opengl versus 40-60fps being
about the max I've EVER seen SDL run anything.

[Ian Mallett]

The test was essentially fill with background color and add a fps counter.

Post by Ian Mallett
Hmmm. Well, you seem to be right. I ran the test and OpenGL was faster.
I'm guessing it's my graphics card (I got a new laptop).

Post by Patrick Mullen
Opengl will be slower than sdl on computers with either bad graphics
cards or bad graphics drivers, but in general it is much much faster. On
the order of 10 times faster or more for some things. But you have to code
the opengl way, and not the sdl way.
Directly modifying pixels in a texture is going to be slower than
blitting pixels to the screen, so you will want to use another interface to
draw pixels to a texture and then replace the texture for it to be update on
the screen. If you can find a way to accomplish what you want without
changing or editing textures, it will probably work a bit better. On more
advanced cards you can use pixel rendering functions to offset this issue,
but that is less portable.
Another common slowdown with using opengl for 2d is badly sized
textures. Most cards will either have graphical errors or run slowly if any
texture is not a power of 2 in size (256x256, 512x512 etc). This is not
much of a problem, since you can use scaling of polygons rather than scaling
of a textures pixels in order to make anything look the right size on
screen.
Finally, polygon count does matter. If you use tiles and make a giant
map, say, 10,000 x 10,000, and then blit that whole map to the screen, it
will run incredibly slow. You have to be just as careful in opengl on how
much data you pass to the renderer as you would have to watch the number and
size of your blits in sdl.
Lastly, display lists or other batch techniques to limit the amount of
functions python has to call are a must. Python function calls are slow, so
if you are telling opengl to draw each vertex of the entire scene every
frame, it could possibly be slower than the blits would just due to the
python overhead.
I'd like to see what your test was that ran slower in opengl than sdl.
Everything I've done has ran 100-300 fps in opengl versus 40-60fps being
about the max I've EVER seen SDL run anything.

[kschnee-SEpB88Xup+CsTnJN9+]

Post by Patrick Mullen
I'd like to see what your test was that ran slower in opengl than sdl.
Everything I've done has ran 100-300 fps in opengl versus 40-60fps being
about the max I've EVER seen SDL run anything.

I loaded up the "rain generator" written by Kamilche and posted here some
time ago, and was startled to see it apparently running at _thousands_ of
FPS. Apparently that's the power of updating only a small part of the
screen per frame, using pygame.display.update([list of dirty rects])
rather than doing the whole screen by omitting the list. For my own needs
I just assumed I needed to redraw the whole screen every frame, but maybe
I can reserve part of the screen for the interface and update that only as
necessary, boosting the framerate some.

[altern]

Post by Charles Joseph Christie II
So, I'm trying to find a single good newbie tutorial for using PyOpenGL for 2D
graphics. I haven't found a single one yet, although I have found a few that
focus on C++. Some people recommended that I take a look at the NEHE
tutorials that were re-coded in python on the python page, but those only go
from 1 to 10. Does anyone know where I could find a good starting point (it
doesn't have to be a super-noobish tutorial, just something to give me
examples on how to start) for using PyOpenGL in conjunction with Pygame for
making something?

hi charles

you might get some ideas from this basic example. Not very impressive
graphics ;) but it touches some basic concepts of how to deal with 2D in
OpenGL. You could avoid using pygame by using GLUT instead but I think
using pygame is much nicer and flexible.

2D using pyopengl with pygame
https://devel.goto10.org/filedetails.php?repname=ixi&path=%2Fpython%2Fpygame_opengl.py&rev=0&sc=0

and in case you are interested on using GLUT
https://devel.goto10.org/filedetails.php?repname=ixi&path=%2Fpython%2Fglut_opengl.py&rev=0&sc=0

good luck

enrike

[altern]

Post by Charles Joseph Christie II
So, I'm trying to find a single good newbie tutorial for using PyOpenGL for 2D
graphics. I haven't found a single one yet, although I have found a few that
focus on C++. Some people recommended that I take a look at the NEHE
tutorials that were re-coded in python on the python page, but those only go
from 1 to 10. Does anyone know where I could find a good starting point (it
doesn't have to be a super-noobish tutorial, just something to give me
examples on how to start) for using PyOpenGL in conjunction with Pygame for
making something?

hi charles

you might get some ideas from this basic example. Not very impressive
graphics ;) but it touches some basic concepts of how to deal with 2D in
OpenGL. You could avoid using pygame by using GLUT instead but I think
using pygame is much nicer and flexible.

2D using pyopengl with pygame
https://devel.goto10.org/filedetails.php?repname=ixi&path=%2Fpython%2Fpygame_opengl.py&rev=0&sc=0

and in case you are interested on using GLUT
https://devel.goto10.org/filedetails.php?repname=ixi&path=%2Fpython%2Fglut_opengl.py&rev=0&sc=0

good luck

enrike

[Richard Jones]

Post by Simon Wittber
If you're after brain dead simple 2D OpenGL functions only, try gfx.gl
in the GFX package. (http://cheeseshop.python.org/pypi/GFX).

Yep, and pyglet is intended to provide windowing, input, music, sound, video, etc. It has some "extensions" already that are in various states of completion (none of them quite ;) which do "sprite and tilemap" graphics, XHTML layout, GUI, etc. The emphasis is on pure-python implementations (as it is with pyglet itself) so if you could (ie. you can compile or ship binaries for your target platforms) you'd use something like GFX for faster-than-pyglet graphics.

Except, of course, that pyglet's not actually officially released yet ;)

But fundamentally, GFX* is just using a GL context, and pygame and pyglet both provide one of
those.

Quick, untested translation of Simon's example to pyglet:


1 from pyglet import window, image
2 from gfx import gl
3
4 w = window.Window(800, 600)
5 gl.init((800,600)) # I assume this is just setting up a projection :)
6
7 im = image.load('ball.png')
8 texture_id = im.texture.id
9 w,h = im.width, im.height
10 while not w.has_exit:
11 w.dispatch_events()
12 gl.draw_quad((0,0),((0,0),(0,h),(w,h),(w,0)), texture_id=texture_id)
13 w.flip()


Note that the gl.draw_quad could be done with "im.blit(0, 0)". A speed comparison
would be interesting :)


Richard

*: I've also noticed http://cheeseshop.python.org/pypi/Rabbyt which has just popped up recently...

[Luke Paireepinart]

[snip other stuff not relevant to me teasing Richard]
But fundamentally, GFX* is just using a GL context, and pygame and pyglet both provide one of
those.
1 from pyglet import window, image
2 from gfx import gl
3
4 w = window.Window(800, 600)

w is window here...

5 gl.init((800,600)) # I assume this is just setting up a projection :)
6
7 im = image.load('ball.png')
8 texture_id = im.texture.id
9 w,h = im.width, im.height

and, whoops, you reassigned it to the width here :D
Good thing this isn't *tested* code or I'd be wondering about you,
Richard ;)

11 w.dispatch_events()
12 gl.draw_quad((0,0),((0,0),(0,h),(w,h),(w,0)), texture_id=texture_id)
13 w.flip()

I was confused as to how you were flipping an integer... 2s complement? :D
-Luke

[Richard Jones]

Post by Luke Paireepinart
I was confused as to how you were flipping an integer... 2s complement? :D

I was just being rude :)


Richard