Best organization practice/releasing memory practice

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Best organization practice/releasing memory practice

(11 posts) (7 voices)

Started 2 years ago by Juntaou
Latest reply from Codemattic

Tags:

Juntaou
Member

Hey everybody I am moving into the latter parts of the development of my game and(realistically this is something I should have checked on a long time ago...) realized that I am probably doing this all wrong. So if anyone has any tips or anything let me know :D!

Question 1
The overall organization of my game goes as following(I relied heavily on the monocle studios starting example)

mainMenuScene -> groupSelectScene -> levelSelectScene -> playScene

Once a level is beaten in playScene you go back to levelSelectScene, from any of the scenes you can either move forward or backward to the scenes in front of it or behind it. To accomplish this I simply use:

mainMenuScene *ms = [MainMenuScene node];
[[Director sharedDirector] replaceScene:ms];

I use that exact same style for pretty much all of my scene transitions... all of them. Is that bad? And should I be releasing any of the scenes when I do that? As it stands I am not releasing any of the scenes, and I'm just kinda hoping that it is getting autoreleased. This goes into my next question.

Question 2

What exactly do I need to be releasing? This is a very noobish question I understand, but I am very new any of the c languages let alone objective c. I never use malloc or new anywhere, but for example should I be releasing the sprites I am using?
example.h
Sprite *test;

example.m
test = [Sprite spriteWithFile:@"test.png"];
[test setPosition:ccp(121, 110)];
[self addChild:test z:2];

Should I be releasing that somewhere, or because it is a cocos2d node it gets aurotrealeased? I kind rushed into a lot of this where I should have been taking my time in some of the earlier stages and so now when I am getting ready to release my game I am having to go back and make sure it doesn't crap out on someone else sometime in the future. It is a puzzle game and runs pretty smoothly for the most part(It should since it is a simple tile game ...) So if anyone has any input that would be great. Thanks for the help!

Posted 2 years ago #
Frank84
Member

Replacing the Scene like that is perfectly fine. Calling replaceScene will handle the transitioning between scenes and will dealloc the old scene when the transition is done. A Scene is a CocosNode and when a CocosNode is released it also releases all of its children, which release their children and so on. Since your Sprite is a child of the Scene, or something else that is a child of the Scene, you do not have to release it yourself. Note that if there is something still retaining the Scene, it will not actually get released when the transition is done. The main cause of this is forgetting to unschedule your update timer BEFORE calling replaceScene.

To test this I would launch the app with Instruments on the device (never trust Instruments on the simulator) with Leaks turned on. Take a look at the Object Allocations after you exit your scene. Make sure that it is set to only show the active allocations. If your Scene is still on the list, then something went wrong.

Posted 2 years ago #
Codemattic
Moderator

"test = [Sprite spriteWithFile:@"test.png"];"

There are two basic ways to create a new object.

MyClass myObject = [[MyClass alloc] init];

Here the "init" method may be more complex like -initWithVariable: or something, but the method will start with "init...". And it returns a new object already retained and it is your responsibility to release it when you no longer need the object. If you are going to return this object from a function and no longer need it, then autorelease it instead of release.

The other way to create an object is:

MyClass myObject = [MyClass myClassWithVariable:zzz];

Here you are using a convenience constructor. And it returns a new object already autoreleased. If you are only using this object briefly you dont have to retain it. If you want to keep this object around, then yes you need to retain it and then release it when you are done.

So, in your example you are getting an object autoreleased and do not have to release it bc you are only using it briefly.

Posted 2 years ago #
atze
Member

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/20000994-BAJHFBGH

Posted 2 years ago #
shazbox
Member

I did this same thing last week. I was so lost and confused after realizing that I had no idea what I was doing in a memory-management sense (too much time in Java)...

I found this article and something just clicked and now I seem to have figured it out and removed all of my memory leaks.

http://memo.tv/memory_management_with_objective_c_cocoa_iphone

Posted 2 years ago #
Codemattic
Moderator

On Mac OS you have a choice between automatic garbage collection or manual memory management. I imagine that choice will come to iPhone OS one of these days and retain and release will become a bad dream for many developers.

Posted 2 years ago #
shazbox
Member

Honestly, before I thought it was the worst idea I had seen. Now that I actually understand it, I kind of like it...but maybe I'm just a masochist.

Posted 2 years ago #
Juntaou
Member

Great explanations and links thanks everyone! :D

Posted 2 years ago #
slipster216
Moderator

After many months, I still find the whole retain/release/autorelease thing annoying and flawed. I wanted to like it, but just can't. I guess part of it is that I don't like the idea that memory management is partially based on convention. For instance:

SomeClass* c = [[SomeClass alloc] init];

I've retained the class in this case, but I didn't write retain. Oh yeah, because alloc implies retain.

SomeClass* c = [SomeClass convienienceConstructor];

Hmm, whats going on here? I have no way of knowing without looking at the code, which might be in a library I don't have access to. The convention is that this will be autoreleased, but I have no real way of knowing this when I'm writing the code. I simply have to hope others followed the convention.

And perhaps what I hate most about memory management in Objective-C is what it does to the debugger. Because in most cases objects are not cleaned up until you exited the area of code which deals with them, memory issues crash and give you basically no information. It's not like in C where you pop open the stack and you're sitting right on the line of code which caused the problem. No, you're going to have to guess, or use NSZombies to hunt it down.

I think the final thing that I dislike about it is that it doesn't really go as far as it should have. Objects are reference counted; but they are not reference tracked. In other words, an object knows that something is retaining it; but it has no idea what object is retaining it. It's essentially half of a smart-pointer solution native to the language, which makes it a half-wit pointer in my book.

Posted 2 years ago #
jonathan0382
Member

I could do with NSZombies to find the memory f-ups in my code. Codemattic and Clain have helped me massively with my problems, but over the last two days I've still spent more hours than I'd like to admit on my quest to make sure I dealloc everything.

Posted 2 years ago #
Codemattic
Moderator

In addition to the good points Slipster216 made - the reference counting only works with directed graphs. So if you have a tree where each node also keeps a link to its parent, it *shouldnt* retain that link. And if you have a object graph that is more complex than that, memory management gets very difficult very fast.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.