A fast, easy to use, free, and community supported 2D game engine
trump-card
Member
Hello!
Very simple question. I'm confusing
Example:
@class GameLayer;
@interface GameScene : Scene
{
GameLayer *layer;
}
@property (nonatomic, retain) GameLayer *layer;
@end
@interface GameLayer : Layer
{
}
@end
@implementation GameScene
@synthesize layer;
- (id) init
{
layer = [GameLayer node];
[self addChild:layer];
}
- (void) dealloc
{
[layer release];
}
@endQuestion: Should I do [layer release] in this example?
also i am pretty sure your dealloc method should have
- (void) dealloc
{
[super dealloc];
}
Ok, I'll try to explain some of this (though you should read apples documentation on retain/release, its very good and very detailed.
1) Pablo is right, you should call [super dealloc] in the dealloc method.
2) You do not actually need your layer to be a property, your code will fully work without it. You only need it if you access the layer from outside of gameScene.
3) Assuming you keep your code as it is, here is what happens in your code:
layer = [GameLayer node]; // the node function creates a GameLayer for you which will be autoreleased when the end of init is reached. So current retainCount of layer is 1.
[self addChild:layer]; // You add the layer to the cocos2d scene, cocos claims the layer and retains it, retain count is now 2.
} // the end of the init function is reached, layer is autoreleased. The retain count is now 1 again (because cocos is still retaining)You now no longer own layer! Only cocos owns it. If you call [gameScene removeObject:layer] somewhere the retain count will reach 0, and the layer will be dealloced. If you then call [layer release]; your retain count will reach -1 and your app will crash.
Heres whats wrong: if you want to own the layer using the property system, you need to not only declare layer as a property, but use it as a property. if you do self.layer = [GameLayer node]; (notice the self!) you use layer as a property and not as an objective C object. Now internally, because you said @property (nonatomic, [strong]retain[/strong]) GameLayer *layer;, cocoa will convert self.layer = [GameLayer node]; into
layer = [GameLayer node];
[layer retain];As you now own the object correctly, you can dealloc it in your (void) dealloc. You could also do:
self.layer = nil;because as you are using it as a property by calling it via self, it is actually converted to:
[layer release];
layer = nil;I hope this helps, but again, i strongly recommend you read apples documentation on memory management and properties, else you'll have memory leaks all over the place.
ok... then I also have a question regarding it:
if I want to access some property (of Cocos kind of course, say it's a CCLayer or CCSprite) from outside a class, should I use:
@property (nonatomic,retain) CCNode * someNode;
@property (nonatomic,assign) CCNode * someNode;
or how ?
not releasing it myself (letting Cocos do it), non deallocing (also leaving it for Cocos), just want to be able to access it
PS: also read this:
@Mike: you can use both assign or retain, it all depends on how you like working.
A retain property will automagically always add a retain and release whenever you access the property (see my post on how cocoa converts that).
An assign property will NOT add any retain/release things, you are responsible for now adding those yourself.
There is no "letting cocos do it" option, cocos2d claims the object for itself and will only keep it for itself as long as it needs it. So cocos2d might release it, causing the retainCount to reach 0, while you still need access to the object. A typical example is this (retainCount is the retain count of aSprite):
(assuming 'Sprite *aSprite;' in the header file of a layer)
- (id) init {
....
aSprite = [SpriteWithFile:@"blabla.gif'];// retainCount: 1
[self addChild: aSprite]; //retainCount: 2
....
} // retainCount 1
//... time passes, the game is playing ...
// you want to temporarily remove the sprite from the screen, so you remove it from the layer.
[self removeChild: aSprite]; // retainCount: 0 OBJECT DEALLOCED!
//... time passes, the game is playing ...
// the sprite needs to reappear on the screen
[self addChild: aSprite]; // CRASH, aSprite has been dealloced and no longer exists.There are multiple solutions to this, one of the simplest is to make aSprite into a retain property, call self.aSprite = [SpriteWithFile:@"blabla.gif']; and call self.aSprite = nil; during the dealloc of the layer to also release the sprite.
thanks hactar, I never liked all those settings, so much easier and clearer in C++ ;)
makes it clearer now ;) not entirely clear, but clearer ;)
---
my real question was something more like:
I have a storage class where I keep all the "public" data, also pointers to some of the more important layers (dont want to access variables using getByTag as I feel it must be rather slow). so in the header I have something like:
CCLayer * gameLayer;
@property (nonatomic, retain) CCLayer * gameLayer;
and of course @synthesize in .mm
I initialize it in another class like this:
gD.gameLayer = [CCLayer node];
[gameScene addChild:gD.gameLayer]; // gD is my macro for gamedata class (The one with "public" data), gameScene is some CCScene
I never release those layers (why would I ;) ), they stay with me till the end. so while I guess there is not much difference between retain and assign (memory will be purged when the app is closed anyway), I just wonder what is the correct way of doing it
Yes, i don't usually work with tags either.
Well, this is all coding philosophy, and its a thing of personal preference. As long as you are consistent in your working everything is fine.
I nearly always prefer retain over assign, but only because I understand cocoas memory management and it saves me lines of code. If one does not fully understand cocoas memory management then explicitly having to add retains and releases may help you learn it quicker as you see exactly whats going on.
I personally try to write my code symmetrically to keep my code clean and make checking for memory leaks easy. So, in your case, if i had "another class" which does gD.gameLayer = [CCLayer node]; (which is converted to two lines, an assignment followed by a retain) on init, i would also have "another class" do gD.gameLayer = nil; (which is converted to two lines, a release and an assignment to nil) on its dealloc.
Now when checking my code for leaks I look at the init and see, ooh, "another class" has assigned something to a retain property during init, hence "another class" needs to do something on dealloc.
Another approach would be to use your gD as a dumpster, where you (using retain properties) store your access to different objects, and only it is responsible for releasing everything at the end (during its own dealloc).
As for "never releasing layers"... Well, don't know what your coding, but when switching scenes the layers on it are generally released. Also, lets say you have a game and the player has a "open menu" button. What I do here is drop down a layer with the menu while pausing the layers behind it, and if the player closes the menu the layer gets removed and released again... There are many situations where layers are released.
thanks again hactar ;)
however - I'm not really sure why would you release layers during the game. I mean - you can just keep them, no ?
for example let's suppose you have 3 scenes:
1) gamescene with gamelayer and guilayer (buttons etc)
2) menuscene with menulayer
3) optionsscene with optionslayer
you can just switch from one to another, why release anything ?
I understand that after you die (or run the game again) game objects need to be removed from the gamelayer, but the layer itself can stay like it was, no ?
@MikeSz: Why release layers/scenes? Memory limits... The iPhone is very tight on memory, having all 3 scenes and their layers loaded in parallel while only one scene is actually running is wasting lots of memory. In the case of my app, it actually causes the iPhone to kill my app due to it being out of memory. So in my app the main menu scene is opened first, the user chooses his game mode, the scene is replaced with the game scene (while the main menu scene is released and so freed) and this in turn reduces memory load. When the player opens the in game menu a layer is added, when the user clicks continue the layer is released. When the game completes the main menu is loaded and the game scene is released.
Even if your app does not get killed for memory over-usage, you may notice the iPhone killing other background tasks when the iPhone is in low (but not out of) memory situations (check the iPhone console for messages). The iPhone then stops checking for mails in the background or kills Safari's preloaded pages, and so makes the iPhone slower for the user when he quits your app as all caches are gone.
Being a Good Citizen means releasing things you don't need anymore and allocating objects lazily (See "Memory is not Unlimited: http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/DevelopingSoftware/DevelopingSoftware.html). Will your app work without being a good citizen? Probably. But if you ever reach the point where your app breaks the iPhones limits, guess what, you get to rewrite your code to release scenes and layers. Even if you never reach that limit, users will still be happier if mails continue to be checked for in the background, your code will be future proof (iPhone Nano with less memory?), and you'll have less troubles with jailbroken users who install backgrounding apps on their iPhone and then mail you because they are surprised that your app crashed when their background apps are swallowing a substantial amount of memory.
Also note that in low memory situations (applicationDidReceiveMemoryWarning:), your app should call [[TextureMgr sharedTextureMgr] removeUnusedTextures]; which removes unused textures from your memory. If however all your layers and scenes are still loaded then all textures are still in use, so no memory will be freed, so you run a further risk of your app being killed for memory over-usage.
Hope that helps :)
@goldplated: No problem, glad its of use :)
ok, I get it now hactar ;) thanks for explaining it all in detail ;)
still - I guess that this mostly depends on the size of the app
if the app is rather small and doesn't stress the memory limit - it can be better not to release scenes/layers and basically remove all the loading time when changing scenes (no need to recreate them anymore)
but in a larger app your approach is absolutely better ;)
thanks for the input, will be more than useful soon enough I guess ;)
You must log in to post.
