zsprites, or sorting sprites with the z buffer
516 views
Skip to first unread message
Benjamin Moran
Oct 2, 2016, 1:48:44 AM10/2/16
to pyglet-users
Hi guys,
This is something that comes up pretty often. Users looking for a z value on the sprites, allowing easy depth sorting without needing to use the OrderedGroups.
At first this seems easy to add to the existing sprite class, but unfortunately translucent sprites (sprite.opacity) do not blend together correctly if you simply add the additional z vertex. This page on the OpenGL wiki explains the issue in some detail: https://www.opengl.org/wiki/Transparency_Sorting
I have a branch here, which has the bare minimum added to get z sorting working: https://bitbucket.org/treehousegames/pyglet/branch/z_sprite
Translucency (sprite.opacity), however, does not work correctly. Only pure transparency (100% invisible) works, which is enough for some cases but not all. The only change made outside of the Sprite module is to the Window.on_resize method, which changes the z range from (-1, 1) to (-255, 255). This is so that if you're NOT using subpixel sprites, then you can use whole numbers for the z value and not have them clamped to ints.
Ideally, it would be nice if the current sprite API and operation could be kept, but I'd love to hear you guys thoughts on this.
This is something that comes up pretty often. Users looking for a z value on the sprites, allowing easy depth sorting without needing to use the OrderedGroups.
At first this seems easy to add to the existing sprite class, but unfortunately translucent sprites (sprite.opacity) do not blend together correctly if you simply add the additional z vertex. This page on the OpenGL wiki explains the issue in some detail: https://www.opengl.org/wiki/Transparency_Sorting
I have a branch here, which has the bare minimum added to get z sorting working: https://bitbucket.org/treehousegames/pyglet/branch/z_sprite
Translucency (sprite.opacity), however, does not work correctly. Only pure transparency (100% invisible) works, which is enough for some cases but not all. The only change made outside of the Sprite module is to the Window.on_resize method, which changes the z range from (-1, 1) to (-255, 255). This is so that if you're NOT using subpixel sprites, then you can use whole numbers for the z value and not have them clamped to ints.
Ideally, it would be nice if the current sprite API and operation could be kept, but I'd love to hear you guys thoughts on this.
Josh
Oct 2, 2016, 3:30:07 PM10/2/16
to pyglet-users
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 texture (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.
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 texture (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.
Benjamin Moran
Oct 3, 2016, 6:02:59 AM10/3/16
to pyglet-users
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.
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.
Josh
Oct 3, 2016, 4:17:08 PM10/3/16
to pyglet-users
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.
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.
Benjamin Moran
Oct 4, 2016, 10:03:57 AM10/4/16
to pyglet-users
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.
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.
Josh
Oct 13, 2016, 11:05:55 PM10/13/16
to pyglet-users
I'd be willing to give it a shot.
Benjamin Moran
Oct 17, 2016, 8:59:02 AM10/17/16
to pyglet-users
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?
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?
Charles
Oct 18, 2016, 6:45:39 PM10/18/16
to pyglet-users
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?
Benjamin Moran
Oct 19, 2016, 2:23:40 AM10/19/16
to pyglet-users
I think the ideal method should be how it works now, whn using the pyglet.resource module. Things are packed together as much as possible, but it should still be able to function normally if you create your own textures or texture atlases. It would be slower of course, but I think it should at least work.
I've been reading up on various order independent transparancy techniches, such as the one described in this blog: https://mynameismjp.wordpress.com/2014/02/03/weighted-blended-oit/ There is a link to the original PDF there as well.
All very interesting stuff. The impression that I'm getting is that transparancy is not really a solved issue in the OpenGL world.
I've been reading up on various order independent transparancy techniches, such as the one described in this blog: https://mynameismjp.wordpress.com/2014/02/03/weighted-blended-oit/ There is a link to the original PDF there as well.
All very interesting stuff. The impression that I'm getting is that transparancy is not really a solved issue in the OpenGL world.
Josh
Oct 20, 2016, 7:29:08 PM10/20/16
to pyglet-users
I cloned the repo, working on a Zsprite branch.
Benjamin Moran
Oct 21, 2016, 4:43:14 AM10/21/16
to pyglet-users
If it's a public fork, it works be great if you could share the link.
Josh
Oct 23, 2016, 6:49:23 PM10/23/16
to pyglet-users
Hi, sorry I've been out of the loop a few days. I put the fork on bitbucket, https://bitbucket.org/clockmarket/zsprites
Josh
Oct 23, 2016, 8:54:24 PM10/23/16
to pyglet-users
Got up to the initial test working. Animations are NOT supported right now. Batches are not supported and there's really no point in supporting them with this pipeline. The basic method for rendering sprites that you want to have sorted is:
Note that sprites are bound to their group, and can't be migrated between groups. Each sprite has a depth attribute that controls rendering order. There is a self-contained test depth_sprite_test.py. Appreciate anyone who who can give it a shot!
- Josh
group = pyglet.sprite.DepthSpriteGroup(2048, 2048) #the size of the texture atlas
#load some image as img
my_sprites = [pyglet.sprite.DepthSprite(img, group, x=i*10) for i in range(10)]
window = pyglet.window.Window(500, 500)
@window.event
def on_draw():
window.clear()
group.draw()Note that sprites are bound to their group, and can't be migrated between groups. Each sprite has a depth attribute that controls rendering order. There is a self-contained test depth_sprite_test.py. Appreciate anyone who who can give it a shot!
- Josh
Benjamin Moran
Nov 1, 2016, 6:22:45 AM11/1/16
to pyglet-users
Hi Josh,
Nice work, if a bit different from how the batches and groups are currently used within pyglet.
I was looking over your code, and thinking about your texture atlases implementation. The current sprite groups are combined if possible if they share the same textures, so I was thinking about how to utilize this with your implementation.
I've also been reading up on different "order independent translucency" techniques, and realized that my quick zsprite hack does already do basic translucency correctly if you simply make sure to render all of the solid or simple transparent (1/0) textures first. This can easily be done by using the existing OrderedGroups, but putting all "solid" textures in one group, and all textues that need translucency in another. So basically, two OrderedGroups for all sprites. For example:
This all works as expected, with the normal blending quirks. I wonder if this might be enough? It wouldn't be hard to tweak the SpriteGroup more so that Sprite.opacity == 0 sprites are automatically in one group, and sprites with non-0 opacity values are in another.
Nice work, if a bit different from how the batches and groups are currently used within pyglet.
I was looking over your code, and thinking about your texture atlases implementation. The current sprite groups are combined if possible if they share the same textures, so I was thinking about how to utilize this with your implementation.
I've also been reading up on different "order independent translucency" techniques, and realized that my quick zsprite hack does already do basic translucency correctly if you simply make sure to render all of the solid or simple transparent (1/0) textures first. This can easily be done by using the existing OrderedGroups, but putting all "solid" textures in one group, and all textues that need translucency in another. So basically, two OrderedGroups for all sprites. For example:
solid = pyglet.graphics.OrderedGroup(0)
translucent = pyglet.graphics.OrderedGroup(1)
pyglet_image = pyglet.image.load("examples/pyglet.png")
spritea = pyglet.sprite.Sprite(img=pyglet_image, x=120, y=150, z=3, batch=batch, group=translucent)
spriteb = pyglet.sprite.Sprite(img=pyglet_image, x=140, y=170, z=2, batch=batch, group=translucent)
spritec = pyglet.sprite.Sprite(img=pyglet_image, x=160, y=190, z=1, batch=batch, group=solid)
sprited = pyglet.sprite.Sprite(img=pyglet_image, x=180, y=210, z=0, batch=batch, group=solid)
spritea.opacity = 200
spriteb.opacity = 200
This all works as expected, with the normal blending quirks. I wonder if this might be enough? It wouldn't be hard to tweak the SpriteGroup more so that Sprite.opacity == 0 sprites are automatically in one group, and sprites with non-0 opacity values are in another.
Josh
Nov 1, 2016, 12:48:04 PM11/1/16
to pyglet-users
Hi Benjamin,
When you say solid and translucent textures, are you assuming that the entire texture is one or the other? The problem I had that I couldn't solve with depth-invariant rendering order was with sprites that mix the two. This is actually a much more common use case than it sounds: any antialiased sprite that isn't a perfect rectangle will have translucent boundaries. When I try to render these using depth testing and alpha threshholding with these sprites, I wind up with really hideous artifacts at the outlines. Did you find a solution to this? I would love to learn more.
When you say solid and translucent textures, are you assuming that the entire texture is one or the other? The problem I had that I couldn't solve with depth-invariant rendering order was with sprites that mix the two. This is actually a much more common use case than it sounds: any antialiased sprite that isn't a perfect rectangle will have translucent boundaries. When I try to render these using depth testing and alpha threshholding with these sprites, I wind up with really hideous artifacts at the outlines. Did you find a solution to this? I would love to learn more.
Benjamin Moran
Nov 2, 2016, 1:04:42 AM11/2/16
to pyglet-users
Hi Josh,
You're probably right. I've only been testing with colored primitives and pixel-art style textures. When I say "solid", I mean textures that are opaque and might have pure transparency (basically 1 or 0 alpha only, like the "examples/pyglet.png" file). When I say translucency, I mean something like a glass window that has variable levels of opacity (like you get with the .opacity attribute on pyglet.Sprites).
I'll have to make up some more varied test textures to really see how things look. My hope was that there is a way to make the current unordered batches work acceptably, even if it requires a few set/unset_state calls per draw. Something like depth peeling is probably overkill, and we'd be better off going with ordered batches similar to what you're working on.
-Ben
You're probably right. I've only been testing with colored primitives and pixel-art style textures. When I say "solid", I mean textures that are opaque and might have pure transparency (basically 1 or 0 alpha only, like the "examples/pyglet.png" file). When I say translucency, I mean something like a glass window that has variable levels of opacity (like you get with the .opacity attribute on pyglet.Sprites).
I'll have to make up some more varied test textures to really see how things look. My hope was that there is a way to make the current unordered batches work acceptably, even if it requires a few set/unset_state calls per draw. Something like depth peeling is probably overkill, and we'd be better off going with ordered batches similar to what you're working on.
-Ben
Benjamin Moran
Nov 17, 2016, 12:15:40 AM11/17/16
to pyglet-users
Hi Josh,
I've been poking through your code, looking at Batch support. Was there a roadblock you ran into with OrderedDomain migration support, or you just skipped that for now?
I've been poking through your code, looking at Batch support. Was there a roadblock you ran into with OrderedDomain migration support, or you just skipped that for now?
-Ben
On Wednesday, November 2, 2016 at 1:48:04 AM UTC+9, Josh wrote:
Josh
Nov 17, 2016, 3:46:52 PM11/17/16
to pyglet-users
Hi Ben,
There's no roadblock with migrating OrderedDomains, it's just something I skipped for now (similar to animation support). It will require going deeper into the weeds with pyglet's allocation system, and there are some aspects of that I still don't understand.
Best,
Josh
There's no roadblock with migrating OrderedDomains, it's just something I skipped for now (similar to animation support). It will require going deeper into the weeds with pyglet's allocation system, and there are some aspects of that I still don't understand.
Best,
Josh
Benjamin Moran
Nov 18, 2016, 5:24:57 AM11/18/16
to pyglet-users
Thanks for the reply Josh,
Pyglet's graphics module is a great piece of code, but I'd be lying if I said I fully understood it all either :)
I haven't had time to really focus on this, but I've been poking around to see if we can fit the OrderedDomain into the existing API hierarchy.
Pyglet's graphics module is a great piece of code, but I'd be lying if I said I fully understood it all either :)
I haven't had time to really focus on this, but I've been poking around to see if we can fit the OrderedDomain into the existing API hierarchy.
Benjamin Moran
Nov 19, 2016, 9:30:59 AM11/19/16
to pyglet-users
Hi Josh,
I took your work and ran with it a little, to see if it could be fit into the existing api. So far, It seems to be going OK, but I would greatly appreciate your feedback on this. I'm just kinda winging it here :)
You can find my "ordered_sprite" branch here: https://bitbucket.org/treehousegames/pyglet/branch/ordered_sprite
First of all, I implemented an OrderedVertexDomain which is a copy of your OrderedDomain. The main difference is that it has it's own vertex_lists list, and sorting method. It also has it's own "create" method, which monkey patches an "order" attribute on the vertex_list, for use by the sorting method. There is a simple "self.dirty" attribute that determines if the vertex_lists list should be sorted automatically before the next draw.
By pushing all of that down the stack into the vertexdomain, The Sprite and SpriteGroup classes could be left almost original. The only addition being a "depth" property on the Sprite class which updates the vertex list order attribute, and sets the domain to "dirty" so that it will be sorted before the next draw.
As for requiring all sprites to be on the same TextureAtlas for blending to work correctly, that is still a requirement (no way around this in OpenGL). However, it's up to the user to ensure this part. It would be "automatic" if using the pyglet.resource module. If the user doesn't use a single atlas, everything will still work fine - but of course sorting won't work because they will be in different domains.
I haven't tested any of it yet, but I think animations and such will work fine since it's using the existing Groups and such.
-Ben
I took your work and ran with it a little, to see if it could be fit into the existing api. So far, It seems to be going OK, but I would greatly appreciate your feedback on this. I'm just kinda winging it here :)
You can find my "ordered_sprite" branch here: https://bitbucket.org/treehousegames/pyglet/branch/ordered_sprite
First of all, I implemented an OrderedVertexDomain which is a copy of your OrderedDomain. The main difference is that it has it's own vertex_lists list, and sorting method. It also has it's own "create" method, which monkey patches an "order" attribute on the vertex_list, for use by the sorting method. There is a simple "self.dirty" attribute that determines if the vertex_lists list should be sorted automatically before the next draw.
By pushing all of that down the stack into the vertexdomain, The Sprite and SpriteGroup classes could be left almost original. The only addition being a "depth" property on the Sprite class which updates the vertex list order attribute, and sets the domain to "dirty" so that it will be sorted before the next draw.
As for requiring all sprites to be on the same TextureAtlas for blending to work correctly, that is still a requirement (no way around this in OpenGL). However, it's up to the user to ensure this part. It would be "automatic" if using the pyglet.resource module. If the user doesn't use a single atlas, everything will still work fine - but of course sorting won't work because they will be in different domains.
I haven't tested any of it yet, but I think animations and such will work fine since it's using the existing Groups and such.
-Ben
On Friday, November 18, 2016 at 5:46:52 AM UTC+9, Josh wrote:
Josh
Nov 20, 2016, 6:22:07 PM11/20/16
to pyglet-users
Hi Ben,
I like this solution for staying with the original API. Tested it with ordered groups and it still performs correctly. I'm missing a couple pieces in terms of how it works with batches, though. I can't find the code change that actually causes Batch to use OrderedVertexDomain - can you point me to it?
I like this solution for staying with the original API. Tested it with ordered groups and it still performs correctly. I'm missing a couple pieces in terms of how it works with batches, though. I can't find the code change that actually causes Batch to use OrderedVertexDomain - can you point me to it?
Benjamin Moran
Nov 21, 2016, 2:10:27 AM11/21/16
to pyglet-users
Hey Josh,
As far as I understand it, the Batch is a group of domains that get drawn together, or consolidated when possible. Also, it appears that there is always a default batch, even if you don't explicitly create your own. The additional code needed for Batch support was actually quite minimal (assuming I didn't miss anything). In pyglet/graphics/__init__.py, I made the following changes:
As far as I understand it, the Batch is a group of domains that get drawn together, or consolidated when possible. Also, it appears that there is always a default batch, even if you don't explicitly create your own. The additional code needed for Batch support was actually quite minimal (assuming I didn't miss anything). In pyglet/graphics/__init__.py, I made the following changes:
- Added a new *Batch.add_ordered* method, underneith *Batch.add* and *Batch.add_indexed*.
- Modified *Batch._get_domain* so that it can create/return the OrderedVertexDomain when requested.
- Tweaked a few of the methods and the domain cache with an additional *ordered=True* parameter, just like for *indexed=True*.
I accidentally left a *print("new domain")* in there, which illustrates the consolidation that happens when the Sprites share the same TextureAtlas.
There is a bit more work to do in OrderedVertexDomain, such as the migration code. Also, deleting vertex_lists probably won't work because of the *OrderedVertexDomain._vertex_lists*.
Benjamin Moran
Nov 21, 2016, 7:49:28 AM11/21/16
to pyglet-users
By the way, I guess you saw it already, but I modified your depth_sprite_test.py app in the root of the repository.
Also, I think the cleanest way to fix the garbage collection issue caused by the OrderedVertexDomain._vertex_lists is probably by subclassing VertexList. A custom delete method can remove itself from the list, and the order attribute can be added so that OrderedVertexDomain.create can be neater.
I'm curious just how slow this will be. I guess it all comes down to the sitting time, and glDrawArrays VS glDrawElements.
Benjamin Moran
Nov 23, 2016, 4:51:09 AM11/23/16
to pyglet-users
I ended up subclassing VertexList, and fixed the garbage collection issue. I also added a vertex_index attribute to it, so during should be faster.
There are only two things left, which are:
1. Migration. The code is there, but I don't think it's accurate.
2. Handling of drawing OrderedVertexDomains with a primsize that is not equal to 1.
Number 2 is important, since drawing breaks if you delete vertex lists from the middle (or migrated, if that worked). I haven't had time to figure out glMultiDrawElements yet, which is what we need to use I think. Maybe a different type of index list is needed.
Feedback is appreciated. I'm thinking that maybe it would be a good idea to benchmark this implementation before spending time finishing it up.
Benjamin Moran
Dec 4, 2016, 10:03:14 AM12/4/16
to pyglet-users
Hey Josh, I've put this back on the back-burner for now, but It would be great if you wanted to keep at it. Anyone else with feedback would be welcome as well. The glMultiDrawElements index list was a little too much for me to figure out at the moment.
I'm still considering that a simple zsprite implementation might be a good start, since it can probably be added without breaking any backwards compatibility. Having a z attribute wouldn't necessarily mean that the batch couldn't also be ordered if desired.
I'm still considering that a simple zsprite implementation might be a good start, since it can probably be added without breaking any backwards compatibility. Having a z attribute wouldn't necessarily mean that the batch couldn't also be ordered if desired.
Josh
Dec 7, 2016, 4:18:50 PM12/7/16
to pyglet-users
Hi Ben,
I'll take a stab at it. Life is going to be hectic for a bit so I may not get to it until January. I'll also try making a few benchmarks. My suspicion is in almost all cases pyglet applications are CPU-bound, and glDrawElements is just faster than using ordered groups. If we get this to support migration, is there anything else that needs to be done for backwards compatibility?
I'll take a stab at it. Life is going to be hectic for a bit so I may not get to it until January. I'll also try making a few benchmarks. My suspicion is in almost all cases pyglet applications are CPU-bound, and glDrawElements is just faster than using ordered groups. If we get this to support migration, is there anything else that needs to be done for backwards compatibility?
Benjamin Moran
Dec 7, 2016, 10:24:11 PM12/7/16
to pyglet-users
No worries about the time-frame. We're just experimenting here after all!
As I understand it the OrderedGroups require a separate Domain.draw() call for each one, so it's pretty easy to see why they get slow when you use more than a few of them.
I think the only work left to do is within the OrderedVertexList. The glDrawElements function that we're using works well with a contiguous Vertex list, but once you delete/migrate anything it doesn't work anymore. The glMultiDrawElements is the way to go, but it doesn't accept the simple integer index list like glDrawElements does. We can see that IndexedVertexList uses an actual buffer for the indexes instead of the simple integer list, which seems to be what glMultiDrawElements wants. I'm thinking that maybe it would be easier to base OrderedVertexList off of IndexedVertexList, instead of the simpler VertexList.
As I understand it the OrderedGroups require a separate Domain.draw() call for each one, so it's pretty easy to see why they get slow when you use more than a few of them.
I think the only work left to do is within the OrderedVertexList. The glDrawElements function that we're using works well with a contiguous Vertex list, but once you delete/migrate anything it doesn't work anymore. The glMultiDrawElements is the way to go, but it doesn't accept the simple integer index list like glDrawElements does. We can see that IndexedVertexList uses an actual buffer for the indexes instead of the simple integer list, which seems to be what glMultiDrawElements wants. I'm thinking that maybe it would be easier to base OrderedVertexList off of IndexedVertexList, instead of the simpler VertexList.
...
Dec 9, 2016, 7:22:52 PM12/9/16
to pyglet...@googlegroups.com
Sounds like y'all are tackling the same issue I did when I wanted to do vectorized translations on vertex lists. I tried to use pyglets architecture but it was so tied to domains being dumb and not keeping track of what was in what they had allocated. This is for obvious performance reasons, but my idea didn't mesh at all.
I made a defragmenting buffer that keeps track of each allocated entity, and an allocator that places new entities accordingly, rearranging the buffer as necessary. Everything (with a common gl state) is rendered with one glDrawArrays call.
Sorry for the terse description. I'm on my phone. Let me know if I can help. I'd love if pyglet had native support for ordered, contiguous buffers that could interface with my entity component system. Maybe you can use some code from the allocator. Here's the project:
https://github.com/Permafacture/data-oriented-pyglet
Elliot
Benjamin Moran
Dec 10, 2016, 8:36:57 PM12/10/16
to pyglet-users
Hey Elliot,
The defragmenting buffer sounds interesting. How does it perform?
My solution to sorting was to keep a list of associated VertexLists in the OrderedDomain. The VertexLists themselves all have a reference to their parent domain (even if it's the default pyglet domain). Whenever any VertexList's depth attribute was changed, the parent domain is marked as dirty and gets sorted at the next draw call. It works fairly well, but I didn't have time to figure out the glMultiDrawElements stuff.
For an experiment I rebasing off of the IndexedVertexLists, but I discovered that those seem to be broken. I don't know if this is just my machine, but it seems like any batch/domain that contains indexed vertex lists will fail to draw correctly if you delete any of the lists in the middle of the order. Indexed vertex lists are not really necessary for the sorting stuff, so I reverted back to plain vertex lists in my branch.
The defragmenting buffer sounds interesting. How does it perform?
My solution to sorting was to keep a list of associated VertexLists in the OrderedDomain. The VertexLists themselves all have a reference to their parent domain (even if it's the default pyglet domain). Whenever any VertexList's depth attribute was changed, the parent domain is marked as dirty and gets sorted at the next draw call. It works fairly well, but I didn't have time to figure out the glMultiDrawElements stuff.
For an experiment I rebasing off of the IndexedVertexLists, but I discovered that those seem to be broken. I don't know if this is just my machine, but it seems like any batch/domain that contains indexed vertex lists will fail to draw correctly if you delete any of the lists in the middle of the order. Indexed vertex lists are not really necessary for the sorting stuff, so I reverted back to plain vertex lists in my branch.
...
Dec 11, 2016, 8:50:36 PM12/11/16
to pyglet...@googlegroups.com
How does it perform? I have not profiled the allocator. Being able to used numpy or numba vectorized operations to transform verticies was a massive performance improvement. Being able to have the rendering and game logic happen in separate processes (with multiprocessing) what use shared memory was a significant performance improvement. (for example, a 50 FPS physics simulation went to 600 FPS rendering and 180 physics time steps per second). Actually adding and deleting "vertex lists" from a Domain is likely very slow because much of the data gets shuffled around. IE: adding three elements that won't be next to each other involves reassigning six slices as it moves the data out of the way to make room and then inserts the new data. It would be an improvement if deleted areas just had null values assigned (ie, empty triangles), since if only some percentage of the buffer is "dead", it doesn't take much time to render empty triangles compared to shuffling data around.
The fragmentation is only important because it simplifies and improves the performance of the numpy operations (they operate on contiguous arrays rather than indexing over arrays with dead values).
I'll poke around your branch and see what your sorting/data shuffling code looks like.The fragmentation is only important because it simplifies and improves the performance of the numpy operations (they operate on contiguous arrays rather than indexing over arrays with dead values).
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to pyglet...@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
Benjamin Moran
Dec 12, 2016, 4:54:23 AM12/12/16
to pyglet-users
Hi Elliot,
That sounds pretty nice. The null triangles idea makes sense. I guess it would be considered wasteful, but would be insignificant waste with even semi-modern GPU memory.
I find the numpy stuff fascinating. I also love pyglet for being "pure Python", as in only needing the standard library. I feel like there is a need for pyglet in the Python world, but certainly a need for more focused libraries like yours.
If you poke around my branch, you'll see it's fairly simple. It uses the default vertex lists and allocator, so there is fragmentation when deleting/migrating lists. I'm relying on the gl*Elements functions to draw things out of the order in which they're allocated.
The sort method is just a simple sort with lambda depth. The sort is only called when a vertex lists depth attribute is changed, so it should perform well if there aren't many changes. I hear the Python sort function is fairly fast, but I've not benchmarked it.
Benjamin Moran
Dec 15, 2016, 8:45:47 AM12/15/16
to pyglet-users
Hi guys,
I was able to figure this out (I think). The solution was to just use glMultiDrawArrays, and forget about using glMultiDrawElements. The gl*Elements methods probably didn't make sense anyways, since the vertex lists are not really indexed anyway. With glMultiDrawArrays, we just need an array of the start + size of each vertex list. This information is pretty easily grabbed from each vertex list, so the implementation turned out to be very simple. Basically this:
The starts and sizes can be moved out of the draw method so that this is only recalculated if the OrderedDomain is marked as dirty, and the sort_vertex_lists method is called. I'll probably do this soon.
I was able to figure this out (I think). The solution was to just use glMultiDrawArrays, and forget about using glMultiDrawElements. The gl*Elements methods probably didn't make sense anyways, since the vertex lists are not really indexed anyway. With glMultiDrawArrays, we just need an array of the start + size of each vertex list. This information is pretty easily grabbed from each vertex list, so the implementation turned out to be very simple. Basically this:
starts = [vert_list.start for vert_list in self._vertex_lists]
sizes = [vert_list.get_size() for vert_list in self._vertex_lists]
primcount = len(starts)
starts = (GLint * primcount)(*starts)
sizes = (GLsizei * primcount)(*sizes)
glMultiDrawArrays(mode, starts, sizes, primcount)
The starts and sizes can be moved out of the draw method so that this is only recalculated if the OrderedDomain is marked as dirty, and the sort_vertex_lists method is called. I'll probably do this soon.
Josh
Jan 5, 2017, 9:45:53 PM1/5/17
to pyglet-users
I'm experimenting with this and it seems to be working so far.
Benjamin Moran
Jan 6, 2017, 12:18:44 AM1/6/17
to pyglet-users
Great! As you can see in pyglet.graphics.vertexdomain.OrderedDomain, I moved all of the sorting stuff into it's own method. I tried to make the draw method as efficient as possible, but there might be
some ways to speed up the sorting method. As it is, sorting is required under the following conditions:
1. A vertex_list/sprite gets added, deleted, or migrated to or from the batch/domain.
2. Any vertex_list/sprite's order attribute gets changed.
As it stands, it's very similar to the standard VertexDomain except that it keeps it's own starts/sizes lists instead of using the lower level allocators lists.
I think it would be nice to benchmark against VertexDomain to see how much of an impact this has. Maybe the following benchmarks would be a good start:
1. Creating several thousand sprites and moving them around each frame. No addition/deletion of anything, to avoid calling the sorting method.
2. The same test, but randomly delete/add sprites each frame. This will illustrate the sorting overhead.
What do you think?
some ways to speed up the sorting method. As it is, sorting is required under the following conditions:
1. A vertex_list/sprite gets added, deleted, or migrated to or from the batch/domain.
2. Any vertex_list/sprite's order attribute gets changed.
As it stands, it's very similar to the standard VertexDomain except that it keeps it's own starts/sizes lists instead of using the lower level allocators lists.
I think it would be nice to benchmark against VertexDomain to see how much of an impact this has. Maybe the following benchmarks would be a good start:
1. Creating several thousand sprites and moving them around each frame. No addition/deletion of anything, to avoid calling the sorting method.
2. The same test, but randomly delete/add sprites each frame. This will illustrate the sorting overhead.
What do you think?
Charles
Jan 8, 2017, 8:24:14 PM1/8/17
to pyglet-users
It's been a long time since I checked this thread, but it looks like there has been quite a lot of progress since I last looked. I have tested the test branch and so far I have found the ordering to work without issues.
I guess my questions on the latest changes are:
1) Are there any limitations for this? I know last I looked and tested the z sprite issues, there were some alpha and transparency issues.
2) Have you done any benchmarks on ordered groups compared to this method? How does having a lot of different sprites (hundreds) on various order levels affect performance?
Thanks for your work guys!
Benjamin Moran
Jan 9, 2017, 3:07:13 AM1/9/17
to pyglet-users
Hi Charles,
1) No inherit limitations. Under the hood, it's functionally identical to the normal VertexDomains, except that it keeps it's own additional lists of starts/sizes for the VertexLists in the Domain, which are sorted. There should be no Alpha/transparency issues, since everything is rendered in order and will composite correctly.
2) This will be infinitely faster than OrderedGroups, IF you're doing more than a few groups. The reason being is that Groups in pyglet set and unset OpenGL state, and each Group reqires a seperate draw process. Pyglet consolidates Groups by default, so a batch with a lot of objects using the same TextureAtlas, etc. will usually all draw together - most of the time your objects will be similar and automatically grouped into the same draw call. By using OrderedGroup, you are forcing a seperate draw call for every single group. A few groups, like "background", "midsection", "foreground", etc. is fine, but it will fall on it's face if you try to do a lot.
The performance question is not so simple:
For basic benchmarks of static sprites, the draw speed for OrderedVertexDomain is identical to the normal VertexDomain. Drawing 20,000 sprites takes about 0.010ms (@ 90fps). It doesn't matter how many different order levels there are. If you try to use OrderedGroups, it takes over 3 seconds(!) to draw the same amount of sprites.
That said, the actual sorting process does use some CPU. Any time you add/delete/migrate a sprite/vertex_list in an OrderedVertexDomain, it does a sort before the next draw. Even if you're doing this every frame, it's still good for thousands of sprites. I'm sure the sort process can be optimized a bit more.
1) No inherit limitations. Under the hood, it's functionally identical to the normal VertexDomains, except that it keeps it's own additional lists of starts/sizes for the VertexLists in the Domain, which are sorted. There should be no Alpha/transparency issues, since everything is rendered in order and will composite correctly.
2) This will be infinitely faster than OrderedGroups, IF you're doing more than a few groups. The reason being is that Groups in pyglet set and unset OpenGL state, and each Group reqires a seperate draw process. Pyglet consolidates Groups by default, so a batch with a lot of objects using the same TextureAtlas, etc. will usually all draw together - most of the time your objects will be similar and automatically grouped into the same draw call. By using OrderedGroup, you are forcing a seperate draw call for every single group. A few groups, like "background", "midsection", "foreground", etc. is fine, but it will fall on it's face if you try to do a lot.
The performance question is not so simple:
For basic benchmarks of static sprites, the draw speed for OrderedVertexDomain is identical to the normal VertexDomain. Drawing 20,000 sprites takes about 0.010ms (@ 90fps). It doesn't matter how many different order levels there are. If you try to use OrderedGroups, it takes over 3 seconds(!) to draw the same amount of sprites.
That said, the actual sorting process does use some CPU. Any time you add/delete/migrate a sprite/vertex_list in an OrderedVertexDomain, it does a sort before the next draw. Even if you're doing this every frame, it's still good for thousands of sprites. I'm sure the sort process can be optimized a bit more.
Charles
Feb 19, 2017, 2:26:11 PM2/19/17
to pyglet-users
Hey Benjamin, I know it's been a while since our last posts, but I have just started experimenting with the ordered sprite branch. Everything is working perfect (performance, implementation, ordering) except one thing.
Whenever a sprite uses the order attribute it will sometimes flicker. So for an example I have my tiles with no order set, but in my 'game objects' layer where everything is ordered by the order attribute. Unfortunately it doesn't happen all the time, but when it does, it flickers all of the ordered sprites every couple of seconds or so.
Unfortunately it's hard to test since it's so inconsistent, majority of the time it seems ok. Just wondering if you've run across this issue before? Thanks.
Benjamin Moran
Feb 19, 2017, 9:00:19 PM2/19/17
to pyglet-users
Hey Charles,
No worries. It's good to squash any bugs that might exist. First of all, are you using the latest version of the code? There wa a missing sort call that existed before, and would cause trouble.
Unfortunately I haven't come across that issue, but I haven't stressed this code extensively in any of my personal projects. If it's at all possible, can you share an example of code that illustrates the problem? Even if it only happens sometimes, it would be a good start to track it down. Internally, the OrderedVertexDomain is quite simple. There is a single call to glMultiDrawArrays, which takes in two lists of starts/sizes, as well as primsize. The most crutial bit of the code is ensuring that these starts and sizes lists are regenerated when necessary. Basically any time you add, delete, migrate, or sort a vertex list, the domain is marked as dirty and is sorted before the next call.
The only other thing I'm unsure of are the buffers + attributes that are bound before each call. I'm not very familar with that code (or honestly the deep OpenGL logic behind this), but it's a possibility that this is the cuprit.
No worries. It's good to squash any bugs that might exist. First of all, are you using the latest version of the code? There wa a missing sort call that existed before, and would cause trouble.
Unfortunately I haven't come across that issue, but I haven't stressed this code extensively in any of my personal projects. If it's at all possible, can you share an example of code that illustrates the problem? Even if it only happens sometimes, it would be a good start to track it down. Internally, the OrderedVertexDomain is quite simple. There is a single call to glMultiDrawArrays, which takes in two lists of starts/sizes, as well as primsize. The most crutial bit of the code is ensuring that these starts and sizes lists are regenerated when necessary. Basically any time you add, delete, migrate, or sort a vertex list, the domain is marked as dirty and is sorted before the next call.
The only other thing I'm unsure of are the buffers + attributes that are bound before each call. I'm not very familar with that code (or honestly the deep OpenGL logic behind this), but it's a possibility that this is the cuprit.
Charles
Feb 19, 2017, 9:28:03 PM2/19/17
to pyglet-users
I have done a lot of rounds of testing and found some issues. (tileImg = 32x32, objectImg = 16x16)
1) No order set.
Sprites that sit on top of each other.
Same group.
A majority of the time, the objectImg sprites will not load. Restarting several times and they may show up half the time. Some issue there.
Example:
tileGroup = pyglet.graphics.OrderedGroup(0)objectGroup = pyglet.graphics.OrderedGroup(1)sprites = []
for i in xrange(50):
for j in xrange(50):
sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, batch=batch, group=tileGroup))
for i in xrange(50):
for j in xrange(50):
sprites.append(pyglet.sprite.Sprite(objectImg, x=i*32, y=j*32, batch=batch, group=tileGroup))
2) No order set:
Sprites that sit on top of eachother.
Different groups.
Works as expected 100% of the time. Both groups of sprites show up.
Example:
tileGroup = pyglet.graphics.OrderedGroup(0)objectGroup = pyglet.graphics.OrderedGroup(1)
sprites = []
for i in xrange(50):
for j in xrange(50):
sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, batch=batch, group=tileGroup))
for i in xrange(50):
for j in xrange(50):
sprites.append(pyglet.sprite.Sprite(objectImg, x=i*32, y=j*32, batch=batch, group=objectGroup))3) Introduce a playerSprite into the mix and orders into the objectGroup.
Orders based on y.
Sprites may start on top of eachother (ie, object and player sprite start at 0x0)
Results: Sometimes the player sprite appears under the object sprites, sometimes over the object sprites. Once the sprite appears over or under, order will no longer have an effect.
For instance if it starts under all of the object sprites, changing the order will not put it over the sprites it will always stay under. If the sprite starts OVER the sprites, changing the order will not put it under the sprites.
tileGroup = pyglet.graphics.OrderedGroup(0)objectGroup = pyglet.graphics.OrderedGroup(1)
sprites = []for i in xrange(50): for j in xrange(50): sprites.append(pyglet.sprite.Sprite(tileImg, x=i*32, y=j*32, batch=batch, group=tileGroup))
for i in xrange(50): for j in xrange(50): sprites.append(pyglet.sprite.Sprite(objectImg, x=i*32, y=j*32, order=j*32, batch=batch, group=objectGroup))
playerSprite = pyglet.sprite.Sprite(playerImg, x=0, y=0, group=objectGroup, batch=batch)
def moveChar(dt, axis, val): if axis == "x": playerSprite.update(x=playerSprite.x+val) else: playerSprite.update(y=playerSprite.y+val) playerSprite.order = playerSprite.y
Under no circumstances can I get this method to actually work as intended where the sprite will appear over the sprites in objectGroup up until it passes the sprite and goes under it.
Charles
Feb 19, 2017, 10:28:31 PM2/19/17
to pyglet-users
Just saw your reply. The version I have is from 2/11/2017
Benjamin Moran
Feb 20, 2017, 3:12:47 AM2/20/17
to pyglet-users
Thanks for all of the example code and detail Charles, that's plenty of info to go on.
This is exactly the type of testing that needed to be done. I've actually not tested this with OrderedGroups, since ordering makes them redundant. However, there is no reason it shouldn't be able to work. Not working with OrderedGroups indicates that it probably won't work with custom Groups either.
I'll first confirm that I have the same results, and then hopefully it's something that can be fixed at the domain level.
This is exactly the type of testing that needed to be done. I've actually not tested this with OrderedGroups, since ordering makes them redundant. However, there is no reason it shouldn't be able to work. Not working with OrderedGroups indicates that it probably won't work with custom Groups either.
I'll first confirm that I have the same results, and then hopefully it's something that can be fixed at the domain level.
Benjamin Moran
Mar 9, 2017, 10:09:05 PM3/9/17
to pyglet-users
Hi Charles,
Sorry it took me so long to get back to you on this. The answer is pretty simple: All of the sprites/images must be on the same TextureAtlas in order for the OrderedVertexDomain to work. If you just do a *pyglet.image.load* for each image, they are put into their own seperate Domains. This is because the the Groups/Domains can't be consolidated (and drawn together in one shot) when the texture is different.
In your example, when each image is on it's own texture, you end up with two Groups - each Group containing a ton of VertexDomains under the hood. By making sure everything shares the same texture, you'll get two Groups with one big VertexDomain each (which can be ordered). Does this make sense? It might be a bit hard to visualize if you're not familiar with how things work in the graphics module.
The easy way is to just use the pyglet.resource module for loading images, but of course you can manually create your own Atlas as well.
Sorry it took me so long to get back to you on this. The answer is pretty simple: All of the sprites/images must be on the same TextureAtlas in order for the OrderedVertexDomain to work. If you just do a *pyglet.image.load* for each image, they are put into their own seperate Domains. This is because the the Groups/Domains can't be consolidated (and drawn together in one shot) when the texture is different.
In your example, when each image is on it's own texture, you end up with two Groups - each Group containing a ton of VertexDomains under the hood. By making sure everything shares the same texture, you'll get two Groups with one big VertexDomain each (which can be ordered). Does this make sense? It might be a bit hard to visualize if you're not familiar with how things work in the graphics module.
The easy way is to just use the pyglet.resource module for loading images, but of course you can manually create your own Atlas as well.
Benjamin Moran
Mar 13, 2017, 12:58:21 AM3/13/17
to pyglet-users
Just wanted to let people know that my personal fork of pyglet containing this branch has changed. The new link is: https://bitbucket.org/HigashiNoKaze/pyglet/branch/ordered_sprite
I'm thinking that, just like the IndexedVertexDomain, the OrderedVertexDomain is worthwhile to include in pyglet. I'd have to think about it after the 1.3.x release.
I'm still not sure if it makes sense to changed the Sprite module at this time. It seems like there are perfectly valid reasons to go with ordering, OR zbuffer.. You can always do both, of course, but the OrderedVertexDomain does incur a bit of overhead when sorting. Due to the way it works, sorting is required when adding/deleting vertex lists, so for some use cases it could be slower.
I'm thinking that, just like the IndexedVertexDomain, the OrderedVertexDomain is worthwhile to include in pyglet. I'd have to think about it after the 1.3.x release.
I'm still not sure if it makes sense to changed the Sprite module at this time. It seems like there are perfectly valid reasons to go with ordering, OR zbuffer.. You can always do both, of course, but the OrderedVertexDomain does incur a bit of overhead when sorting. Due to the way it works, sorting is required when adding/deleting vertex lists, so for some use cases it could be slower.
Charles
Mar 22, 2017, 12:10:38 PM3/22/17
to pyglet-users
Thanks for the response, that makes sense now. That was kind of the limitation I was wondering about initially. Unfortunately that kind of makes it inconsistent for use since now the texture atlas size is dynamically chosen based on machine configuration. You can't guarantee texture atlas size without managing them all on your own and it would have to be on the small side to maintain compatibility. Also this makes it unusable for larger projects since, for instance, just my creatures can take up one whole atlas by itself, leaving it unable to be ordered with the world objects. However, using it in smaller projects this is a good implementation and I agree with adding it as an option for people since it's a common question these days.
Benjamin Moran
Mar 23, 2017, 9:53:29 AM3/23/17
to pyglet-users
Sorry I didn't think to mention the texture atlas part, but that is definitely something that needs to be well documented.
Just for clarity, and for others reading this, the current pyglet.resource module uses an internal TextureBin of 2048x2048 if possible, but will do a check first to see how big the card can actually handle. The TextureAtlas/Bin classes themselves have also added a check to fall back to the maximum size available if the requested size is not possible. This was done so that if another user runs your app/game on an older GPU, it might have a chance to run instead of just crashing.
One thing you could do is to make more than one altas. This by itself will mean multiple draw calls of course, since you'll be using more than one texture. You can then use OrderedGroups to ensure that they draw in the order you want.
Just for clarity, and for others reading this, the current pyglet.resource module uses an internal TextureBin of 2048x2048 if possible, but will do a check first to see how big the card can actually handle. The TextureAtlas/Bin classes themselves have also added a check to fall back to the maximum size available if the requested size is not possible. This was done so that if another user runs your app/game on an older GPU, it might have a chance to run instead of just crashing.
One thing you could do is to make more than one altas. This by itself will mean multiple draw calls of course, since you'll be using more than one texture. You can then use OrderedGroups to ensure that they draw in the order you want.
Delta
Oct 22, 2019, 8:51:06 AM10/22/19
to pyglet-users
Hello ! I am a newcomer in pyglet and i am looking for a way to render z sorting sprites, and so that's how I found your work
The problem is that the link https://bitbucket.org/HigashiNoKaze/pyglet/branch/ordered_sprite is not working anymore, so where can I find your Ordered_sprite branch ?
Thanks for all
Reply all
Reply to author
Forward
0 new messages