next »

[cmspice]

Pyglet http://pyglet.org/ is a python graphics library intended for game development. Here's what I've concluded so far after glossing at the documentation. Making comparisons to pygame which I've spent a good amount of time with.

-Written in python. Best language ever (biased).

-Uses opengl, this means fewer dependencies, and better performance. Pyglet is designed primarily for 2d games using hardware acceleration. Pyglet still allows for native opengl calls so it's just as readily useable with opengl much like how one would use SDL with opengl.

-Basic functionality is very easy to use, hiding all the nasty opengl stuff. For example, loading and displaying an image are all one line calls with many of the bells and whistles that pygame has (like get_region()).

-Offers an event system for about 30 different events (including keyboard, mouse, timers, etc)

-In older versions, one would instantiate an window.Window class and override the main_loop() function and control all looping manually. Events are handled upon calling the dispatch_events() functions and one can follow that up with update and draw cycles all in the main loop.

-Newer version encourages and entirely event driven paradigm. Program blocks on pyglet.app.run() and user code should go in event functions like on_draw(). This is optimised for performance as functions are only called as needed.

The documentation for the event driven paradigm is a little poor but I'd imagine its comparable to AS3. I'm much more used to programming the former way, managing the main loop manually. I'm trying to figure out how to schedule timer events and what happens when framerate drops. I'll report as I find out more.

[Pishtaco]

I messed around with pyglet for a 3d game (as a beginner with both opengl and python). In the end I found the opengl stuff a bit frustrating. Using pyglet is close enough to using opengl that you have to understand how opengl works to do it, and in particular you need to read the opengl documentation because the pyglet documentation only covers a little of it. But then pyglet does some things a bit differently from opengl, and suddenly you're lost as to how they work. For example I'm still a bit mystified about all the stuff about rendering sprites in "batches". It looks like this is to do with making fewer opengl draw calls; but how, exactly? And I spent a lot of time trying to work out how pyglet's vertex array things are related to things described in the opengl documentation. Maybe the docs have improved now.

There was also some weirdness with vsync and jerkiness in the built in game loop that I never got to the bottom of.

[george]

For example I'm still a bit mystified about all the stuff about rendering sprites in "batches". It looks like this is to do with making fewer opengl draw calls; but how, exactly?

It's because OpenGL is state-based -- pyglet sorts batches so you make fewer state changes in between drawing. The more state changes you would make, the less efficient it would be.

The documentation for the event driven paradigm is a little poor but I'd imagine its comparable to AS3. I'm much more used to programming the former way, managing the main loop manually. I'm trying to figure out how to schedule timer events and what happens when framerate drops

I started off with pygame too and after working with pyglet a bit I much prefer how it handles events. Things end up clearer IMO. I'm curious what your experience will turn out to be. Regarding timers, the pyglet convention is to set up a timer and pass dt to the function you're calling; if framerate drops all of the functions in the game will slow down correspondingly; of course this isn't the only way to handle that issue but as a beginner to programming myself I found this easy to understand.

[cmspice]

I started off with pygame too and after working with pyglet a bit I much prefer how it handles events. Things end up clearer IMO. I'm curious what your experience will turn out to be. Regarding timers, the pyglet convention is to set up a timer and pass dt to the function you're calling; if framerate drops all of the functions in the game will slow down correspondingly; of course this isn't the only way to handle that issue but as a beginner to programming myself I found this easy to understand.

So one can set up a timer to trigger ever X ms and X gets passed in as dt unless the framerate drops in which case dt will be larger than x? I'm used to doing everything at a fixed framerate and using frames as a unit of time. Anyways, I guess that does make sense now that I think about it a bit. I've trained myself into too many rigid habits.

I'm going to  start messing around a bit with pyglet today. The ultimate goal is to make a game that uses these full motion video sequences with a tacky retro look. To get transitions seamless, I've dropped the framerate to about 10 fps (which just makes it look all the more retro). I still have my qualms about how video codecs work and with such an imminent deadline (gamma4, jan 31) I'd rather stick with something I trust more. In this case, that means a lot of images! A whole freaking lot of them. It's going to be pretty awesome. I started off yesterday by loading and drawing images as fast as possible in pyglet, It goes pretty fast, the video plays at well over 1x speed (edit: I get 90 fps on a pretty slow laptop) loading and drawing one 320x240 resolution image each frame.

[cmspice]

as mentioned in his interview http://www.pygamesf.org/?p=101 pyglet does a pretty terrible job with audio and in addition needs users to have avbin installed on their machine (for linux at least). I could not seem to get an mp3 to play properly (it just made noise) so rather than mess around I just used the pygame sound library instead. There seemed to be no conflict. I can even instantiate a pygame window along with the pyglet one. Multiwindow game anyone??  (actually pyglet lets you instantiate multiple windows anyways) It's probably better to use some other audio library without the overhead of including all the uneeded parts of pygame but time is of interest and it works good so I'm sticking with it.

To do this, with pyglet or any other python script (or cpp if you want to use sdl as a simple audio library) simply initialize pygame without establishing a window and use the mixer module. One could do this with many of pygames other modules as well.

e.g. place this somewhere in your script

import pygame
pygame.init()
pygame.mixer.music.load("music.mp3")
pygame.mixer.music.play()

again a disclaimer here this is a pretty stupid thing to do but it's also not that stupid and works here in interest of time.

[FatHat]

Pyglet is pretty neat, although it has a lot of rough edges that are really annoying. The main one that's bugging me is that sprites convert their x/y coordinates to integers instead of keeping them as floats. That's fine if your scale is 1:1 with pixels, but it's horrible when you zoom in and you see things jump.

Also, I noticed using batches can actually slow things down sometimes. I'm getting better performance with glBegin/glEnd calls than I was using batches, which is really surprising to me. Might be a driver issue though.