Sorry for the delay! How would you prefer to move forward on this? Would you prefer me make a branch that you could clone, or just clone to repo and start your own branch for now?
On Friday, October 14, 2016 at 12:05:55 PM UTC+9, Josh wrote: > > I'd be willing to give it a shot. > > On Tuesday, October 4, 2016 at 9:03:57 AM UTC-5, Benjamin Moran wrote: >> >> 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.
