On Dec 15, 5:46 am, Tristam MacDonald <[email protected]> wrote: > Sprites are inherently 2-dimensional. Using 4x4 matrices to transform them > would be a gross waste of processing power ;)
Yeah, except that your texcoords are going to get padded out to 4- float vectors anyway, either in the driver, or in HW, and you need at least a 4x4 matrix for properly transforming them. As a real, practical example, the v2i used in Sprite for position is *not* actually valid on pre-HD Radeons, so it must be translated in the driver into v4f. Ouchies. (I seem to remember that this is also the case on GeForces from that era, but I don't know for sure.) On the other hand, the v2f I've been using is directly sent to the HW, where the HW pads it out into v4f transparently, way faster than anything CPU-side. On the other other hand, it's not like this actually costs anything for the first couple hundred sprites, compared to the next thing... > Above and beyond that, your suggestion of using the matrix stack would > require you to set the modelview matrix for *each* sprite. Instead, pyglet > manually calculates the sprite transform, so that it can pack many sprites > into a single vertex buffer, and render them with a single draw call. > > This is essential for OpenGL performance, and even more so for pyglet - the > ctypes bindings make individual OpenGL calls very expensive. Meh. No matter what, there's overhead. If you do matrices on a shader pipeline, then you have to invalidate your vertex shader each time you change to a different sprite, which sucks even with e.g. Gallium, which caches shaders. On the other hand, if you do a pre-calculated VBO, you have to invalidate the entire VBO when any of the sprites change, which sucks unless your driver has ARB_map_buffer_range. (And even then, it sucks if your VBO is large and you're not on an IGP chipset.) With all of that said, the pyglet way is probably a win, but I'm still kind of annoyed that there's no matrix math in pyglet. I'm doubly annoyed that subclasses of Sprite have to override _update_position() (A private method!) in order to change anything about the way that it gets drawn, since the method is so inflexible. > ARB_npot changes nothing for people already specifying texrect texture > > > targets. It only relaxes the conditions for NPOT textures, permitting > > them to be used in more situations. I'm really not sure how somebody > > could be creating forwards-incompatible setups without grievous abuse > > of isinstance(). > > If load a NPOT2 image currently, pyglet will resize it to the nearest power > of 2, padding out the difference. I then calculate the texture coordinate > bonds of the original image (as a sub-region of the padded texture), and use > those texture coordinates to render it. > > If it suddenly loads the texture directly as NPOT, my texture coordinate > calculations are going to give blatantly incorrect results. Doesn't that also apply when using texrect? Every chipset put out this decade supports texrect, either the NV or the ARB flavor, and pyglet appears to be perfectly happy greedily using texrect when it can. ~ C. > On Dec 13, 5:59 pm, Tristam MacDonald <[email protected]> wrote: > > > > > > On Sun, Dec 13, 2009 at 3:39 AM, Corbin Simpson > > > <[email protected]>wrote: > > > > > First, Sprite doesn't use GL's modelview matrices to do its scaling, > > > > rotation, etc. This wouldn't be a big deal, except that cocos doesn't > > > > really respect that (cocos.sprite.Sprite overrides draw() without > > > > adding any functionality) and as a result a couple of my Sprite-based > > > > classes are a bit on the bloated side. > > > > > I've got a TiledSprite class that derives from Sprite and has the > > > > ability to tile its texture arbitrarily. I'd like to upstream this > > > > since it's icky to have in my code and pyglet's license requires it, > > > > but right now it doesn't work with scaling/rotate and I'm not keen on > > > > adding that in unless Sprite can be changed to do matrices. > > > > The issue is that Pyglet does this the 'right way' (i.e. managing > > > rotation/scaling internally), and cocos does it the old-fashioned way. In > > > particular, with OpenGL 3.0 rapidly approaching mainstream, the OpenGL > > > matrix stacks are going away, and rapid manipulations of the matrix stack > > > haven't been a performance path for some time. > > > > As such, it is more of a cocos bug than a pyglet bug. > > > > Speaking of which, ARB_npot isn't properly supported. I attached a > > > > > patch in the issue tracker that should provide correct NPOT support > > > > when available, falling back to rectangles correctly, etc. but haven't > > > > seen any movement on that yet. > > > > I brought this up a while ago, but there are some issues with backwards > > > compatibility. We need to make sure that applications using the current > > > pyglet API continue to function identically after the patch is applied, > > > which won't be the case if the application is suddenly dealing with > > textures > > > of different pixel dimensions. > > > > The fix here would be to introduce a new flag to existing texture methods > > > (or entirely new methods) to specify NPOT behaviour, but I don't believe > > we > > > ever sorted the details of the necessary API changes. > > > > -- > > > Tristam MacDonaldhttp://swiftcoder.wordpress.com/ > > > -- > > > You received this message because you are subscribed to the Google Groups > > "pyglet-users" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<pyglet-users%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/pyglet-users?hl=en. > > -- > Tristam MacDonaldhttp://swiftcoder.wordpress.com/ -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
