On Wed, Sep 25, 2013 at 10:39 PM, Paul Pittlerson <[email protected]>wrote:
> Ok thanks for clearing that up. I have some more questions: > > Anchors seems to be different depending on the type of layer. For example > a ColorLayer will be created with the anchor=0, 0 but a Sprite will have > it's anchor in the center. Is there any reason for this inconsistency or is > it advisable to subclass Sprite if I'm planning to use a lot of them? > Maybe at some time there was some reason for the difference, today I think probably not. anchor is the reference point for the scale and rotate operations, thats what defines what value is adequate. Whit the default anchor, the sprite will rotate around its center, if you want to rotate around a corner, you change the anchor. You can change the anchor at any time. > > Basic Layer automatic functions are still unclear. An example is the thing > we discussed just before this post. > Do small samples, think about simple variations and the try to code them. > Another example is that I am often unsure if I can add some code (about > managing other Layers) to the __init__ function, or if I should instead put > that same code in on_enter. > Not sure what you mean by 'about managing other layers' > It has caused some trouble when setting up a scene with multiple > components. > > Some factor that influence whether some code should be in a CocosNode __init__ or on enter: 1) __init__ will run once in the lifetime of the object (duh!) so if you think some activity will need to be executed more than one time, his code cannot be in __init__ 2) *manually* registering as listener should always be done in on_enter (and a matching de-registering should be in on_exit) 3) if some piece of code needs info not available at __init__ time, then you will need to find another place. Sometimes it can be in on_enter, sometimes you can define some cocos actions to perform the task 4) pieces of codes that need to interact with the parent node (or other ancestor) cannot be in __init__, at this time it is unknown the parent 5) containers, be it stock python objects as lists, sets,... and Layers with acts as simple containers, it usually convenient to create in __init__ , by example list of enemies, list of powerups actors,... . Filling those containers may or not be convenient to fill in __init__ > As a note I'm really liking cocos because it's so easy to create a basic > system and see the result immediately. I also really like the object > oriented design which I did not experience in working with Pygame first. > However I'm still unsure of many things because I'm new to python and > pyglet / cocos. Would you mind taking a look at my whole program and tell > me if there are mistakes I'm not even realize I'm making? > > > You can't expect a detailed review. If is not too big and it runs, I can give a look and tell if something pops as strange. No promises. If you want to to try, upload somewhere, better one of googlecode, bitbucket, launchpad or github. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
