Help! Memory issues (I think) « cocos2d for iPhone

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

Help! Memory issues (I think)

(25 posts) (4 voices)

Started 1 year ago by Dunc
Latest reply from Dunc

Tags:

Dunc
Member

Evening All,

I'm hoping this is a simple problem, as it doesn't "feel" like I'm pushing things too far here...

Having finally managed to get my hands on an iPad (I'm in the UK), I'm now trying to get the app I've been working for a while now to run on the device. It works to a certain degree, but is very prone to crashing on the device (fine in simulator)

What I have is a bunch of scenes, which I load in sequence (I suppose a book would be a good analogy). Each of these scenes has a bunch of child sprites, layers, etc. In some scenes, I have flipbook style animation sequences which activate under certain circumstances. For the animations, I'm making use of CCSpriteSheets. This all works fine.

My problem is that I can tap through the first few scenes, which are all fairly basic (light animation and static sprites mainly - with some audio), and I can flip back and forward between these scenes with no problem at all. But when I continue on to some of the more in depth scenes, I quite often (but not always) get a crash when I replace the scenes (status 10 or status 0).

It certainly doesn't seem to be a crash at a specific point in the code, as the scene replacement taking place can be different each time. If I reboot the device, it will let me get further through the scenes before it crashes, after which the crashing will occur far more quickly. So this all points to a memory / resources issue.

I've checked that all my scenes, sub-layers, etc, are being dealloc'd, I'm forcing a [[CCDirector sharedDirector] purgeCachedData] on applicationDidReceiveMemoryWarning (in my appDelegate). I'm also forcing a release of the sharedSpriteFrameCache in the dealloc of each scene (and verifying that it has ran through that bit of code).

Can anyone offer any hints and tips on what I should be doing to ensure memory is released between scene loads? Or offer any suggestions on things to try here? I'm out of ideas at the moment.

Oh, and the other thing is I've tried running this through the Leaks instrument, but it crashes the app at the point it tries to gather data after the first scene replacement.

Any advice would be gratefully appreciated!

Thanks,

D.

Posted 1 year ago #
Dunc
Member

oh, and by "in-depth scenes", I just mean scenes with more/larger flipbook-style animations.

Posted 1 year ago #
robodude666
Member

Are you able to view the Debugger? It should give a backtrack list of where it's been and show you where it crashed. Have you tried setting breakpoints and manually stepping in/over to see how the code executes?

You can also try going into the organizer and getting the crash log off of the device, then see exactly what the problem it crashed at was.

Posted 1 year ago #
Dunc
Member
Thanks for the response dude. I wasn't aware of the console, but it has been quite educational. This is definitely a memory issue. I didn't realise that the OS would terminate background processes first (such as Mail and iPod) before killing the running app. This would go some way to explaining the inconsistency in where the app terminates.

I've since added the following lines before my scene change to clear texture and sprite frame cache of unnecessary stuff:
```
[[CCTextureCache sharedTextureCache] removeUnusedTextures];
[[CCSpriteFrameCache sharedSpriteFrameCache] removeUnusedSpriteFrames];

[[CCDirector sharedDirector] replaceScene:[CCPageTurnTransition transitionWithDuration:0.4
                                                                             scene:[NSClassFromString(sceneName) scene] backwards:backwards]];
```
... and I can see in the console that the stuff from the current scene which is being replaced is not being removed until the NEXT scene change. But due to the nature of the transition, I can't really see how this could be any other way.

Here's some more info:

Fairly regularly, the memory warning occurs on the load of some fairly chunky animation sprite sheets as follows (between the two NSLog calls):
```
NSLog(@"before adding to sharedSpriteFrameCache");
	[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"tickle1.plist"];
	tickleSpriteSheet1 = [CCSpriteSheet spriteSheetWithFile:@"tickle1.png"];
	[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"tickle2.plist"];
	tickleSpriteSheet2 = [CCSpriteSheet spriteSheetWithFile:@"tickle2.png"];
	[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"tickle3.plist"];
	tickleSpriteSheet3 = [CCSpriteSheet spriteSheetWithFile:@"tickle3.png"];
	[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"tickle4.plist"];
	tickleSpriteSheet4 = [CCSpriteSheet spriteSheetWithFile:@"tickle4.png"];
NSLog(@"after adding to sharedSpriteFrameCache");
```
These sprite sheets are each 1024px * 1024px in total, with around 14 200px *300px sprite frames in each sheet (I've already made a compromise and split this up into 4 sheets from one big one).

I then go on to load each set of sprite sheet frames in to an animation, and run the animation on the main sprite when needed (in this case, I randomly pick one of the 4 animations when the user "tickles" the character. Very cute and possibly a bit wrong :p ).

So, I guess my questions are:

1) Am I asking too much of the poor little iPad? (surely not!)
2) Is there a better way to do this which won't be so memory hungry?

This is just one of my scenes - there are other scenes large-ish animation sequences too...

Please help!! I promise I'll be a good community person and start trying to help out more once I've nailed this problem!!!

Thanks,

D.
Posted 1 year ago #
Dunc
Member

Wait a minute - can someone please tell me if I'm working this out right?

- 4 sprite sheets at 1024*1024*4 = approx 4MB each = approx 16MB
- For each sprite sheet, there are about 14 300*200 sprites = approx 12MB

So have I just loaded 28MB of animation graphic data in to memory?

Add to that a full screen background image (3MB) and another largish static graphic (600 x 460 - approx 1MB), and whatever memory has been consumed by audio, and I guess that's my problem.

Is this right? And Is there an easy way for me to find out how much memory my app is currently consuming with an NSLog call? (As I said previously, Instruments just seems to crash the app for some reason).

Thanks,

D.

Posted 1 year ago #
Karl
Member

If you're working in 32-bit, then:

a 1024x1024 sprite sheet = 4MB. 4 sprite sheets = 16MB.
a 600x460 graphic gets expanded to 1024x512, so another 2MB
a full screen bg on iPad is 1024x768, which gets expanded to 1024x1024, so 4MB.
Sprites in a sprite sheet don't use up extra memory. They all share the sprite sheet's texture.

Total space used: 22MB.

If instruments is crashing your app, it's probably a serious bug in your code. Have you tried using Clang/LLVM? http://www.fruitstandsoftware.com/blog/2008/08/finding-memory-leaks-with-the-llvmclang-static-analyzer/

Posted 1 year ago #
Dunc
Member

Thanks for this Karl. I tried to use Clang once before, but needed my root password - which I misplaced a long time ago!

What's the limit for an app's memory footprint (if there is one) ?

I think I'll have to opt for loading in the sprite sheets and creating the animations as and when I need them, rather than all at once. This may make for a more jarring user experience though. Would have been nice to be able to preload them all and not worry about it...

Cheers,

D.

Posted 1 year ago #
Karl
Member

The golden rule for older phones is about 24MB. I managed to get up to 32MB (loading the app right after rebooting the phone) before the system went nuts and did an 8MB reallocation, freezing my app solid for a few seconds in the process. The system can issue memory warnings at any point, but usually it's after 24MB in practice (not sure about newer devices).

Bear in mind that you can cut your memory use in half by loading into 16 bit buffers instead of 32 bit.
You can cut even further (8x or even 16x) if your images look OK when compressed using PVRTC.

Posted 1 year ago #
Dunc
Member
Thanks again Karl! I just tried dropping the texture pixel format for the app down to RGBA4444, from RGBA8888. Interestingly, it didn't seems to make any difference in terms of stability, and even if it did, the images looked awful! My images have a watercolour look about them, so lots of smooth gradients, unfortunately.

However, I did try out the other formats for kicks, and it looks as though using RGB565 and RGB5A1 stopped the memory warnings and subsequent crashes. But totally unusable, due to low alpha channel bit depth.

So, at least I know it's something to do with the texture memory size now...

The crash log shows this:
```
Free pages:        693
Wired pages:       26456
Purgeable pages:   0
Largest process:   XXXXXXDemo

Processes
         Name                 UUID                    Count resident pages
   XXXXXXDemo <f2669867a0af3207ba63627c8ff017f0>   36730 (jettisoned) (active)
```
Is the 36730 figure the current memory footprint of the app process?

D.
Posted 1 year ago #
Karl
Member

If RGBA4444 didn't make a difference in stability, then you're likely facing a memory leak (RGBA4444, RGBA5551, and RGB565 all use the same amount of memory). Memory management is not just about retaining and releasing in your code. Setting timers and enabling touch causes various cocos2d subsystems to retain your objects (which ideally they shouldn't do, but that's another story :P).

If you're using watercolour-like images, chances are pretty good that converting some of them to PVRTC would yield acceptable results. Just remember that the 4 pixels along the edge of a PVRTC image will look ugly, so you'll have to adjust your texture coordinates to offset by 4 in X and Y direction. The backgrounds in Mice Heist are PVRTC, for example: http://www.cocos2d-iphone.org/forum/topic/6681

Considering that you're unable to run any code analyzers due to crashes / lack of the root password, I'd strongly suggest that you reinstall your mac. You're going to miss memory leaks by only desk checking, especially as the program grows bigger.

Posted 1 year ago #
Dunc
Member

I think I may be able to recover my root password using the OSX install disc - just need to hunt that down. I'll make this my next port of call :)

Wow - must have missed the post about your game - looks like a lot of fun. I shall add it to my download list!

Time to look in to PVRTC as well...

D.

Posted 1 year ago #
Steve Oldmeadow
Administrator

If you are developing for the iPad then you are using a version of XCode that has Clang built in. Just choose "Build and Analyze" from the build menu.

Posted 1 year ago #
robodude666
Member

Though, keep in mind that Clang doesn't work for C++/Obj-C++ files (aka *.cpp and *.mm). Those files are skipped as Clang hasn't fully implemented it and Apple doesn't use non-final stuff.

Posted 1 year ago #
Dunc
Member

Oh cool, thanks for that! To be honest, I hadn't even noticed the new menu option!

Posted 1 year ago #
Dunc
Member

Right, I just used the analyser. It only picked up a few minor little leaks (just small arrays of strings). It seemed to run through very quickly though, so I'm not completely convinced it checked everything... are there any settings for the analyser that I need to set?

Posted 1 year ago #
Karl
Member

I just ran the xcode analyzer, followed by scan-build from my CLANG/LLVM installation, and both came up with the same 6 issues in the same 2MB of source code. Xcode's analyzer scanned in less than half the time it took the separate CLANG/LLVM installation for some reason...

Posted 1 year ago #
Dunc
Member
I'm really not having much joy with this. I'm really disappointed that this is causing so much grief.

I can't use RGBA4444, as the image quality is awful.

I tried using PVRTC, but I can't get it to accept my PVR file as a valid file. I think I may not have converted the file correctly. I have tried using the TextureTool command line utility with some of Apple's example commands, but to no avail. Could someone please let me know what command line parameters I should be using? I'm using the following code to try and load the PVR sprite sheet in to the app...
```
CCTexture2D *tex1 = [[CCTextureCache sharedTextureCache] addImage:@"tickle1.pvr"];
[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"tickle1.plist" texture:tex1];
spriteSheet1 = [CCSpriteSheet spriteSheetWithTexture:tex1];
```
Thanks,

D.
Posted 1 year ago #
Karl
Member

In order to convert to PVRTC, your source image must be square, and its dimensions must be a power of 2. For example, 16x16, 32x32, 64x64, 128x128 etc up to 1024x1024.

Posted 1 year ago #
Dunc
Member

These are the 1024x1024 sprite sheets. So this should comply. I'll keep playing.

Posted 1 year ago #
Dunc
Member

Okay, it seems I was missing the -f flag from the texturetool parameters. I now have PVRTC textures, but alas they are too muddy around the edges (where the sprite frames meet the transparent background). It's a shame really, as the middle rest of the image is absolutely fine. It's just a problem at the boundary between graphic and transparency. Are there any tricks for preventing this?

Posted 1 year ago #
Karl
Member

Unfortunately, no. PVRTC isn't very good with hard edges (including transparent to non-transparent).
What you could try is making a compound image, making a CCSprite with the texture coordinates matching the nice looking part, and then making other (smaller) sprites with the parts that didn't compress so well and lining them all up in code (with the non-PVRTC stuff in front of the PVRTC stuff).
That's what I did with the backgrounds in Mice Heist, because the mouse holes looked awful after converting to PVRTC.

Posted 1 year ago #
Dunc
Member

Sadly not an option in this case, as these are character animation frames. The edges are constantly on the move. I'm now going through the various textures converting what I can get away with in to PVRTC. Perhaps it will be enough...

None of this would have been (and wasn't) a problem on my iPhone 3G, but I guess the new phone will have similar problems if your graphics are at native resolution.

Posted 1 year ago #
Dunc
Member

I've been trying to convert a 1024 x 1024 single color square PNG file to a PVRTC file using TextureTool, but it just generates a big black square! Does anyone have any ideas why this might be??

Posted 1 year ago #
Karl
Member

The PVRTC compression algorithm works by interpolating with its neighbors. A single color image is probably one of those edge cases it can't handle.

If you need a big, one color sprite on the screen, you have 3 ways to do it:

1. Make a big PNG. Not a good idea because it will take up a lot of room.
2. Make a small (1x1) png and scale the sprite.
3. Make a CCColorLayer, initialize it with the color and alpha you want, and set its contentSize.

Posted 1 year ago #
Dunc
Member

Thanks again Karl. As I'll sometimes need a pretty background image, and sometimes just a solid colour, I think I'll add a new property to the scene data file to give it a colour. If the colour is populated, use option 3 (above), otherwise, just use the provided background filename. Then it's just down to me to decide for each scene whether or not I can get away with PVRTC or PNG...

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.