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 post to this group, send email to
Visit this group at
For more options, visit

Reply via email to