On 10/7/08, David Eyk <[EMAIL PROTECTED]> wrote: > > On Oct 6, 9:11 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > wrote: > > > * AbstractImage/batch/group integration > > > > I'm afraid that AbstractImage integration just doesn't make sense for > > SVG. The AbstractImage class is really quite tightly coupled to OpenGL > > textures, and most of the API simply wouldn't translate to an SVG > > setting. Batches and groups on the other hand, are on the way. I may > > even have a bit of a hack on it this evening, if I don't get > > distracted by a shiny object. > > > Maybe I'm asking the wrong question, or maybe I'm displaying my > ignorance of the underlying structures of pyglet. My end-goal is to > have an SVG object that I can pass to a Sprite's constructor, so I > don't have to do messy jury rigged copycat classes to use an SVG with > a 3rd-party extension of Sprite, i.e. Cocos2d. It is not the end of > the world if I have to continue doing this. However, it would be nice > not to have to treat SVGs specially at such a basic level.
I can't speak for cocos2d, but pyglet's Sprite class is entirely designed around drawing a region of an OpenGL texture. As long as squirtle renders vector data, and not raster data, there's no match here at all. Perhaps what's really needed is a sprite-like interface to anything that can be "batchable" -- indeed, there's already a sort of feature request for this (issue 272), but creating such a thing would be non-trivial. In the meantime, creating "copycat" sprite classes is definitely the way to go. Alex. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
