I'm in the final stages of releasing my first game, and after running Instruments:Leaks & Allocations, I see that I have a leak in my code caused by a retain cycle. I am using Cocos2d 2.0, and compiling my app with ARC, and I should mention that I started the project pre-ARC, and used the Xcode refactoring tool to convert it. My game has several animated objects per screen, each of which has a small number (1-7) of animated "variants" of that object (i.e. the barn opens to show a horse once and a zebra another time). I have a class that represents each animation, and another class for each variant. The variant creates a CCAnimation from a sequence of frames, and then creates an action which will be run whenever a touch event is received in the correct region. This action is what is causing my retain cycle. My declaration for the action ivar looks like this:
#interface AnimationVariant : NSObject
{
#private
CCAction* _action;
...
}
#property (readonly, nonatomic) CCAction* action;
...
-(void) setupActionWithMask:(int)mask
cycles:(int)cycles
hasScale:(bool)hasScale
scale:(float)scale
masterScale:(float)master_scale
animationFrames:(NSArray*) frames
duration:(float)duration
andBlock:(VoidBlock)block;
#end
In the implementation of the setupActionWithMask method, I build up an NSMutableArray of CCActions, actionList. The sequence of CCActions varies depending on args, but usually it looks something like this:
[actionList addObject:[CCScaleTo actionWithDuration:0.0f scale:scale]];
[actionList addObject: [CCAnimate actionWithAnimation:animation] ];
[actionList addObject:[CCScaleTo actionWithDuration:0.0f scale:master_scale]];
[actionList addObject: [CCCallBlock actionWithBlock:block]];
And I create the action like this:
_action = [CCSequence actionMutableArray:actionList];
The consuming class creates an AnimationVariant instance, sets its properties, calls setupActionWithMask, and passes in a block it wants executed when the action completes. When the consuming class wants to play the animation variant, it does so like this:
[self runAction: variant.action];
I tried declaring _action as:
CCAction* __unsafe_unretained _action;
which of course broke the retain cycle, but the action is destroyed, and is no longer around when it's needed (which is what you would expect, since __unsafe_unretained does not retain). I know __weak is the recommended solution, but as I am targeting iOS 4 and up, I don't think it's available to me.
I had another retain cycle in my code, exactly like this one, also caused by retaining (automatically with ARC of course) a CCSequence containing a CCCallFunc/CCCallBlock. I solved that one by just re-creating it whenever I needed it, which I could also do in this case, but these animations are triggered maybe a couple hundred times in the whole game, so I was hoping to follow the recommended Cocos2d Best Practices and retain the actions.
Thanks!
Retaining actions is not best practice. It's not even good practice. Though it comes heavily recommended by many, quite unfortunately.
Retaining actions works in many cases, but fails in others causing objects to leak. I'm guessing your case may be one of those.
Since you're targeting iOS 4 you can't use weak references. But you should probably reconsider unless you have to target the remaining few 1st and 2nd generation devices. Otherwise, google for iOS 5 adoption rate. The handful of devices that haven't been updated yet are well below a reasonable threshold, in particular if you consider that those users probably don't buy (many) apps (anymore) anyway.
Since you meantioned CCCallFunc, make sure you don't use them and replace with CCCallBlock. CCCallFunc are not safe to use with ARC, in particular whenever you have to __bridge_transfer cast a data object to void* (also bad practice).
There's always the chance that the necessary bridge cast back to the original object never occurs, and then ARC doesn't get the chance to clean up that object. With CCCallFunc this can happen when you run a call func action but the action is stopped before the callback selector is called, for example by changing scenes or stopping the action/sequence.
Cocos2D is also prone to retain cycles if you don't follow this rule:
any node should only retain another node that is one of its children or grandchildren
In all other cases (ie node retains (grand)parent or sibling node) you must make sure to nil those references in the -(void) cleanup method. Doing so in -(void) dealloc is too late because the object will never get to dealloc when there's a retain cycle.
Related
I’m using Cocos2d v3 and want to change a body from dynamic to static after colliding with another body. At the moment I’ve got:
-(void)ccPhysicsCollisionPostSolve:(CCPhysicsCollisionPair *)pair static:(CCNode *)nodeA wildcard:(CCNode *)nodeB
{
_player.physicsBody.type = CCPhysicsBodyTypeStatic;
}
or
-(BOOL)ccPhysicsCollisionPreSolve:(CCPhysicsCollisionPair *)pair static:(CCNode *)nodeA wildcard:(CCNode *)nodeB
{
_player.physicsBody.type = CCPhysicsBodyTypeStatic;
return YES;
}
but neither works. I get the error:
Aborting due to Chipmunk error: This operation cannot be done safely during a call to cpSpaceStep() or during a query. Put these calls into a post-step callback.
Failed condition: !space->locked
I then tried to make a joint at the point of collision but it doesn’t work right.
Is there a way to change a body to dynamic as soon as it collides in v3? I can do it in later versions using Box2D. I want to stop gravity and other forces so it doesn’t move. I want to make it look like it stuck to a surface.
Read a little on post-step callbacks but i'm unfamiliar with how to use them.
Any help would be appreciated.
As the error message states, you need to implement a post-step callback.
To do this on Cocos2d 3.0 and with Objective Chipmunk you first need to import a new header file to access advanced chipmunk properties:
#import "CCPhysics+ObjectiveChipmunk.h"
Then add the callback in your collision handler:
-(void)ccPhysicsCollisionPostSolve:(CCPhysicsCollisionPair *)pair static:(CCNode *)nodeA wildcard:(CCNode *)nodeB
{
[[_physicsNode space] addPostStepBlock:^{
_player.physicsBody.type = CCPhysicsBodyTypeStatic;
} key:_player];
}
Note that I assume you have access to your CCPhysicsNode in _physicsNode.
The Chipmunk Space of CCPhysicsNodeis locked while the a physics step is calculated. During a calculation of a step collisions are resolved and objects are moved around - changing the body type during this calculation could result in unexpected behaviour.
Therefore you add the postStepBlockcallback. This is a place where a body type can be safely changed.
The key value you pass into the callback is used to ensure that the code is only called once (especially useful when removing objects, but it also makes sense in this case).
If also added an example implementation: https://www.makegameswith.us/gamernews/367/make-a-dynamic-body-static-in-cocos2d-30-with-chi
I am not sure how you are supposed to control a player character in Bullet. The methods that I read were to use the provided btKinematicCharacterController. I also saw methods that use btDynamicCharacterController from the demos. However, in the manual it is stated that kinematic controller has several outstanding issues. Is this still the preferred path? If so, are there any tutorials or documentations for this? All I found are snippets of code from the demo, and the usage of controllers with Ogre, which I do not use.
If this is not the path that should be tread, then someone point me to the correct solution. I am new to bullet and would like a straightforward, easy solution. What I currently have is hacked together bits of a btKinematicCharacterController.
This is the code I used to set up the controller:
playerShape = new btCapsuleShape(0.25, 1);
ghostObject= new btPairCachingGhostObject();
ghostObject->setWorldTransform(btTransform(btQuaternion(0,0,0,1),btVector3(0,20,0)));
physics.getWorld()->getPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
ghostObject->setCollisionShape(playerShape);
ghostObject->setCollisionFlags(btCollisionObject::CF_CHARACTER_OBJECT);
controller = new btKinematicCharacterController(ghostObject,playerShape,0.5);
physics.getWorld()->addCollisionObject(ghostObject,btBroadphaseProxy::CharacterFilter, btBroadphaseProxy::StaticFilter|btBroadphaseProxy::DefaultFilter);
physics.getWorld()->addAction(controller);
This is the code I use to access the controller's position:
trans = controller->getGhostObject()->getWorldTransform();
camPosition.z = trans.getOrigin().z();
camPosition.y = trans.getOrigin().y()+0.5;
camPosition.x = trans.getOrigin().x();
The way I control it is through setWalkDirection() and jump() (if canJump() is true).
The issue right now is that the character spazzes out a little, then drops through the static floor. Clearly this is not intended. Is this due to the lack of a rigid body? How does one integrate that?
Actually, now it just falls as it should, but then slowly sinks through the floor.
I have moved this line to be right after the dynamic world is created
physics.getWorld()->getPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
It is now this:
broadphase->getOverlappingPairCache()->setInternalGhostPairCallback(new btGhostPairCallback());
I am also using a .bullet file imported from blender, if that is relevant.
The issue was with the bullet file, which has since been fixed(the collision boxes weren't working). However, I still experience jitteryness, unable to step up occasionally, instant step down from to high a height, and other issues.
My answer to this question here tells you what worked well for me and apparently also for the person who asked.
Avoid ground collision with Bullet
The character controller implementations in bullet are very "basic" unfortunately.
To get good character controller, you'll need to invest this much.
I'm designing a new power-up system for a game I'm creating. It's a side scroller, the power ups appear as circular objects and the player has to touch / move through them to pick up their power. The power up then becomes activated, and deactivates itself a few seconds later. Each power-up has its own duration defined. For simplicity's sake the power ups are spawned (placed on the screen) every X seconds.
I created a PowerUpManager, a singleton whose job is to decide when to create new power ups and then where to place them.
I then created the Powerup base class, and a class that inherits from that base class for every new Powerup. Every Power-up can be in one of three states: Disabled, placed on the screen, and picked up by the player. If the player did not pick up the power up but moved on, the power up will exit the screen and should go back from the placed state to the disabled state, so it can be placed again.
One of the requirements (that I) put in place is that there should be minimal code changes when I code up a new Power up class. The best I could do was one piece of code: The PowerUpManager's constructor, where you must add the new power-up to the to the container that holds all power-ups:
PowerupManager::PowerupManager()
{
available = {
new PowerupSpeed(),
new PowerupAltWeapon(),
...
};
}
The PowerUpManager, in more details (Question is coming up!):
Holds a vector of pointers to PowerUp (The base class) called available. This is the initial container that holds one copy of each power up in the game.
To handle the different states, it has a couple of lists: One that holds pointers to currently placed power ups, and another list that holds pointers to currently active power ups.
It also has a method that gets called every game tick that decides if and where to place a new power up and clean up power ups that weren't picked up. Finally it has a method that gets called when the player runs into a power up, that activates the power up (Moves it from the placed to the active list, and calls the power up's activate method).
Finally, once you understand the full picture, the question:
I needed a way for client code to ask if a particular power-up is currently active. For example: The player has a weapon, but there is a power up that replaces that weapon temporarily. Where I poll for input and recognize that the player wants to fire his weapon, I need to call the correct fire method - The alternative weapon power up fire method, and not the regular weapon fire method.
I thought of this particular demand for a while and came up with this:
template <typename T>
T* isActivated() // Returns a pointer to the derived Powerup if it exists in the activated list, or nullptr if it doesn't
{
for(Powerup *i : active) // Active is a list of currently active power ups
{
T *result = dynamic_cast<T*>(i);
if(result)
return result;
}
return nullptr;
}
So client code looks like this:
PowerUpAltWeapon *weapon = powerUpManager->isActivated<PowerUpAltWeapon>();
if(weapon)
...
I thought the solution is elegant and kind of neat, but essentially what it is is trying to convert a base type to a derived type. If that doesn't work, you try the next derived type... A long chain of if / else if, it's just disguised in a loop. Does this violate the guideline that I just described? Not casting a base type to all of its derived types in a long chain of if / else if until you get a hit? Is there another solution?
A secondary question is: Is there a way to get rid of the need to construct all the different power ups in the PowerupManager constructor? That is currently the only place you need to make a change if you want to introduce a new power up. If I can get rid of that, that'd be interesting...
This is based on your design, but if it was me I choose an ID for each PowerUp and a set of IDs in the client, and each time a user posses a PowerUp that ID will be added to its set and ... you know the rest. Using this technique I can do fast look up for every PowerUp and avoid dynamic_cast:
std::set<PowerUp::ID> my_powerUps;
template< class T > bool isActivated() {
return my_powerUps.find( T::id() ) != my_powerUps.end();
}
And about your second question, I have a similar program that load some plugins instead of PowerUp, I have a pure virtual base class that contain all methods that required by that plugin and implement it in shared modules and then at startup I load them from an specific folder. For example each shared module contain a create_object that return a plugin* (in your case PowerUp* of course) and then I iterate the folder, load modules and call create_object to create my plugins from them and register them in my plugin_manager
I'm working on a game engine in C++ using Lua for NPC behaviour. I ran into some problems during the design.
For everything that needs more than one frame for execution I wanted to use a linked list of processes (which are C++ classes). So this:
goto(point_a)
say("Oh dear, this lawn looks really scruffy!")
mowLawn()
would create a GotoProcess object, which would have a pointer to a SayProcess object, which would have a pointer to a MowLawnProcess object. These objects would be created instantly when the NPC is spawned, no further scripting needed.
The first of these objects will be updated each frame. When it's finished, it will be deleted and the next one will be used for updating.
I extended this model by a ParallelProcess which would contain multiple processes that are updated simultaneously.
I found some serious problems. Look at this example: I want a character to walk to point_a and then go berserk and just attack anybody who comes near. The script would look like that:
goto(point_a)
while true do
character = getNearestCharacterId()
attack(character)
end
That wouldn't work at all with my design. First of all, the character variable would be set at the beginning, when the character hasn't even started walking to point_a. Then, then script would continue adding AttackProcesses forever due to the while loop.
I could implement a WhileProcess for the loop and evaluate the script line by line. I doubt this would increase readability of the code though.
Is there another common approach I didn't think of to tackle this problem?
I think the approach you give loses a lot of the advantages of using a scripting language. It will break with conditionals as well as loops.
With coroutines all you really need to do is:
npc_behaviour = coroutine.create(
function()
goto(point_a)
coroutine.yield()
say("Oh dear, this lawn looks really scruffy!")
coroutine.yield()
mowLawn()
coroutine.yield()
end
)
goto, say and mowLawn return immediately but initiate the action in C++. Once C++ completes those actions it calls coroutine.resume(npc_behaviour)
To avoid all the yields you can hide them inside the goto etc. functions, or do what I do which is have a waitFor function like:
function waitFor(id)
while activeEvents[id] ~= nil do
coroutine.yield()
end
end
activeEvents is just a Lua table which keeps track of all the things which are currently in progress - so a goto will add an ID to the table when it starts, and remove it when it finishes, and then every time an action finishes, all coroutines are activated to check if the action they're waiting for is finished.
Have you looked at Finite State Machines ? If I were you I wouldn't use a linked list but a stack. I think the end result is the same.
stack:push(action:new(goto, character, point_a))
stack:push(action:new(say, character, "Oh dear, this lawn was stomped by a mammoth!"))
stack:push(action:new(mowLawn, character))
Executing the actions sequentially would give something like :
while stack.count > 0 do -- do all actions in the stack
action = stack:peek() -- gets the action on top of the stack
while action.over ~= true do -- continue action until it is done
action:execute() -- execute is what the action actually does
end
stack:pop() -- action over, remove it and proceed to next one
end
The goto and other functions would look like this :
function goto(action, character, point)
-- INSTANT MOVE YEAH
character.x = point.x
character.y = point.y
action.over = true -- set the overlying action to be over
end
function attack(action, character, target)
-- INSTANT DEATH WOOHOO
target.hp = 0
action.over = true -- attack is a punctual action
end
function berserk(action, character)
attack(action, character, getNearestCharacterId()) -- Call the underlying attack
action.over = false -- but don't set action as done !
end
So whenever you stack:push(action:new(berserk, character)) it will loop on attacking a different target every time.
I also made you a stack and action implementation in object lua here. Haven't tried it. May be bugged like hell. Good luck with your game !
I don't know the reasons behind you design, and there might be simpler / more idiomatic ways to it.
However, would writing a custom "loop" process that would somehow take a function as it's argument do the trick ?
goto(point_a)
your_loop(function ()
character = getNearestCharacterId()
attack(character)
end)
Since Lua has closures (see here in the manual), the function could be attached to your 'LoopProcess', and you call this same function at each frame. You would probably have to implement your LoopProcess so that that it's never removed from the process list ...
If you want your loop to be able to stop, it's a bit more complicated ; you would have to pass another function containing the test logic (and again, you LoopProcess would have to call this every frame, or something).
Hoping I understood your problem ...
Recently I was listening to a tech talk on clean coding. The speaker was a test engineer, who emphasized on avoiding the "if" statements in the code and use polymorphism as much as possible. Also he advocated against global states.
I quite agree with him, yet i need a clarification on replacing the global state and "if" statement using polymorphism for the below scenario,
I have 3 states in my document. I want to change the state of the UI components based on the document state. Right now, i use "if" blocks and an enumeration type holding the current state of document to transition the states of UI components.
eg:
enum DOC_STATE
{
DOC_STATE_A = 0,
DOC_STATE_B,
DOC_STATE_C
};
void QMainWindow::handleUi(_docState)
{
switch(_docState)
{
case (DOC_STATE_A):
{
menu.disable();
....
}
case (DOC_STATE_B):
{
menu.enable();
...
}
case (DOC_STATE_C):
{
...
}
}
I think i can have separate child classes for each state and have the handleUI() method in each class. Calling handleUi() method calls the right method call. But say i maintain these objects in my doc, how do i switch from one object to other each time there is a transition in state?
In other words, how to handle UI transition by tracking the change in state of document without using a global state and "if" or Switch statements?
I use Qt. Thanks.
If you are using Qt, take a look at The Qt State Machine Framework and the State Machine Examples. No need to re-invent the wheel when your framework already provides a sports car :)
I don't think I understand the problem because the answer is too trivial: you replace the pointer to your state instance with a new state instance and discard the old one.