You can mix 4444, 8888, 5551, 565, LA88, L8, etc... textures.

The PVR images are not affected by the [CCTexture2D setDefaultAlphaPixelFormat:] method.

Hi

I would like to use RGBA4444 in some of my PVR textures and RGBA8888 in others of my PVR textures. No as I understand it the PVR includes information about wether it is RGBA8888 or RGBA4444, but will cocos2d work well with this also reducing memory usage on the RGBA4444 textures and still render my RGBA8888 textures in lovely 32 bit?

Thank you
Søren

We use CCVideoPlayer to play a mp4 video in our intro scene. It worked well for us in one of our apps.

CCVideoPlayer is part of cocos2d-extension.

Great assets! Thanks @bradparks!

cool.... and i forgot to mention that you have to only use the SWF format... that thread talk about converting the SWF's into textures, but for your purposes you'd ignore that whole bit and just stick with native SWF's.

Thanks @bradparks, looks interesting :) I'll definitely check them out tomorrow and get back to you with updates :)

hey.... you can use Adobe Flash SWF's in Cocos2d for stuff like that.... That would be low overhead for memory, and would probably work great for cut scenes... I haven't tried it though, but it should work. When you publish your Flash SWF's, they can't include Actionscript, and they should probably publish to something like Flash 3 or something like that.... This thread talks about it in detail:

http://www.cocos2d-iphone.org/forum/topic/24542

with I *beleive* the best versions of the referenced source online available at GitHub here:
https://github.com/talentless

specifically, I think you need the following:
https://github.com/talentless/MonkSWF
https://github.com/talentless/cocos2d-iphone-extensions-swf
https://github.com/talentless/MonkVG

Hope it helps! Let us know how you make out.... I haven't looked at this since that thread was busy a couple of months ago, but will probably get back to it sometime within the next month myself....

I was wondering, the intro animation of Cut the Rope, in which theres a knock on the door, and Om Nom appears in a box, etc. How is this made? Is there any way I can embed videos in my game like that, because making a video like that, by using CCSprites and CCAnimation would consume a lot of memory.

Here is some more interesting data that doesn't seem to make much sense. I ran the same glReadPixels() test on two different devices - a gen 2 iPod Touch running iOS4.2 and gen <latest> iPod Touch running iOS 5.0.1. The test simply created an empty CCRenderTexture of 512x512 pixels, calling glReadPixels on it every frame and measuring the delay. Here is the code:

if (tex == nil) {
		tex = [[CCRenderTexture renderTextureWithWidth:512 height:512] retain];
	}

	[tex begin];

	float x = 0;
	float y = 0;
	float w = 512;
	float h = 512;

	GLubyte* pixels = malloc(w * h * sizeof(GLubyte) * 4);
	glReadPixels(x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, pixels);

	[tex end];
	free(pixels);

On the older device running iOS4.2, the glReadPixels call (which I measured independent of the other calls (mallocs and such)) hovered at at around 25ms. On the new device, the glReadPixels call lasted a whooping (and consistent) 100ms.

Anyone know why that might be?

Thanks for the reply and code sample, @araker! And you are totally right about the texture binding - my bad.

I found this interesting post on CVPixelBufferRefs supposedly part of iOS5 but I haven't dug into those yet (and according to the post, they only have hardware support on the new devices, reverting to glReadPixels on older hardware). Most of this is way over my head in terms of my knowledge of OpenGL, but if I sniff out something interesting, I'll let you know.

EDIT: as far as the type of processing I need - I was looking at the possibility of rendering dynamic 2D shadows based on programmatically generated textures. I believe this would be an easy accomplishment with shaders, but I'm not quite ready to jump onto OpenGL ES 2.0 just yet. So, I was sniffing around to see if I could hack something together on the CPU instead.

We all wish that glReadPixels could be faster. It's not possible to use a pixel array like in CCMutableTexture because the render texture is a color buffer and not a texture, the texture is generated from the color buffer, but the manipulation happens on the buffer.

The buffer itself can't be accessed directly, only glDraw commands can write to it and glReadPixels can retrieve the color values. The texture can only read the buffer, but not manipulate it.

Where exactly do you use that code? glReadPixels reads values from a color buffer, not from a texture. So the texture bind calls aren't necessary.

I usually read the buffer like this..

GLubyte* pixels = malloc(section_width * section_height * sizeof(GLubyte) * 4);
CCRenderTexture* myTexture = ...;
[myTexture begin];
  [someSprite visit];
  glReadPixels(x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, pixels);
[myTexture end];

One other thing that can speed things up a bit is using a smaller render textures and scale the sprite when needed.

Depending on where you need the color values for, there may be ways to avoid using glReadPixels. What exactly do you mean with additional processing?

I have CCRenderTexture into which I draw stuff using the following method:

CCRenderTexture* myTexture = ...;
[myTexture begin];
[someSprite visit];
[myTexture end];

Occasionally, I want to peek back into this texture and read a bunch of pixels to do some additional processing with them. I can accomplish this with glReadPixels() thusly:

GLubyte* pixels = malloc(section_width * section_height * sizeof(GLubyte) * 4);
glBindTexture(GL_TEXTURE_2D, textureName);
glReadPixels(x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, pixels);
glBindTexture(GL_TEXTURE_2D, nil);

This works, but it's slow for my needs and the question I have is whether I can accomplish this same task faster, by avoiding glReadPixels somehow. Any suggestions?

I figured, I could keep a pointer to the raw data representing the texture in way similar to CCMutableTexture2D that has been used by folks on this forum (for example here). In the CCMutableTexture2D, that data is passed to the GPU using glTexImage2D(). Does that method copy the data into GPU's memory or does it simply direct GPU to use that piece of memory without duplicating it? If it's the former, I could just look through the raw data as it's updated via the CCRenderTexture begin/end method without having to call glReadPixels(). If it's the latter, I'm out of ideas.

Any help is much appreciated!

I've trying to fix this issue for days now without success. The summary is that I have a character in my game that can have one of 8 possible textures. So I have 8 different spritesheets (TexturePacker, pvr.ccz) and randomly I pick one. This class eventually gets released and a new one is created. What happens is that every time that happens the memory allocated increases by around 4MB up until the point where the 8 spritesheets are loaded, then it stops growing.

This class has also methods for animating the sprite but they are not being called. I tried to isolate the problem by commenting out all functionality down to a point where all the class does is load the sprite sheet when it's created and remove it when it's released:


// right after init
[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:spriteSheetFileName];


//right before dealloc
[[CCSpriteFrameCache sharedSpriteFrameCache] removeSpriteFramesFromFile:spriteSheetFileName];
[[CCTextureCache sharedTextureCache] removeTextureForKey:textureFileName];


But memory still keeps growing.

I can't use removeUnusedSpriteFrames or removeUnusedTextures because that removes textures I intend to use at some point and I need it pre-loaded.

Does anyone have any idea what can possibly be happening? Anyway I can debug this further?

Thank you!

Instruments speaks a language, that only the high priests of programming understands.
The rest of us will have to rely on the fact, that loading a texture, will immediately chew away our precious memory :)

Thanks for your reply. I was using Instruments/Allocations widget and looking at the top line which shows all memory allocated from my app. It seemed to go up and down depending on the Visible property. Using the Activity Monitor widget, I see that alot of virtual memory is being used depending on how many images I load, regardless of the Visible property.

I am not sure what you are reading.
When you create the sprite, the texture is loaded into the cache. Setting visible will have no impact on memory consumption.

So the answer to your question is: Yes, you will want to preload as much as possible, to avoid loading textures on the fly, and no, there is no memory saved by setting visible to false.

I notice that when I load a sprite from a file (the size is 512x512 and is PVRTC), instruments indicates the memory usage has gone up, as it should. But, if I set the sprite visible property to false right away after loading, the memory usage goes up only slightly. Of course, when I set the visible property back to true again, the memory usage goes back up where it was before. Is this memory reading accurate? If so, does this mean i can load all my images up front and set only those images which are needed right now to visible?
Thanks.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html

I think im a bit confused about how it works.
What is a "reference count"? What is release and retain?
Do i have to release the object everytime i "use" it?

Where can i read more about properties? (@property (nonatomic, retain), etc.)

if you want to completely control memory usage from sprite sheet, the only way i found is to :

begin : use addSpriteFramesWithFile
end : use removeSpriteFramesFromFile + removeTextureForKey

for removeTextureForKey, be warn that you need to give the EXACT texture name (like XXX-hd.png or XXX-ipad.png) it doesn't complete it automatically like in loading :(

if you have memory use buy your sprite sheet after that, it's probably because your sprite are not destroyed or something like that.

I have also tried to explicitly remove the texture with:

[[CCSpriteFrameCache sharedSpriteFrameCache] removeSpriteFramesFromFile: ];
[[CCTextureCache sharedTextureCache] removeTextureForKey: ];

But still won't free up the memory...

Hi FogleBird.
No, they don't. removeSpriteFramesFromFile:file will remove all sprite frames, including the ones I am planning to use and I want to have pre-loaded. removeUnusedTextures will not free up the memory.

It just keeps increasing...

Do either of these help?

[[CCSpriteFrameCache sharedSpriteFrameCache] removeSpriteFramesFromFile:file];
[[CCTextureCache sharedTextureCache] removeUnusedTextures];

Check out some of my threads I had the same problem and eventually solved it it was a special way I had to use to unload sprite sheet

Bump. I'm still struggling with this issue. I made my " human" class not a subclass of CCSprite anymore but rather just containing a CCSprite object with itself.

I have defined the 2 methods below that are called when I'm done with that instance. The methods are being called, but the memory keeps increasing every time a new HumanSprite is created.


-(void) cleanUp
{
[_humanSprite removeFromParentAndCleanup:YES];

-(void) dealloc
{
NSLog(@"On dealloc for humanSprite");
[super dealloc];
}


And here's how I create the CCSprite that is held on this class:


HumanSpriteRandomizer *humanSpriteRandomizer = [HumanSpriteRandomizer getInstance];
humanId = [humanSpriteRandomizer getNextHumanId];

_humanSprite = [CCSprite spriteWithSpriteFrame:frame];
[_humanSprite setPosition:ccp(642, 400)];
[spriteSheet addChild:_humanSprite z:10];


That's a big problem for me right now, anyone has any idea why it doesn't free up the memory after I remove the sprite sheet?

Thanks!

If you stream the music with AVAudioPlayer you should not get out of memory crashes regardless of the filesize because it streams the music.

less than 5mb mp3 file is ok. You don't need too high quality bg music, people don't buy casual game (except music game) because of the bg music.

it depend on how many data you have on memory (sprites etc...).

i think that there is no general maximum background music size.

if you make a music game, you will have high quality music but lite graphics.
if you make a FTP shooter, you will have high graphics and medium/low quality music.

the object is released when the reference count == 0.
removeFromParent will decrease the reference by 1.
And if cleanup == YES it will remove all scheduled timers / actions for that particular node (further reducing the reference count it case times/actions were scheduled)