I have this setup:
A layer has a sprite as a child. The sprite has this code in its init method:
id fadeOut = [CCFadeOut actionWithDuration:1.0f];
id death = [CCCallFunc actionWithTarget:self selector:#selector(die)];
self.deathAction = [CCSequence actions:fadeOut, death, nil];
[self runAction:deathAction_];
The death action calls the sprite's 'die' method in which its status is changed to 'dead'.
On its update method the layer checks all children and removes the ones wich are 'dead' with:
[self removeChild:child cleanup:YES];
The problem is that the child sprite still has retaincount of 2 after this line. As I understand it is kept by CCCallFunc. If I omit this deathAction and instead remove the sprites that have zero opacity (when they are faded), the code is working and the dealloc method gets called.
How should I remove the sprite by using an action properly?
You don't show all of your code. But it seems you are keeping a reference to the action and your likely forgetting to release that.
retainCount is notoriously unreliable : link so please don't use it and certainly don't count on it to be accurate.
Related
I don't get why this code is incorrect...
DeadPanelLayer* deadPanelLayer = [DeadPanelLayer node];
[(CCScene*)self.parent addChild:deadPanelLayer z:2];
DeadPanel is a layer that I want to add on the Scene running from another layer
any idea why my layer is not loaded?
Edit: the game is not crashing, but the new layer does't show up. I tried to even move the objects on the scene and layer just to make sure it is not displaying due zindex hierarchic
but still...
I tried to add a method on Scene to add the layer in case it is called from parent:
[(GameScene*)self.parent showDeadPanel];
and even get current scene from Director
[[CCDirector sharedDirector] runningScene]
and it doesn't work either
Currently, I have a game where an object determines a point to go to. It then calculates a path to that point and constructs one long CCMoveTo animation to get to that point. With this method, the animation seems very smooth and continuous.
I am now trying to break this one long CCMoveTo to multiple CCMoveTo leveraging the update method that gets called periodically. I want to do this because at each node of the path that the objects passes through, there might be a distraction and I want my object to be able to act on that. So this is what I am doing:
- (void) update: (ccTime) dt
{
if(![self isWalking]){
CGPoint nextNode = [_path objectAtIndex:(_currentPathIndex%[_path count])];
_currentPathIndex++;
NSMutableArray *actions = [[NSMutableArray alloc] init];
[actions addObject:[CCCallBlockO actionWithBlock:^void(id obj) {
[(Monkey *) obj setIsWalking:NO];
} object:self]];
[self moveTo: nextNode withCallbacks: actions];
}
}
Note: that I set isWalking to NO as a callback when the object has completely reached the destination node. This will let it calculate the next node to go to and construct that animation. Without this, the object would try to runAction in the middle of an ongoing CCMoveTo action. The problem with this method is that the movement does not seem smooth and continuous anymore. There seems to be a lag at the end of each CCMoveTo animation
Anybody has any clue on how to fix this?
That's a side effect of cocos2d's CCAction system respectively the CCScheduler.
There will always be a 1-frame delay because when an action stops, it won't do any work in the current frame: it made the last position update in the previous frame, and in the current frame it does no longer exist as a running action.
If you now run another move action in a scheduled method, that action won't begin updating until the next frame because it will schedule itself to receive updates. And updates that are scheduled while cocos2d's CCScheduler performs updates will not be run until the next frame, due to the fact that you can't modify an array during enumeration.
My advise is always to avoid using CCMove* actions for gameplay purposes, and instead manually update position of game objects. It's easy enough to do, and if you need a code example, look inside the CCMoveTo class.
A workaround would be to extend the distance of the CCMoveTo and replace the action shortly before it completes. Though that'll be a hack and may actually be harder to implement correctly than manual position updates.
PS: That's an issue I have addressed in the action model of KoboldTouch. It implements its own action system, with more lightweight and reusable actions.
Just wondering how I can get the position of a node that will be the current position if it is not moving, but if there is a CCMoveTo action being performed I need the position it is moving to.
Is this already built in or will I have to implement it myself, if so any suggestions on how I would go about it?
Thanks for the help,
Ben
Usually, if there are already built-in methods that "single-lined-ly" give you the information that you want, for example using [[CCDirector sharedDirector] running Scene] to get the current scene, it is a bad idea to create an ivar to keep track of the information for later querying.
But if using the built-in methods are hackish or long-winded, with no guarantee for accuracy, then it is better to create an ivar.
So, just create an ivar on that node that you update whenever the position is changed or a CCMoveTo action is assigned.
Note: I'm calling the -(NSArray *)getActionsByTarget:(id)target method as hackish because it is not guaranteed that you can find the CCMoveTo action in it. The action might be embedded deep in [CCSequence actions:[CCFadeIn ...], [CCSpawn actions:[CCCallBlock actionWithBlock: ^{ [self runAction:[CCSequence actions:[CCDelay ...], [CCMoveTo ...], nil]]; }], [CCMoveTo ...], nil], [CCMoveTo ...], nil]. Now how in the world you would implement the logic that can correctly find all the three CCMoveTo and deduce which of it will give the final position?
You need to have any CCMoveTo action object, and then search it by CCNode object that you want to get the position of. If you found the CCMoveTo object that is targeted for the CCNode object, then you can get the position from the CCMoveTo object. For example, add -(NSArray *)getActionsByTarget:(id)target method or something like that to CCActionManager class.
Or, create derived class from CCNode to have the position of the CCMoveTo action.
Can anyone tell me how to vibrate/shake CCSprite in cocos2d???plz give me some example.
If the object is static you could create a CCSequence of MoveTo actions - pixel or two to the one side and pixel to the other of the real position and repeat it with CCRepeat how many times you need or use CCRepeatForever and remove action by tag with CCActionManager method removeActionByTag:(int)tag target:(id)target when some event occur.
I have 3 question.
How to keep fps rate constant(almost) in cocos2d.When lots of CCSprite created and removed within a small interval like (5-8) per second is it possible to keep frame rate lmost constant??
Is [self removeChild:sprite cleanup:YES] is enough or i should also use
CCTexture2D *texture = [sprite texture];
[[CCTextureCache sharedTextureCache] removeTexture: texture];
The following Part of code is responsible for my frame drop.How to accomplish same task in better way-
id fadeout = [CCFadeOut actionWithDuration:1.4f];
id call = [CCCallFunc
actionWithTarget:self
selector:#selector(RemoveSmashedSprite:)];
CCSequence* sequence= [CCSequence actions:fadeout, call, nil];
[smash runAction:sequence];
and
-(void)RemoveSmashedSprite:(id)sender
{
CCSprite *sp = (CCSprite *)sender;
[self removeChild:sp cleanup:YES];
}
This is called 5-8 times per second.So the frame rate goes down.Can any one help me.
I am guessing that the "smashed sprite" in question is probably one of a number of sprites visible on the screen, more than likely sharing the same texture (part of a sprite sheet perhaps, or all the same image, etc?).
If this is the case, I would recommend allocating the number of sprites your games requires to have on screen and rather than "destroy" (remove them, re-create them) you should "re-use them".
Store a reference to all the CCSprite's in an NSMutableArray, populate this array with the number of sprites you think is appropriate (how many sprites are removed per second? how many sprites are added per second? how many sprites are on the screen to start? - use the answers to these questions to determine the most appropriate size of your array).
Then, rather than removing the sprite as a child, simply [sprite setVisible: NO] to hide it, then ... when you need to display a new one on screen, use the next "available" (hidden) sprite in the array (keep track of the last "used" sprite with an index, and simply increment it by 1 to find the next "available". Once the index exceeds the bounds, reset it to 0 - at this point, that sprite should have been "smashed"). Once you have the next "available" sprite, change it's properties (position, scale, texture?, visibility) and apply any actions that are appropriate (don't forget to "stop all actions" on it when "smashing it" - this is what "cleanup: YES" does).
If your game does not allow you to go around in a "circle" like this, because the user decides what may or may not be visible by interacting with the sprites in a varied order then you can store a reference to the "smashed sprites" in a separate array (while keeping them in the original array as well - then you can just pick anyObject from the "unused" array, remove it from that array and then alter it as mentioned above).
This should reduce your frame rate drops dramatically, as you won't be creating and destroying sprites all the time.
Another thing that may be occurring is that you are using different images, and each image is stored separately (image1.png, image2.png, image3.png) and the creation/destruction of these is causing the textures to be removed and re-added ... to resolve this, create a sprite sheet and add the sprite sheet to the Texture Cache, then create your images with 'spriteFromSpriteCacheName:#"image1.png"'