[visionegg] Re: pyglet vs. pygame

  • From: Martin Spacek <visionegg@xxxxxxxxxxxxx>
  • To: visionegg@xxxxxxxxxxxxx
  • Date: Tue, 01 Jan 2008 20:22:05 -0800

OK, I just made some commits. The first one removed a duplicate definition for set_gamma_ramp() which was being overridden anyway by a second definition.

The second commit added a VisionEgg.Window class which inherits from VisionEgg.Screen, except it doesn't depend on pygame. It has a .win attribute, which is its associated pyglet window. It might be better to do multiple inheritance from both VisionEgg.Screen and pyglet.window.Window, so that all of the pyglet window's attribs would be part of the VisionEgg.Window attribs. However, that would either force everyone to install pyglet, or would probably require putting the code for pyglet stuff in a separate module that could be optionally imported.

You should normally use VisionEgg.Core.get_default_window() to create a window based on your VisionEgg.cfg

There's also a pyglet_Viewport class which is used with Window in place of the normal Viewport class which is used with Screen.

The third commit added two pyglet demos that should clarify how to use the Window and pyglet_Viewport objects. One of the demos also shows pyglet event handling.

I've only tested in winxp.

Everything is oh-so-easy in pyglet, but things aren't completely seamless yet. In the def for VisionEgg.Window, I left code copied from VisionEgg.Screen that I didn't want to deal with commented out. Two things that don't work yet are frameless windows and gamma correction.

Also, since the Presentation class expects pygame screens and viewports with .screen attribs, Presentation loops don't work. It wouldn't take much code change, but I only ever use custom loops anyway.

Andrew: I'm not sure how to best organize the code so that both pygame and pyglet can be used throughout. Perhaps it would be best to make a decision at some point to completely switch to pyglet and dump pygame? Maybe make a branch? It would be nice to switch from pyopengl to pyglet's opengl calls as well. Then visionegg would only really depend on numpy and pyglet :)

For now, I've gotten what I need out of this foray, namely multiple windows with simultaneous mouse-controlled stimuli. I haven't tested precise frame timing, because I don't need it in this case.

Let me know how it works for you!


Andrew Straw wrote:
Hi Martin,

Certainly I agree that pyglet looks like a contender to replace pygame. I think that the multiple screen/window option is potentially a killer feature for us. My best guess is that it wouldn't be too much work to use it -- as far as I can tell, simply initializing the Screen instance using pyglet rather than pygame should be sufficient to test the water. Initially, I think we can probably keep using PyOpenGL (pyglet wraps OpenGL, too), although I'm certainly interested in some of pyglet's higher-level OpenGL texture management stuff -- if the VE used that, some of the Vision Egg's more hairy code could be eliminated. The pygame event handling would have to be ported, too, but I don't think that would be too hard.

I'm actually planning on poking around pyglet's code base a little more in the next week or so. I should have some more informed opinions then. I must admit that my immediate goal for pyglet is for another project (my wxglvideo module), but obviously anything I learn could be applied to VE. Nevertheless, I'm not planning on doing anything along with VE and pyglet in the immediate future simply due to time constraints.

If you want to attempt at a port, my best guess is that re-writing the Screen class to use pyglet rather than pygame should be just-about-sufficient to get a proof of concept done. (Also, swap_buffers will have to be done, but that's a one-liner, I guess.) Hopefully the multi-screen planning I did back in the early days of VE will make actually supporting multiple screens easy. You'd initially want to ignore the get_default_screen() stuff and just simply hand initialize screens with the values you know you want -- 99% of the stuff in Screen is purely used at initialization and if it's missing, most of the rest of VE would never miss it. Doing things like creating reasonable default values and setting look up tables could be done later.

Keep us posted,

The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: