Thanks for the link, I haven't seen your library yet. Very nice work! I like how you've done the automatic setter and getter creation. It's also nice to have the ability to share shader resources (owned or not) between multiple programs.
I was hopething that pyglet would get it's own shader class, so I think my goals are a little different. I'm trying to make it as simple as possible, while being usable for basic shader programs. Because of that, I was thinking that the ShaderPrograms would be self contained. It also needs to be Py2/3 dual compatible for now, since pyglet is supporting both. I'm not yet sure how to handle the pre-3.0 shaders. My example code is using vertex arrays, but I'm not sure if it's worth handling < 3.0 shader programs or not. If you don't mind, I may take a few ideas from your code. I'd also be happy to hear your feedback or if you want to work on this. -Ben On Friday, July 8, 2016 at 10:47:39 AM UTC+9, [email protected] wrote: > > I created a small shader library for pyglet. You might want to take a look > at it: > https://github.com/gabdube/pyshaders > > Le mercredi 1 juin 2016 03:55:37 UTC-4, Benjamin Moran a écrit : >> >> I opened up a pull request for my simple ShaderProgram class I worked on >> a few months ago. This is likely not suitable for merging in it's current >> state, but I wanted to potentially spark up a bit of conversation on what >> should be added/changed/modified/removed. The pull request is here: >> https://bitbucket.org/pyglet/pyglet/pull-requests/24/shader_class/diff >> The changes consist of two new files, so you could just copy/paste those >> into a local directory for playing around with. >> Feel free to express your horror at what you see. It's obviously not >> finished :) >> >> ------------------------------------------------- >> The rest of this post are just some thoughts I've been having with >> regards to modern OpenGL and pyglet: >> >> When playing around with shaders and pyglet, some things come up: If you >> use a newer OpenGL context, you have to give up all the nice pyglet >> graphics classes and roll everything yourself. This is fine for advanced >> use cases, but it's a huge drawback not being able to take advantage of the >> awesome pyglet batches and other niceties. Using an OpenGL 3.0 context >> bridges the gap, but of course this doesn't work on OSX (and old functions >> are not even guaranteed to be available anyway by the spec). Looking >> towards to a possible future where it might become necessary to support >> OpenGL Core profiles, some thoughts are: >> >> 1. Fill the code base with a bunch of "if context > 3.0" statements and a >> ton of duplicated methods for legacy and core OpenGL. >> 2. Re-write the necessary pyglet classes to use the OpenGL Core profile, >> including a default set of basic shaders that mimic the current >> functionality. >> >> Option 1 seems foolhardy. Option 2 might be the best way to go. Perhaps >> this timeframe would tie in with the eventual end of life for Python 2.x in >> 2020. Dropping both Python 2 and legacy OpenGL at the same time would allow >> a nice refresh. >> >> -- 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.
