Thanks for your insite with regards to DrawArrays/DrawElements. There is a lot of old bickering online about how one or the other is "better", but not so much recent discussion.
I think having the separate implementation of these things is a good idea for a start. I don't think anyone would want to have two seperate implementations side by side in the long run, but it's nice to compare side by side. I think you've already worked out most of the messy stuff, so it would be a matter of seeing if this implementation is feasable if we add in some fallbacks to keep things simple. For example, pyglet is really fast if you use a batch, and rely on the resources module to load your images. It still works fine, however more slowly, if you are ignorant of that and load all of your textures manually. I have other things on my plate at the moment, but if you're keen to help make this happen we could open a new branch to experiment in. Let me know what you think. On Tuesday, October 4, 2016 at 5:17:08 AM UTC+9, Josh wrote: > > 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.
