I've been a little busy, so I figured I'd share the simple shader program class I wrote a week or two ago. I've been mostly poking around with the rest of the graphics module these days, which is quite a beast (but impressive piece of software!). The shader code can be found in this branch: https://bitbucket.org/treehousegames/pyglet/src?at=shader_class There is a new pyglet.graphics.shader.py file, and a new examples/opengl_core.py file.
It's already "useable" if you want to feed it your own ctypes.Structure's, but idealy support will need to be added to the existing vertex_lists and VBO classes. shader.py is obviously not finished code, but I would appreciate any comments on the general layout and structure of it. Does it make sense to have the shader programs compile and link as they do, in the __init__ section? Are there any glaring omissions? The VAO stuff in specific is going to need to be handled in the general graphics module, but maybe it would also make sense to have some simple methods to handle that in the shader class. Thanks everyone. On Saturday, February 27, 2016 at 12:59:30 PM UTC+9, Benjamin Moran wrote: > > Hi guys, > > I have a ShaderProgram class in a working state, which supports only > vertex/fragment shader programs for a first step. OpenGL 3.0 and 4.1 > contexts work, and it's Py2/3 compatible. > > Currently there is code in there to create a VBO and VBA, which should be > moved out eventually. It currently only works by feeding it vertex data > from a ctypes.Structure, so it's not exactly user friendly at the moment. > > My next step is to work on pyglet.graphics.vertex_list, and see if I can > enhance it to create vertex lists that are compatible with the OpenGL core > profile. Basically, just to be able to feed it vertex data and display some > shapes without ctypes. Once I get this going I'll post a link to my fork > and ask for feedback/assistance. > > > > On Sunday, February 21, 2016 at 6:35:06 AM UTC+9, Serdar Yegulalp wrote: >> >> I'm happy to try and test things out in my own apps as the changes are >> rolled in. I've got 3-4 apps using Pyglet now that would make a good test >> bed for this sort of thing. Things do work in the meantime, but I agree >> that modernizing iks going to be the way to go. >> >> I think it would make sense to have some kind of default shader that is >> passed on window creation which can be overridden, or toggled off entirely. >> I have one app in the making that uses multiple shaders -- some for 2D (for >> color-cycling effects, etc.), some for 3D, so being able to override >> something like that would be a must. >> > -- 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.
