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.
