Looking for the *right* way to delete a CCSprite!

Hey all,

New to Cocos and trying to safely delete any CCSprite that exits the screen. I’ve got the logic that checks if the sprite is on the screen, but I don’t know how to safely delete it.

Bead extends CCSprite and is called like this

Bead* bead1 = Bead::create(size.width*2, size.height*2, “1”);

Meanwhile in my Bead.cpp…

Bead* Bead::create(int x, int y, CCString n)
{

Bead *bead = new Bead();
if (bead && bead~~>initWithFile)
{
bead~~>autorelease();
bead~~>setPosition);
bead~~>name = n;
bead~~>scheduleUpdate;
return bead;
}
CC_SAFE_DELETE;
return NULL;
};

The reference that I have to the Bead looks like this…
Bead* aBead = dynamic_cast<Bead*>(movingBeads->objectAtIndex(i));
I’ve tried aBead~~>release(); and delete aBead, but nothing seems to work right. Any help would be great.

I assume you have added the bead to a CCNode or CCLayer?

Have you tried removeFromParent / removeFromParentAndCleanup?
Or maybe this~~>removeChild?
bead~~>release would only be needed if you did a bead->retain.

Yes, the bead is added to a CCLayer, and yes removeFromParent makes the bead disappear, but I feel like it is not completely removed from the memory for the following reason. My bead also extends CCTargetedTouchDelegate and I register it in the onEnter

void Bead::onEnter() {
CCDirector::sharedDirector()->getTouchDispatcher()->addTargetedDelegate(this, 0, false);
CCSprite::onEnter();
};

even after doing a removeFromParent or removeChild the invisible bead still registers touches? If I try to manually call onExit the app crashes.

So I feel like just removing the bead from the layer doesn’t actually free up the memory, but I don’t completely grasp the whole memory allocation deal.

So I guess my new question is does removing a sprite from a layer actually free up the memory or just remove it visually, and also do I need to do something to unregister the bead with the touch handler.

In your code, you mention that : movingBeads->objectAtIndex(i)

movingBeads is a CCArray right ? When you add an object to a CCArray, it gets retained. You need to remove it from the CCArray to have it released.

If it’s not that, check for every place where you or an object you use retain your bead, and check there is an associated release.

Since you use a create method (which means, since the method is done properly, that the ref count is at 0 at the end), you shouldn’t have to release it anywhere, unless you retain it : what keeps it alive is the fact it is inside arrays : at least 2 : the CCLayer parent, and your movingBeads array.

Removing a sprite from a layer just remove it visually. Your bead will be released when the refCount is at 0 (except if it’s an autorelease and you retain it in the scope).

If you have registered your sprite with the touch dispatcher, you must unregister the sprite using CCTouchDispatcher::removeDelegate(Bead). You may want to add this code to the onExit() method of your Bead class.

Yes movingBeads is an array. I removed the bead from the array and the layer and it seems to be completely gone. Thank you guys. It works fine, but Francois, you said “except if it’s an autorelease and you retain it in the scope”. I just took the autorelease thing from a tutorial and don’t really know what it does. At what point would an autorelease object get released, and what do you mean by retain it in the scope. Like bead->retain()? Also should I even mess with autorelease? What is its benefit?

The autorelease basically mean “release it after a little while”. That means even if the refcount reach 0, the object won’t get freed right away : you have some time to retain it later (and yes, this means bead->retain(), or adding it to an array, or whatever may retain it).

It’s essential for a few methods which should not retain ownership of the object, but at the same time can’t release it, because else the object is freed right away. A create method is a good example of that situation.

If that’s not clear enough, search about reference counting : that’s the model being used, which is exactly the same Objective-C use.