I would be very interested to see these changes and additions to test out.

One thing with the texture atlas containing everything, many graphics cards 
have max texture size limits, would a change like this cause problems then?

On Monday, October 3, 2016 at 3:17:08 PM UTC-5, 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