I'm new to cocos2d so I am a bit confused by some things:
The term "child" keeps popping up. At
first I thought it was a subclass,
now I perceive to be a sort of
dynamic instance variable? Can
anyone explain this a bit better?
The class CCSpriteBatchNode is some kind of array of CCSprites
which calls a method that renders
the graphical part of its
elements/children from a sprite
sheet. Is my explanation somewhat
correct?
My book (learning cocos 2d a beginners guide) shows a design
setup where the CCSpriteBatchNode
has several objects as children. I'm
a bit confused because I'm used to
separating drawing classes from
logical classes, AKA "Separation of
concerns". Is this something cocos2d
doesn't abide by and we shouldn't
either?
Parent-child is just a relationship between CCNode and their subclasses in cocos2d. For example if you want a moon turning around the moving planet it is really hard to calculate the absolute path of the moon. But you can make it the child of a planet, and in this case its position, rotation and so on, will be relative to the planet's coordinates. So parent-child relationship is just grouping.
CCSpriteBatchNode is a parent to all its children, but the position of its children are relative to CCSpriteBatchNode parent. Such approach is used because BatchNode is rendering all its children at the same time. That is done to increase performance (no texture switching).
Batch rendering is faster. If your logic is good, CCSpriteBatchNode does not make it worse. For example, you can have a character with a body, arms and legs and you want to render it using BatchNode. You just add the body as a child to BatchNode, then add arms and legs as children to the body. Logic is kept, performance is increased.
Related
I'm newbie with Chipmunk physics and want to make an easy example of polygon explosion.
I started with the SmashLogo demo but in this example the are no explosions, only so much ball movements.
I know how to do polygon collision but my dude is for example how to explode a cube into many little pieces.
Chipmunk doesn't support exploding objects in smaller ones. Your cube should in fact be composed of multiple fragments that will separate upon impact. If your cube is not frozen and is moving, you probably need to add some forces to keep the parts together before impact.
I am making a game using cocos2d and box2d that basically consists of a ball rolling down an infinite hill. My current approach consists of using CCFollow to create the scrolling effect, while iterating through a series of four background images to create continuity. I want the ball to bounce of the hill, so I considered making the hill from two b2Body objects that alternate one another. But this requires manually moving the bodies, which seems to make keeping track of the placement of the corresponding sprite somewhat confusing. Should the hill images even be sprites? Is there a better approach that makes this easier?
Im using Level Helper and SpriteHelper to create my sprites, images, levels and more importantly animations and physics.
Note, by physics i mean the debugdraw you can see on the simulator that is used for collision detection.
I created a swimmer and added physics to this. Done the code so the physics follows the swimmer around the pool as they move. I have now come to animate the swimmer, make the legs kick etc. Now when i load my game and only the first sprite of the animation is the outline for the physics. So i can see the legs kicking on the swimmer but the debugdraw mesh of the physics doesn't animate as well. Now this is not really a problem until for example my swimmer loses their legs (weird game i know). I change the animation to now a swimmer with no legs but again the physics mesh still shows the legs. So any collisions with stuff still happens where the legs were but they shouldnt. This make sense?
Is there a way to update the physics on the new animation or do i need to remove my whole swimmer and draw a new one?
Any help at all would be great. Thanks
This makes sense, since your sprite uses the same box2d mesh in both states. If you want to have a different collision behavior after altering your Sprite, you should assign another (smaller) mesh body.
Note that even in cocos2d side, your sprite still has the same container box with the new animation.
In order to keep using the SpriteHelper functionality you might want to create 2 different sprite-body sets: one with the full body, then after the "accident" replace it with the legless sprite.
Now, gameplay-wise, my opinion is that there shouldn't be any collision for the legs anyway. since they are moving, players will not find it weird to have them not colliding. You could use a mesh body with no legs and use it for both sprites. Except if you want to have different collisions as a gameplay feature (Like giving the player the choice to cut his legs in order to fit in a smaller cave etc)
I have played a little with the particle system in cocos2d-iphone and ParticleDesigner, and I use the CCParticleBatchNode to get good performance as I have many of the same emitter. This works great for explosions, but now I would like to have a exhaust smoke on my ships, but here I am stuck.
I can not add the CCParticleBatchNode to my CCSprite's as they can only be added once and it is reused for all exhausts, but how do I then make my CCParticleBatchNode follow or stick to my CCSprite?
Also the exhaust particle system I have made with ParticleDesigner has a gravity/direction, but when my CCSprite's always are moving then is this wrong, should they just emit particles in one place and the movement of the emitter will create the trail, or?
How is this done guys?
of course you cannot add the ParticleBatchNode to the sprite (the same way you cannot add a particle if the sprite were used in a SpriteBatchNode)
to solve similar problems i use to inherit a class from ccsprite, say MySprite, and then override the position setter
-(void) setPosition:(CGPoint) position {
myParticleEmitter.position = position; //+ offsets if needed
[super setPosition:position];
}
You need a pointer to the emitter, i usually keep a weak reference to the emitter from MySprite, and automatically every time i set and change a position the emitter follows.
I didnt quite get the second part of your question, but i think you can just update the gravity direction of the emitter when your sprites moves / rotate, overriding also setRotation if needed
I have been experimenting with the box2D sample project within cocos2D for the iPhone and am wondering if box2D is the appropriate engine to use to make a moving object "stick" to a stationary object when the moving object is finished moving in a certain direction.
Here is a simplification of what I am trying to achieve: I have MovingObject, a dynamic rigid body, that moves vertically against gravity when enough force is applied to it. As MovingObject moves, it may overlap a static object, StationaryObject. When gravity diminishes MovingObject's velocity to zero such that it is no longer moving, I would like to have MovingObject remain where it is ONLY if it overlaps StationaryObject. If the object's do not overlap, MovingObject should start to move back down towards the ground per the force of gravity. During that descent, if MovingObject at any time overlaps StationaryObject, it should stop its descent and remain in that location as if it is stuck on StationaryObject.
I am able to get MovingObject to move per the forces I am applying to it, but not really sure how to make it stop and stay there once it reaches the top of its ascent, assuming it is overlapping StationaryObject.
Currently, I am experimenting with simple square/box objects but eventually both MovingObject StationaryObject will be defined as very different complex polygon shapes.
Thanks in advance for any insights and/or suggestions for achieving this.
Sounds like you'll want to change the type of fixture used for "MovingObject" while it "ascending" and then change it when it is "descending" so that it reacts differently (to overlaps).
by "overlap" it sounds like you want to achieve something similar to "one sided platforms" in a platform game (ie; Mario Bros.) - I would recommend looking into the solutions for one-sided platforms for starters.