Saturday, July 2, 2022
HomeGame Developmenttake away a participant when lifeless with out null pointer crash -...

take away a participant when lifeless with out null pointer crash – cocos2d-x


Hello,
I’ve a way that verify collisions between the participant sprite and the enemies.

void CollisionSystem::runPlayerCollision(Vector<Sprite*>& enemies, Sprite* playerSprite)
{
    // I've a loop that checks the collisions and if a collisio is discovered it does this
    CCLOG("Collision discovered");
    playerSprite->removeFromParentAndCleanup(true);
    playerSprite->launch();
}

My understanding is that removeFromParentAndCleanup doesn’t delete the pointer. So I add a launch() to delete it.
Now that is what I don’t get. In the principle replace() loop of the sport I added this

if (GameGlobals::playerSprite != nullptr)
{
     CCLOG("sport operating");
     collisionSystemInstance->runPlayerCollision(GameGlobals::enemies,  Sport:Globals::participant)
}

The output is

sport operating
sport operating
sport operating
sport operating
sport operating
"Collision discovered"

Exception thrown: learn entry violation.
playerSprite->**** was 0xDDDDDDDD.

So, the collision methodology is doing the work proper as a result of the video games retains operating whereas the playerSprite exists. And when there’s a collision, the LOG “Collision discovered” proves it’s working okay, and therefor it deletes the playerSprite pointer. The error playerSprite->**** was 0xDDDDDDDD occurs inside
collisionSystemInstance->runPlayerCollision(GameGlobals::enemies, Sport:Globals::participant), however why is it operating that, if I said to operating solely if the GameGlobals::playerSprite != nullptr??

The error implies that playerSprite was delete proper? which is what I need when it collides. However the situation to run the collision methodology is that the playerSprite exists, and it doesn’t, so why is it operating it? I’m confused.

R


That’s not right.

It’s crashing since you’re attempting to free an object that has already been freed.

A name to launch() must match a name to retain(). Assuming you’re simply utilizing the Sprite::createXXXX() strategies, the sprite is ready to auto-release, that means it’s added to the auto-release pool which is checked each loop. When the sprite is faraway from a node (through playerSprite->removeFromParentAndCleanup(true); or just playerSprite->removeFromParent();, then its reference rely reduces by 1. If the counter is 1, then given it’s within the auto-release pool, will probably be freed.

The one time you ought to be calling launch() on it explicitly is when you known as retain() on it, or created it with a new and by no means set it to be auto-released through a name to autorelease().

You, fairly actually, have the supply code proper there in entrance of you. Utilizing the debugger might have led you to the supply of this situation in a short time. Maybe it’s greatest you assessment the code associated to the retain/launch/autorelease performance to get a greater understanding of the way it all works.

I ended up creating a world variable known as gameIsStopped.So the replace() loop solely begins whether it is fasle.
When a collision occurs the variable is ready to true, so replace() received’t preserve going. Unsure if that is one of the best ways however I’ve seen related workflows to pause the sport, restart, and many others…
Principally utilizing world bool variables which might be set relying on a particular situation. And people variables arre utilized in the principle replace() to carry out diferente operations like sport over, lowering lives, shifting to subsequent scene, and many others… Appears alright to me.

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments