Like this:

I’ve been working quite heavily on PyGLy for the last few weeks and I’m incredibly pleased to announce that PyGLy is now OpenGL 3 clean!

It took more work than I hoped. Not because of PyGLy (it was already pretty good), but Pyglet’s OpenGL Core (3+) support on OS-X, is well… broken.
I had to integrate a patch written by someone else and patch out 2 of the window event handlers.
The main reason for this is that OpenGL Core on OS-X is limited to 3.2, and is Core only (no legacy compatibility).
These changes can be found in my Github repository.

Pyglet isn’t without it’s problems. It is quite heavy weight in places. There is no support for float or 1D textures.
Other problems are it’s usage of legacy calls. These are scattered throughout the code base and prevent me from using even the Label or VertexList classes.
I would LOVE to help with the development of Pyglet… but I find the code… very confusing.
It’s got a fair amount of abstraction. Tracing even a vertex buffer blows my mind.

“Framework” is an important word there. PyGLy does not force any one methodology on you. PyGLy simply provides functionality to wrap common functionality. Windows, Viewports, Scene Graph Nodes, Cameras. It’s up to you to put them together how you want.

Obviously some things are going to be coupled together. But for the most part, PyGLy just gets out of the way.

At the moment PyGLy is quite small, but it is in active development and already has features that may interest some.

I think the best case for it at the moment is for people wanting to rapidly prototype in 3D but not be abstracted from the rendering process. PyGLy lets you forget about the scene graph and just concentrate on rendering your objects. Rendering is performed via callbacks. You can make any OpenGL call you want in these callbacks.

PyGLy is the foundation of our Python 3D work, so expect it to be actively developed going forward.

The following are some of the things that we’re wanting to add in the future:

The pyglet application event loop dispatches window events (such as for mouse and keyboard input) as they occur and dispatches the on_draw event to each window after every iteration through the loop.

So every mouse move (or any other event) triggers Pyglet to call “on_draw”.

But because I’m controlling my own render loop at 60Hz, I didn’t see a need to hook into this event. So I assume Pyglet is attempting to render the scene itself, and it’s failing miserably.

This is really bad design! What if I have lots of events that are seperate? Looks like Pyglet is going to hammer the “on_draw” event.

The Solution?

Well the basic solution is to ensure you’ve hooked into the “on_draw” event and just connect it to your render call. Don’t connect it to your game update logic or you will end up updating everything.

But…

This means your frame rate will vary depending on user input, and may even end up running balls out. Which could turn a simple game into a system hog. My basic application goes from 1% (of 2 cores on a dual core system), to 20% with the mouse moving.

It also means that you need to decouple the rendering from the system update, as each event you have scheduled will trigger an “on_draw” event. If you don’t decouple them, you will render each frame twice!

The Proper Solution?

We need to over-ride the “EventLoop.idle” method as mentioned in the docs.

The “on_draw” function also calls pyglet.window.flip() for us, so now we need to do that after our rendering. So add the following (obviously you need to change the window variable depending on what you’ve called it):

This discussion on the developer list explains it. This method only works when the platform’s window class has an existing method to handle the event. And not all events are handled by default, so when you come across this, BOOM!

Even then, when it works this is also a double edged sword. The existing handlers are there for a reason! For example, if you over-write the on_resize method of Window your application will no longer draw (took me a while to figure this out).

So yes, Pyglet’s documentation is really, REALLY, asking for trouble.

The Proper Solution?

Use the “push_handlers” method.

Pyglet automatically detects a method with the event’s name and dispatches the event.
So we can just add methods to our class and we’ll automatically receive the events.

Share

Like this:

About Us

Twisted Pair are an independent development team that have been playing games since the days of monochrome monitors and 5 1/4" disks. Having many years of commercial programming in various areas, including experience in the games industry, Twisted Pair are well versed in game technology and gameplay design and development.

Twisted Pair is dedicated to the following goals:

Create games we would actually love to play.

Create games you would actually love to play!

Produce quality software and provide long-life support and post-release enhancements.

Create and promote a community that participates in and actively shapes the development of our software.

Communicate frequent updates and actively seek feedback and suggestions that will shape the development of our software.