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
------------
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
