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.
