On Tue, Dec 15, 2009 at 7:59 AM, Corbin <[email protected]> wrote:
> I'm not exactly sure why using matrices is a bad thing. I'm mostly just > annoyed that I have > to do all this matrix math myself instead of just handing off a couple > of potentially pre-created matrices; AFAICT pyglet doesn't have any > utility methods for matrix math. > Sprites are inherently 2-dimensional. Using 4x4 matrices to transform them would be a gross waste of processing power ;) 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. 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. 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 MacDonald http://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.
