Minimum OpenGl Version

[Jason Spashett]

Hello,

I have been trying to find the minimum OpenGL version requirement for pyglet but can't seem to see it at the moment, it must be in some obvious place though. Can anyone enlighten me?

Thanks,

Jason.

[Benjamin Moran]

I really don't know either, but it doesn't seem to use anything higher than 2.0 for the built in abstractions. You're free to use anything higher of course if you would like to access opengl directly.

Personally I would like to see the sprite and other classes take advantage of modern opengl. Maybe 3.0 would be a good minimum target. It's new enough to take advantage of modern GL programming style, but still almost 8 years old.

-Ben

[Jason Spashett]

I have a use for pyglet that might see it run on older versions, so I just wondered what the minimum was. It would be for service menus and tests on betting machines.

Spites are presumably using VBO's already, what things in OpenGl 3 would make pyglet better? I presume that pyglet is still oriented towards to the 2D side of things, so its handy that it does run on older OpenGl versions. 

World of goo used opengl 1.4ish because that was all that was required, although that is an older game now, you can still do all you need to in a 2D game with the minimum OpenGL versions.

Most people lynch you these days if you say you want to use immediate mode OpenGL, but there is no real argument for using the new way of things for a 2D game, until eveyone has an OpenGL 3 card, but perhaps that is nearly the case. I'll have to throw away my old laptop that has an Intel GMA 945 on it.

[Benjamin Moran]

I've nothing against immediate mode OpenGL, but I've been comtemplating the possibility of using shaders for handing the vertex calculations and other such math that's done in pure Python now. Pyglet does work great as it is, but the sheer number of calculations kills it when trying to do a few thousand sprites at once. A lot of this can be aleviated by rolling your own classes, but It would be nice if things were more performant out of the box.  I was thinking of the default sprite classes having just simple position, velocity, depth values with the calculations done by a default set of shaders. It would also open up the possibility of creating a handful of additional optional "modern 2d" effects via additional shaders, that inexperienced users could use blindly.  Maybe this could be done with 2.0 shaders, but they are really limiting compared to 3.0.

These are just thoughts at the moment. I don't have the time to do this right now, and I've not idea how the developers feel on the matter. I'd imagine 2.0 level OpenGL support isn't going anywhere for a while.

[Leif Theden]

Off the top of my head, I think you could use just the pyglet opengl bindings, (no sprites) with opengl 1.4.  That was a long time ago, though and I haven't touched hardware that old in a long time to test if that is still true.  AFAIK, there is no GUI library for pyglet, so if you plan on doing that, you'll certainly be doing a lot of manual work there.

Ben, currently, pyglet sprites have some real performance issues mostly because of the way math is used.  Any change to X, Y, Scale or Rotation will trigger the vertex updates.  When most programmers will do something like the following, it causes excessive CPU use:

  for sprite in sprites:

    sprite.x += dx

    sprite.y += dy

    sprite.rotation += dr

So for each sprite, the math update was triggered 3 times, when ideally it would have been done just once.  Its an issue that needs documentation, or new API, or perhaps smarter checks to do the math when needed, instead of on each attribute modification.  Shaders would be nice, but pyglet developers are few and far between...it would possibly require more upkeep than the community can cope with to maintain shaders with the moving target that GPU shader programming is (just my thoughts on that).

IMO, a better solution to slow sprite math would be an optional 'pyglet acceleration library' written in cython to handle the math.  Less burden on the developers to maintain compatibility with OS drivers. 

[Jason Spashett]

On Thursday, 12 November 2015 17:39:28 UTC, Leif Theden wrote:

AFAIK, there is no GUI library for pyglet, so if you plan on doing that, you'll certainly be doing a lot of manual work there.

It going to be a simple industrial style GUI with big buttons and some screens, and no windows, on a touch screen, with a little 'pretty' added in with some tests. That's the way the shop floor likes it. Might not end up using pyglet, but it's a good candidate for what the 'client' wants to do. Besides, Sublime text managed it to great effect, in a surprisingly simple way, apart of course from the text rendering which is another story.


Shaders could be used of varying version for different cards with fallback for Sprites. It might be a good way of building a base by which to introduce more shader goodness at a later day, with an eventual transition to OpenGL 3.2+ in a similar way to Orge3d does with it's "techniques" (or used to do when I looked last). But as you say probably needs a few more people to work on that sort of thing.

 

 

[Benjamin Moran]

I suppose if the existing Sprites are kept as a fallback, it would make a lot of sense to optimize them. (Sorry Jason for deraiing the thread. Maybe this should be moved to a new discussion).

Leif, what you've pointed out is totally correct. I was bit by that on my first test of pyglet. Switching to a single set_position call resulted in a doubling of performance. I've had some ideas for refactoring the Sprite class. All calls to _update_position would be removed, and x/y/position/scale/rotation would become simple attributes. The self._vertex_list.vertices addtibute would be hidden behind a @property, which would call the _update_position method "on demand", whenever the vertices are checked. This would have the added bonus of increasing access speed to all Sprite attributes, because they wouldn't need to be accessed through properties.

I'm not sure if this is possible because of the way the batching works (I've not studied that code yet), but it seems to me that there really should be direct access to the common Sprite attributes in either case.

-Ben