Thanks alberteddu. That code does help as I now have a transparent window, glview and CCLayer (by using CCLayerColor).

The only thing stopping me from having a completely transparent application is CCScene as this still has a black background :(

Does anyone know anyway of making CCScene transparent?

Oh, I found - did you mean [[CCSpriteFrameCache sharedSpriteFrameCache] removeUnusedSpriteFrames] ?
It looks like a key for my question.
Thanks! Thanks a lot!!!

What does it mean "frame cache"?
Does it mean "use [self removeAllChildrenWithCleanup:YES]; in method 'onExit' on the every page"?

Have you tried removing the images from the frame cache and then cleaning the texture cache? I had to do this yesterday for a project I am working on. I have a large intro scene that was sticking around and causing me memory issues later.

I can ask a question for another for another way: Why are volumes of allocated memory different, when I go to the page directly or from previous page?
If I go to the page from menu - it takes 16 MB for all app, if I go to this page from previous - it takes more memory.

I use 'Activity Monitor' in Instruments. I clean texture cache and use [[CCDirector sharedDirector] purgeCachedData] when go to the page.

Hello!
I create the interactive book for iPad.
To turn the pages I use:
[[CCDirector sharedDirector] replaceScene:[pageClass scene]];
I don't have any leaks, but I have notice the memory problem.
For example, in my test project I have 3 pages: first page has 1 picture (1024*768), scene of second picture if free of any child, and third page is also free.
When CCDirector places first scene, allocated memory is around 11 MB.
When first scene is replaced by second scene, there is also 11MB.
And when second scene is replaced by third scene memory go to 8 MB, that is normal for my page without child.
All methods like dealloc onEnter onExit are called properly.

In my real project every page needs around 20-30 MB of memory (I use big atlases). Simultaneous storage of 3 pages in memory calls memory warnings and causes crashing my app, because my iPad 1 doesn't have enough free memory.

Is it bug of Cocos?
May be I do somethings wrong? Where I can read about runloop of cocos2d scene?

There is a way.

[[glView_ opaqueAncestor] setAlphaValue:0];
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);

Hope this helps.

I would be interested, as well, in knowing where the GCD was applied to obtain this ultimate solution.

@riq

Has any progress on that been made?

Thanks, that did solve it.

I think it's the right approach as I'm loading/creating things on the same thread as the main one. Although not checked, I think Director uses this same approach in the scene initialization process as well. I say so as I use it this way in my XNA port of Cocos2d ;).

[[CCDirector sharedDirector] setNextDeltaTimeZero:YES]; MIGHT be what you're looking for, but to be honest I'm not completely sure.

Also, i'm not sure if this would help or work depending on how your visuals are set up, but could you just start the actions after you load all of your assets?

Hello There,

During my gameplay, when I switch a level for example, I'm loading some assets or creating some sprites. This causes a delay in game time. This is not a problem but more importantly, the actions I start during that process, seems to skip that delay in time so some of my animations seems to work like from the middle, like "Get Ready" logo moving into the screen. I think to solve this problem, I need to reset the game time so the actions can start from the beginning.

I could do this in other systems, such as "ResetElapsedTime" on XNA and would like to know whether we have the same feature in Cocos2d as well?

Thanks in advance...

Özden

@rsanchezsaez where do you apply this solution? CCDirector.m?

I found the ultimate solution in this question:
- http://stackoverflow.com/questions/5944050/cadisplaylink-opengl-rendering-breaks-uiscrollview-behaviour

I tried this solution, as I'm trying to use CCDisplayLinkDirector together with an overlaid UIScrollView, but using

[displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSRunLoopCommonModes];

in CCDisplayLinkDirector partially breaks UIScrollView behaviour (very fast burst scrolling doesn't get any inertia).

robodude666: Are you experiencing this issue?

@wololo: check out the thread I started here: http://www.cocos2d-iphone.org/forum/topic/15412
There is some info in it about saving gamestate etc..

As @Benihana said, it is in the roadmap. Hopefully it will be included in 1.1. or 1.2

Aha! Thanks--Should've looked more closer at that I guess. Just wanted to know if there was something already built-in to take care of that.

You are referring to NSCoding, which will make this trivial. It was planned for 1.0, but got pushed back. I'm not sure what priority it is, so it could be anywhere from a month to a year away. I definitely wouldn't wait for it, though there isn't a really good alternative.

http://www.cocos2d-iphone.org/wiki/doku.php/roadmap

I realize this was posted 9 months ago, but was wondering if there is any way to accomplish this? I have a bunch of enemies that are moved on the screen (they are all in a CCSpriteBatchNode), and when the application is quit, I want to save all their positions on the screen.

I know how to save, but I'm wondering if there's an easier way to accomplish this besides manually storing the following: The sprite, which action it's currently on, and its location on the screen.

d-range, how exactly did you fix this? Can you give me some code or more detail? Thanks so much!

If anyone is still interested in how I solved this issue for my game: it turned out the drawing artefacts where caused by sprites with fractional position coordinates. Because my sprite sheet doesn't have borders around the sprites, setting fractional position coordinates sometimes resulted in texels from adjacent sprites being rendered. The STRETCH_TEXEL_0 workaround didn't work for me, because I draw aliased, unscaled, sprites that should be aligned pixel-perfect. Enabling the texel stretch 'fix' only made things worse in my case.

So eventually I fixed it by simply truncating sprite coordinates.

Yes, it was the deletion code. I made some severe mistakes there. Now instead of deleting objects right away when they crash or leave the screen I only store a reference to them in an array called objectsMarkedForDeletion and the only place where I iterate over that array and remove everything in it from my main objectsArray is in the main loop before I update all my objects, check for collisions etc.. That way hopefully the array does not change when something iterates over it. I also do something similar when checking for line of sights and shooting because shooting is creating new objects is changing the array I'm iterating over. I had that right, only my deletion was faulty.
Also yes, I'm reusing objects heavily, but I always call a reInit method on them that should (and it seems to) reset any value that could be wrong.

No problem, I think from the looks of it, it is certainly your deletion code. Are you only allowing for one deletion per cycle? Are you reusing objects (that would have dirty values instead of what you expect). I'd also only use 2 or 3 projectiles for testing.

Thanks a lot for your reply. I tried this now. My thought was that it should not matter where the timeDeltaFactor is clipped or if it is clipped because it should always be in sync as all objects get the same delta time to respond to. I've also logged the x position of the objects so that you can see the drift.
My new test setup is two scripted spawners that spawn a projectile every 0.5 seconds to the right. They should be in sync, but they are not after a while. This is how my log starts:

2011-04-08 12:57:12.658 cocos2d-project[94819:207] main loop update delta: 0.033317
2011-04-08 12:57:12.692 cocos2d-project[94819:207] timedelta: 2.024640
2011-04-08 12:57:12.693 cocos2d-project[94819:207] x position: 57.086239
2011-04-08 12:57:12.693 cocos2d-project[94819:207] timedelta: 2.024640
2011-04-08 12:57:12.694 cocos2d-project[94819:207] x position: 57.086239
2011-04-08 12:57:12.695 cocos2d-project[94819:207] main loop update delta: 0.033744
2011-04-08 12:57:12.725 cocos2d-project[94819:207] timedelta: 1.975080
2011-04-08 12:57:12.726 cocos2d-project[94819:207] x position: 63.999020
2011-04-08 12:57:12.726 cocos2d-project[94819:207] timedelta: 1.975080
2011-04-08 12:57:12.727 cocos2d-project[94819:207] x position: 63.999020
2011-04-08 12:57:12.728 cocos2d-project[94819:207] main loop update delta: 0.032918
2011-04-08 12:57:12.742 cocos2d-project[94819:207] timedelta: 1.013460
2011-04-08 12:57:12.744 cocos2d-project[94819:207] x position: 67.546127
2011-04-08 12:57:12.748 cocos2d-project[94819:207] timedelta: 1.013460
2011-04-08 12:57:12.750 cocos2d-project[94819:207] x position: 67.546127

The line with main loop update delta is the time delta from my main loop, it marks one cycle of movement. The timedelta lines are the timeDeltaFactor you suggested to log and the x position is the position of the object that is beeing moved. It starts out with two objects being perfectly in sync. Later when there are more shots flying around there should be pairs of projectiles with the same position.
Like this:

2011-04-08 12:57:14.652 cocos2d-project[94819:207] main loop update delta: 0.033332
2011-04-08 12:57:14.675 cocos2d-project[94819:207] timedelta: 1.999920
2011-04-08 12:57:14.676 cocos2d-project[94819:207] x position: 473.536804
2011-04-08 12:57:14.676 cocos2d-project[94819:207] timedelta: 1.999920
2011-04-08 12:57:14.677 cocos2d-project[94819:207] x position: 473.536804
2011-04-08 12:57:14.678 cocos2d-project[94819:207] timedelta: 1.999920
2011-04-08 12:57:14.679 cocos2d-project[94819:207] x position: 368.221680
2011-04-08 12:57:14.679 cocos2d-project[94819:207] timedelta: 1.999920
2011-04-08 12:57:14.680 cocos2d-project[94819:207] x position: 368.221680
2011-04-08 12:57:14.681 cocos2d-project[94819:207] timedelta: 1.999920
2011-04-08 12:57:14.681 cocos2d-project[94819:207] x position: 260.032318
2011-04-08 12:57:14.682 cocos2d-project[94819:207] timedelta: 1.999920
2011-04-08 12:57:14.682 cocos2d-project[94819:207] x position: 260.032318
2011-04-08 12:57:14.683 cocos2d-project[94819:207] timedelta: 1.999920
2011-04-08 12:57:14.683 cocos2d-project[94819:207] x position: 151.519257
2011-04-08 12:57:14.684 cocos2d-project[94819:207] timedelta: 1.999920
2011-04-08 12:57:14.684 cocos2d-project[94819:207] x position: 151.519257

But then the strange thing happens and the next iteration of the loop shows this:

2011-04-08 12:57:14.685 cocos2d-project[94819:207] main loop update delta: 0.033332
2011-04-08 12:57:14.708 cocos2d-project[94819:207] timedelta: 1.992120
2011-04-08 12:57:14.709 cocos2d-project[94819:207] x position: 480.509216
2011-04-08 12:57:14.729 cocos2d-project[94819:207] timedelta: 1.992120
2011-04-08 12:57:14.730 cocos2d-project[94819:207] x position: 375.194092
2011-04-08 12:57:14.730 cocos2d-project[94819:207] timedelta: 1.992120
2011-04-08 12:57:14.731 cocos2d-project[94819:207] x position: 375.194092
2011-04-08 12:57:14.732 cocos2d-project[94819:207] timedelta: 1.992120
2011-04-08 12:57:14.734 cocos2d-project[94819:207] x position: 267.004730
2011-04-08 12:57:14.735 cocos2d-project[94819:207] timedelta: 1.992120
2011-04-08 12:57:14.735 cocos2d-project[94819:207] x position: 267.004730
2011-04-08 12:57:14.736 cocos2d-project[94819:207] timedelta: 1.992120
2011-04-08 12:57:14.736 cocos2d-project[94819:207] x position: 158.491669
2011-04-08 12:57:14.751 cocos2d-project[94819:207] timedelta: 1.992120
2011-04-08 12:57:14.751 cocos2d-project[94819:207] x position: 158.491669
2011-04-08 12:57:14.752 cocos2d-project[94819:207] timedelta: 1.992120
2011-04-08 12:57:14.752 cocos2d-project[94819:207] x position: 165.464081

It's still 8 active projectiles, but the first and the last value stand alone, no pairs. Also the first value should maybe not even exist because at more than 480px in x direction projectiles should get destroyed.

This is the next itteration:

2011-04-08 12:57:14.754 cocos2d-project[94819:207] main loop update delta: 0.033202
2011-04-08 12:57:14.775 cocos2d-project[94819:207] timedelta: 3.999480
2011-04-08 12:57:14.777 cocos2d-project[94819:207] x position: 487.534973
2011-04-08 12:57:14.777 cocos2d-project[94819:207] timedelta: 3.999480
2011-04-08 12:57:14.778 cocos2d-project[94819:207] x position: 389.192261
2011-04-08 12:57:14.778 cocos2d-project[94819:207] timedelta: 3.999480
2011-04-08 12:57:14.779 cocos2d-project[94819:207] x position: 281.002899
2011-04-08 12:57:14.779 cocos2d-project[94819:207] timedelta: 3.999480
2011-04-08 12:57:14.783 cocos2d-project[94819:207] x position: 281.002899
2011-04-08 12:57:14.784 cocos2d-project[94819:207] timedelta: 3.999480
2011-04-08 12:57:14.784 cocos2d-project[94819:207] x position: 172.489853
2011-04-08 12:57:14.785 cocos2d-project[94819:207] timedelta: 3.999480
2011-04-08 12:57:14.785 cocos2d-project[94819:207] x position: 179.462265
2011-04-08 12:57:14.786 cocos2d-project[94819:207] timedelta: 3.999480
2011-04-08 12:57:14.789 cocos2d-project[94819:207] x position: 63.998180
2011-04-08 12:57:14.789 cocos2d-project[94819:207] timedelta: 3.999480
2011-04-08 12:57:14.790 cocos2d-project[94819:207] x position: 63.998180
2011-04-08 12:57:14.791 cocos2d-project[94819:207] timedelta: 3.999480
2011-04-08 12:57:14.792 cocos2d-project[94819:207] x position: 77.996361

Now there are 9 objects where there should be an even number... I'm beginning to wonder if the problem could be totally unrelated to my movement code and be caused by the way I delete my objects. I'll do some more logging on that one and assume for now that the timedelta is not the problem.

Edit: I tried to solve it by changing the way objects are deleted. This resulted in screwing up the object removal so that they don't get removed at all, but at least their speed stays in sync, which means I'm on the right track I think. :)
Thanks for your help Benihana!

Try printing the timeDeltaFactor to console (include an identifier so you know which belongs to which projectile). My bet is that it is fluctuating above and below your threshold, so sometimes it is clipping the movement (not moving as far as it should for that step).

Hi! I'm having a really strange problem that I just can't fix. I have a singleton that is supposed to manage every game object. It has the update scheduled by
[self scheduleUpdate];

This is the complete code of the update method of this object:

-(void) update:(ccTime)delta
{
	float d = delta; 

	for (MovingObject* obj in objectsArray)
	{
		[obj update:d];
	}
	[self collisionChecks];
	[self combat];
}

I think that d = delta makes no sense, right? I added it as a test while trying to solve my problem.
My MovingObject's update method starts like this:

-(void) update:(ccTime)delta
	// trying to factor in the time delta for movement:
	float timeDeltaFactor = delta / ( 1.0f/60.0f );
	// capping it at 4 to avoid warping that kills collision detection
	if (timeDeltaFactor > 4) timeDeltaFactor = 4.0f;
	// currentSpeed and speedMultiplier can be ignored for now, they don't change atm
	float speedLeft = currentSpeed * timeDeltaFactor * speedMultiplier;

	// this is what I'm testing with now, the real movement code is more complex.
	self.position = getPointInDirectionFromLocationWithDistance(self.angle, self.position, speedLeft);
	speedLeft = 0;

I have MovingObjects that shoot and the projectiles are MovingObjects themselves. I create two next to each other and they should be flying perfectly synchronous, but they don't. Most times but not always the left one is faster, or the right one slower depending on how you see it. But it isn't even an absolute "slower" which would increase the gap between them over time. It's like they start synchronous, after some pixels one of the projectiles starts to lag behind, catches up a little later, lags behind again, but the distance doesn't change noticably over time.
How can this be? How can I debug this?
I thought it might have something to do with how the director works or which type of director I choose. I tried them all out but I can't see a difference.
Any help would be greatly appreciated, I'm stuck on this.

There is a leak there. The first scene is PushScene-ed which increases the reference count. When the first scene is replaced by another one the first one is still retained.

I fixed it by simply releasing the first scene immediately after runWithScene.

A more robust patch should be implemented though, hopefully by a more knowledgeable Cocos2d coder than me.

Anyone who can spill the beans on making the MacGLView Transparent would be an absolute champion...

I'd also like to know how to do this. Along with adding Quicktime Movies to my Cocos2D Mac projects :)