On Mon, May 27, 2013 at 6:06 AM, Gerardo Marset <[email protected]>wrote:
> > > I might give it a shot. > Here's another option: have scale work as it has until now, and add two > new properties scale_x and scale_y. In _update_position, have x1 multiply > by both _scale and _scale_x, and have y1 multiply by both _scale and > _scale_y. This would add the new functionality and still be 100% backwards > compatible, if maybe a little... redundant. > > The last option reduces the scope change to only class Sprite, which is what most people asks. The direct extra cost in _update_position is two new access, two mults for any sprite , whether it uses or not the anisotropic scaling, probably acceptable. When doing an affect that wants to change both _scale_x and _scale_y there will be two calls to _update_position, giving roughly half the performance than in other cases. Going with a 2-tuple _scale_xy eliminates the double call, but will add unpacking overhead to all the cases. Being a special case, guessing that normal use will unlikely have a lot of sprites with worst case performance, I'd say that having the standard scale plus the new _scale_x and _scale_y is a good option. So, should I add you as commiter ? :-) -- You received this message because you are subscribed to the Google Groups "cocos2d discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/cocos-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
