The standard matrix stacks might be going away, but it's not exactly like Mesa's going to support OGL 3.0 any time soon. Also, matrix multiplication can still be done in vert shaders. 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.
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(). Moreover, it's part of the GL core in OGL 2.0, and all GL 2.0 drivers, with the exception of the cursed fglrx, provide it. (And even fglrx is decent; it omits the ARB_texture_non_power_of_two string from its extension list.) It's kind of weird that such a feature would be omitted, when it transparently provides more functionality. 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]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
