Things have slowed down towards the pyglet v1.3 release (mostly tiny fixes now), so I've been hacking on my GL3+ fork recently. I made a bit more progress. Most of my original ideas turned out to be possible, so I've managed to get pyglet running on (currently) OpenGL 3.3, with the existing API unchanged. The Sprite module now works as intended, with all attributes working as they did before. Basically, the SpriteGroup has a very simple shader with the needed attributes to mimic the old behavior. Going forward, we could probably move the scaling and rotation parts of the Sprite class inside the shader to save a ton of CPU. Setting the sprite rotation, etc. would just need to update a single uniform and let the shader do it, rather than wasting CPU resources. For now, however, my goal is just to get things working. So what's left?
1. I *think* my Shader and ShaderProgram classes are reasonably designed, but they might need a rewrite. They work for now. Better shaders will definitely have to be written, by someone who knows what they're doing :) 2. The text module hasn't been touched yet. This will need tweaks to get working. 3. The image and graphics modules will need a going over. 4. Proper exceptions will need to be written for some things. 5. The IndexedVertexDomain has serious bugs! Needs to be fixed. #5 is a big one. I discovered the IndexedVertexDomain has bugs with deleting vertex_lists. The GL3+ branch uses indexed drawing because of the switch from QUADS to TRIANGLES, so this needs to be fixed. The alternative is to just use standard drawing without indexing, but this would create a lot of needless index data to be written everywhere. On Monday, June 5, 2017 at 12:50:31 AM UTC+9, Benjamin Moran wrote: > > Hi all, > > This thread is to discuss migrating pyglet to an OpenGL 3+ core profile at > some point in the future. The cons are losing support for (what is now) > very old graphics hardware. The pros are many, but include allowing usage > of modern shaders and OpenGL features. We would want to keep pyglet usable > without any OpenGL knowledge, which would mean a set of basic shaders that > mimic the current functionality. > > I've already hacked on my personal branch of pyglet to see if this is > possible while keeping with the current pyglet structure, and I think it > might be. I'm no OpenGL expert, but I think the following ideas will work: > > 1. Each Batch encompasses one VAO. > 2. Each Group can contain shader programs. > 3. The current default Group, which is a NullGroup, will instead > contain a basic shader program. > 4. The pyglet.graphics module remains the same. The default shaders > will contain attributes that match the expected names. > 5. If you wish to use your own shaders, and wish to use the > pyglet.graphics.attribute clases, you must use the same attribute names > (as > these are hardcoded in the module). > > I've already tried this, in that I hacked the pyglet.graphics module to > work with OpenGL 3+. This means vertex lists and batches both work, and you > can create and draw primitives just like normal. The Sprite module is also > working, but is broken because the current default shader is too crude to > handle texture data correctly. It's just a proof of concept at this stage. > You can find my fork here: > > https://bitbucket.org/HigashiNoKaze/pyglet/branch/shaders > > > > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
