I have the code with some bug fixes from after I sent it to you. It's not in a public repository right now but I can put it somewhere. It's still not thoroughly tested, it just worked for my project.
Call for call, I think there isn't much difference between DrawArrays and DrawElements (or if there is, it's on the GPU side). The huge advantage of DrawElements is that you can render your entire game with just the one call, and do it in whatever order you want. In current pyglet, when you call batch.draw(), pyglet makes a separate DrawArrays call for each separate texture that needs to be rendered. What if we subclass VertexDomain with OrderedVertexDomain, create a ZSpriteGroup class, and create a ZSprite class? That keeps backwards compatibility. ZSprites would be initialized with a fixed ZSpriteGroup. Unlike normal groups, ZSpriteGroups would maintain a TextureAtlas, a sorted list of indices, and an OrderedVertexDomain, and would not allow children. Batch methods would be modified so the batch always associates a ZGroup's domain, and only that domain, with that group. This requires changes to Batch.migrate, Batch._get_domain, Batch._add_group that explicitly check if a group is a ZSpriteGroup. On Monday, October 3, 2016 at 5:02:59 AM UTC-5, Benjamin Moran wrote: > > 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.
