On Tue, Jun 30, 2009 at 5:50 AM, claudio canepa<[email protected]> wrote: > > While refactoring squirtle ( svg for pyglet ) for use in cocos, I needed to > see how cocos handles anchors. > I found it somewhat complex, thus making a litle interactive app to test > anchor behavoir [1], reading the code and writing some more test code. > > I reported a bug about CocosNode.transform() ignoring .children_anchor in > some cases, with patch. > > Here it follows a brief anchors behavoir description, wich some my find > useful, and then it follows some questions. > Note that the description asumes the patch is applied. > > > ---------------------------------------------------------------------------------------- > > All the drawables in cocos are CocosNode subclasses. > CocosNode has the following anchors (there are technically properties): > > .transform_anchor > .transform_anchor_x > .transform_anchor_y > > .children_anchor > .children_anchor_x > .children_anchor_y > > .anchor > .anchor_x > .anchor_y > > Due to the properties magic you have: > > transform_anchor == ( transform_anchor_x, transform_anchor_y) at any time > children_anchor == ( children_anchor_x, children_anchor_y) at any time > > Acces to .anchor will raise Exception if transform_anchor != children_anchor > (same for anchor_x, anchor_y) > Assignements to .anchor will propagate to both .transform_anchor and > .children_anchor (same for anchor_x, anchor_y) > > > To describe the CocosNode behavoir with respect its anchors, it is better to > clasify in two cases: > > Type 1 behavoir, when .tranform() is called in .draw() before drawing > anything: > The object will rotate around .transform_anchor > The object view position will have an offset of .children_anchor, that is, > the following two fragments will render the same view: > > #fragment1 > obj = MyNode() > obj.position = 100,100 > obj.anchor = 0,0 > > #fragment2 > obj = MyNode() > obj.position = 0,0 > obj.anchor = 100,100 > > To rotate alpha degrees the object, you simply do: > obj.rotation = alpha > > > Type 2 behavoir, when .transform() is not called in .draw() before drawing: > Childs of object will rotate around .transform_anchor . Some parts can be > drawn without rotation, you can't tell without examination of .draw() > code. > The childs object view position will have an offset of .children_anchor. > Some parts can be drawn without this offset, you can't tell without > examination of .draw() code > The following two fragments in general would not be equivalent: > #fragment1 > obj = MyNode() > obj.position = 100,100 > obj.anchor = 0,0 > > #fragment2 > obj = MyNode() > obj.position = 0,0 > obj.anchor = 100,100 > > In general, rotation of the object can't be acomplised by changing .rotation > : that will only rotate the children, not the parts drawn in .draw() > > > Anchors and Cocos Sprites: > > Sprites has an aditional anchor property, the .image_anchor > Also, the Sprite's __init__method has an 'anchor' keyword param > The 'anchor' keyword param is assigned to .image_anchor, with ( > image.width/2, image.height/2) as the default value > Then the property .anchor is set to (0,0), wich means > 0 = anchor_x = anchor_y = transform_anchor_x = transform_anchor_y = > children_anchor_x = children_anchor_y > > The behavoir is like this: > > 1. If the properties .anchor , .transform_anchor , .children_anchor are > unmolested (ie remains at (0,0)), then asignations to .image_anchor will > a) offset the image view position > b) do not offset any eventual child position > c) The object can be rotated an angle alpha by obj.rotation = alpha. The > rotation center will be object.position , both for the image and childs. > Remark: if the object is subclass of Sprite, and have childs, then the > relative position of child with respect to image would not be invariant by > changes in .image_anchor. > > 2. In the case when any cocosnode anchor has nonzero value, things further > complicates, like having image and childs rotating around diferent centers > when asigning to .rotation > This seems too complicated to be desired behavoir. It is a bug? > > > > ---------------------------------------------------------------------------------------- > > > > > The above seems too heterogeneous. > Is there a point of view for wich this dispersion is worthwhile ? > > > What if Cocos changes to strongly push the Type 1 ? I mean this: > > 1. in CocosNode.visit() , the code will change to call .draw() with the > .transform() already applied. > Reflect this change updating the .draw() description > Reflect this change by updating the name of .children_anchor ; now the ofset > is applied for the entire object, not only the childs. > > 2. Refactor cocosnode.Sprite so that anchor usage is in accordance with > CocosNode > > > > Let aside the work needed to refactor, > it sounds as a good change ? > any drawbacks to this change ? > it is a direction that the developers would consider to be going ? > > -- > Claudio Canepa > > [1] http://cocos-discuss.googlegroups.com/web/anchors_interactive_test.zip > > ------------ >
Ok. ive read this. Ill have a response. i almost promise you that. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cocos2d discuss" 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/cocos-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
