On Monday, May 27, 2013 1:36:28 AM UTC-3, Claudio Canepa wrote: > > > > > On Fri, May 24, 2013 at 8:54 PM, Gerardo Marset > <[email protected]<javascript:> > > wrote: > >> Hey, Claudio, thank you for your answer. >> >> On Friday, May 24, 2013 7:25:41 PM UTC-3, Claudio Canepa wrote: >> >>> >>> > [snip] > > >> It is an operation rarely needed. >>> >>> The additional parameter would need to be used in >>> cocos.sprite.Sprite._update_position, and as a result that method would be >>> a little slower for *any* sprite, not only the ones with scale_x != scale_y >>> >>> cocos (or pyglet) sprites are slow in terms of openGL performance >>> >>> So, there is a tradeof : make easy a rarely required feature versus make >>> the general case slower. >>> >>> So far the feature was not seen as justifying the cost. >>> >> >> Is the cost really that big, though? I just checked >> cocos.sprite.Sprite._update_position, and confirmed it would work just fine >> if scale_x != scale_y with minimum changes... >> Here, look: http://pastebin.com/NnSk8GTv >> I didn't test much, but it seems to work just fine. >> -- >> >> > > I was too short in my reply, sorry. > The cost is not only in the internals of _update_position, but also how > many times it will be called, and the details of how the api for the > expanded scale should be. > > Suppose the public api is new members scale_x , scale_y > To follow the current style that changing a fundamental parameter of > sprite automagically updates the vertices, they should be properties, and > each setter should call _update_position > In the common use cases of scale, the ones currently supported by > cocos. > sprite.scale = 2.0 > produces one call to update position; switching to the new style the > same should be expressed as > sprite.scale_x = 2.0; sprite.scale_y = 2.0 > which means two calls to update position. Thats heavy. > > A better alternative can be define scale as a 2-tuple giving (scale_x, > scale_y) > thus the example case goes to > sprite.scale = (2.0, 2,0) > This needs only one call to _update_position, adds a little overhead there > to unpack the tuple, and possibly the caller has packing + generation > overhead. > Maybe acceptable, is not a double call to _update_position > > > Still, The common operation 'do this node at triple size' which > currently is expressed as > node.scale *= 3 > now will have to be written > node.scale = (node.scale[0] * 3 , node.scale[1] * 3) > This doesn't look newbie-friendly, and seems more prone to stupid errors > > So, maybe a better alternative is: > allow scale to be a scalar or a 2-tuple > add conditional code in _update_position to do the correct math > > This has the added benefit that is backwards compatible. > > Other things to consider: > > 1. It is desired that all cocosnodes share the same fundamental parameters > (position, scale, scale, rotation,...); this consistency eases the general > coding, and in particular allow a generic action to work over any type of > CocosNode. > So, it is desirable to port the new scale api to cocosnode , implement > there and see if this change needs to adjust some other methods. > Probably not hard, but someone should do that. > > 2. Actions expecting to be able to resize nodes by node.scale *= factor > should be recoded to use conditional code. Here is an unknown quantity of > work to do. > > Okay, this look like there are no hard points, but the total change will > need a fair amount of work. > If someone wants to implement, with these or another approach, I have no > problem to give commit access to work in a branch , and when the feature is > complete move to trunk. > 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.
-- 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.
