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 pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to