Thanks for the lengthy writeup, Josh. It seems like this is one of those issues that has no "perfect" solution. I was able to find the code you shared before, and it looks like a nice bit of work. Do you still have an active branch of this somewhere? I'm also curious what your experience with glDrawArrays vs glDrawElements is, performance wise. Most of the talk on the subject is pretty old, so I'm wondering just what the differnce really is.
Not breaking code would be ideal. I think as long as there are fallbacks (even if slow fallbacks) would be a requirement, so as not to regress in functionality. Additionally, not to impose any behaviour that would negatively affect people who don't even use the sprite class at all. On Monday, October 3, 2016 at 4:30:07 AM UTC+9, Josh wrote: > > Hi all, > > Been a while since I dealt with this, but here is the core of the solution > I came up with. Currently VertexDomain uses glDrawArrays to render sprites. > This requires the correct texture for each sprite has to be bound before it > can be rendered. So if you have, say, 100 distinct images being rendered as > sprites, that's (usually) 100 glDrawArrays calls per frame. Also, all > sprites sharing a texture are always rendered simultaneously if they belong > to the same batch. > > To solve this problem, I created a new method draw_ordered for > VertexDomain that uses glDrawElements. This allows you to pass a list of > indices that specifies the order the elements will be rendered in. However, > because you have to choose one texture to have bound before calling > DrawElements, everything in the domain still has to have a common texture. > So to make this solution work,* all sprites in a batch must take their > textures as regions from a single master textur**e *(in pyglet, > TextureAtlas was convenient for this; it automatically sets the texture > coordinates for the sprite vertices correctly). > > I still think the huge gains in efficiency make it worth changing to > glDrawArrays. To make it work with the existing pyglet framework, I created > a new rendering hierarchy in parallel with the existing pyglet methods: > OrderedBatch, OrderedSprite, AtlasAnimation, AnimationRegion. But a better > solution would be to have a singleton TextureAtlas. Getting images through > the pyglet resource tools would automatically enter them in the singleton, > and most users would not have to worry about the change in rendering > method. But definitely some code would break. > -- 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.
