You are free to take ideas from my code and I'll be happy to give you feedback as your module progress.
Le vendredi 8 juillet 2016 00:54:43 UTC-4, Benjamin Moran a écrit : > > 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.
