On Fri, May 24, 2013 at 8:54 PM, Gerardo Marset <[email protected]>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. -- 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.
