Off screen sprite array « cocos2d for iPhone

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

Off screen sprite array

(16 posts) (4 voices)

Started 2 years ago by Kahless
Latest reply from natanavra

Tags:

cancelCollision

Kahless
Member
Hey everyone,

I am trying to get abit of code working that lines up my dead sprites off screen in a row to a certain number then resets and starts from the begining again, i came up with this bit of code but i am very new to programming and can't see why it fails.
```
-(void) updateBullets {
	int i;
	for(Bullet *b in bulletarray)
	{
		if(b.position.y > 500)
		{

			for (; i < 60; i++)
			{
				[b stopAllActions];
				b.position = cpv(-42*i,-50);
				[b setCanFire: YES];

					if(i = 60)
					{
					i = 0;
					}
			break;
			}
		break;
		}
	}
}
```
it is set off during the program step, i just want it to add another number to 'i' each step then reset to 0 when it gets to 60.
As it is it just drops all the sprites in one spot still.
I feel like such a noob cause this seems like such a simple problem.

Any suggestions would be appreciated.
Posted 2 years ago #

Kahless
Member

ok also tried

-(void) updateBullets {
	for(Bullet *b in bulletarray)
	{
		if(b.position.y > 500)
		{

			int i;
			i++;

				[b stopAllActions];
				b.position = cpv(42*i,50);
				[b setCanFire: YES];

					if(i = 60)
					{
					i = 0;
					}

		break;
		}
	}
}

This also doesnt work hehe

Posted 2 years ago #

pabloruiz55
Member

I don't know if this will make it work, but having this:
if(i = 60)
{
i = 0;
}
like this will never make it work.
it should be:
if(i == 60)
{
i = 0;
}

Also you are declaring the in the wrong place, foreach element in the array "i" will always start at zero.

Try it like this (not actually tested, sorry):

-(void) updateBullets {
        int i =0;
        int j =0;
	for(Bullet *b in bulletarray)
	{

		if(b.position.y > 500)
		{
                     i++;
		     [b stopAllActions];
		     b.position = cpv(42*i,50 * j);
		     [b setCanFire: YES];

		}
                if(i == 60)
                {
                    i = 0;
                    j++;
                }
	}
}

Posted 2 years ago #

natanavra
Member

Another problem with your code:

for(; i < 60; i ++)

if(i == 60)

i will never be 60, as the for loop reaches 59 and stops...
Your for declare is not too good either, try something like this:

for(int i = 0 ; i < 60 ; i ++)

This would suit better.

Your if assigns 60 to i and checks to see if that happened, in order to return a boolean value you should use double equate mark.

Posted 2 years ago #
Kahless
Member
Ah thank you pablor that works perfectly, i went with a slight variation. without the else it seemed to form short stacks but with it they are spread right out.
I might use the extra row from j++ if i need more space.
Thx for that!
```
-(void) updateBullets {
	int i =0;
	for(Bullet *b in bulletarray)
	{

		if(b.position.y > 500)
		{
			i++;
			[b stopAllActions];
			b.position = cpv(-42*i,-50);
			[b setCanFire: YES];

		}

		else
		{
			i++;
		}

		if(i == 60)
		{
			i = 0;
                }

	}
}
```
The reason i want this is so i can store my mass of projectiles off screen without the frame rate dropping (down to about 20 fps) because the chipmunk bodies are all colliding when they are stacked up and it takes up a lot of processing time.
Posted 2 years ago #
Kahless
Member

Thanks for the advice natan, i know i am all over the shop with my code, still learning!

Posted 2 years ago #
pabloruiz55
Member

Yes, i had the same problem and to make it quick i just put them at random positions.. :P but your way is much more tidy, hehe

Posted 2 years ago #
jd
Member

Kahless,
You made an interesting comment about your bullets colliding with each other in chipmunk.

How did you determine this was causing slowdown?

Chipmunk does not "report" collisions of bodies that are the same type. So if collision_type=1 for all your bullets, they should not collide. However, chipmunk does test for collision but there is an IF statement that checks if they are the same type and does not "report" it as a collision.

Let us know if you somehow determined that it is causing slowdown.

Posted 2 years ago #
natanavra
Member

@jd I experienced chipmunk's collision reports, and it's not correct - chipmunk reports all collisions even for the same collision types... and you should cancel those if you are stacking sprites...
I remember answering a dudes slowdown problem with chipmunk, and cancelling the collision report via cpSpaceAddCollisionPairFunc(space, 1, 1, &cancelCollision, nil);
Solved the slowdown prob...

Posted 2 years ago #
jd
Member

I'm confused. In chipmunk I know it handles every collision, but there is code within chipmunk that says "if collisiontype A = collisiontype B" then skip further collision processing. That's what I was talking about.

You are saying we should still take more action to prevent even that logic from happening? I could line up my objects so they don't touch when not moving if that's the case. It just seems strange to me that it would have a noticeable impact. Thanks for the feedback and sorry for the thread hijack.

Posted 2 years ago #
Kahless
Member

Heya jd

Yeah it was the chipmunk collisions with out a doubt, i am getting huge frame rate increases with my projectiles stored in an off screen array as compared to all stacked in one place, i have around 120 projectiles, it was not such a problem when i was initially only using 20 or so projectiles but as the numbers got higher so did the slow down increase, as it is my code is running at a solid 60fps with 100 or so objects flying around screen. I think it is worth doing as it is fairly simple to implement and cant really hurt, it is just giving chipmunk less to think about.

And yeah natanavra that was me you helped out with that code, it helped increase frame rates and is still part of my code, but the problem still persisted with a large amount of objects.

Posted 2 years ago #
jd
Member

Interesting. I updated some code tonight to space out my offscreen objects that have bodies. I'll run some tests tomorrow. It can't hurt so why not. Thanks for the information guys:)

Posted 2 years ago #
natanavra
Member

Glad I could help, I also noticed that setting a body's velocity might impact stuff as well, didn't check forces but in my game I have 15-20 sprites + chipmunk for each and mostly I sit tight on 35-50 FPS, at times it drops to 25... but it's pretty smoth so not much of an impact there.

Posted 2 years ago #
natanavra
Member

Sorry for double posting, but I can't really edit my post ('been 5 hrs)...

So basically I want to report, I get a rock solid 30 FPS, when capping director and schedulers!! It's perfect, when I was at 60 FPS interval, I got slowdowns ( see above post) the moment I capped it to 1/30 animation interval, the FPS stays rock solid 30 FPS, sooooo smooth!!

Just advising, 60 FPS had issues probably has something to do with the iPhone's bottleneck for 60 FPS. (idk...)

Posted 2 years ago #
jd
Member

You did setAnimationInterval 1.0/30.0 or something else for director? What did you do to cap your schedulers? I'm releasing in September, so I'm trying to hunt down performance gains anywhere I can.

I found that instead of using Delay in Actions, it's more efficient to have my step method handle the delay. Well, combined with not putting every sprite offscreen at once it helped performance. Your post about chipmunk collisions confirmed my suspicions, so I went for it and it made a difference. Thanks again.

Posted 2 years ago #
natanavra
Member
I'm glad that helped you too...
I basically capped the FPS like so:

[[Director sharedDirector] setAnimationInterval: 1.0/30.0];

this should give you a pretty big performence boost (it worked for me).
Also, stacking sprites (pre-alloc) should give you a huge boost...
stack different typed sprites at different positions.
if you wish to have collision physics for the same group of sprites, I suggested disabling the collision while they are off screen and re-enable collisions when displayed on screen... something like this:
```
static int collision(...collision callback params...) {
     mySubclassedSprite *spr = (mySubclassedSprite *)a->data //get subclassed sprite reference...
     if(spr.insideScreen)
         return 1;
     return 0;
}
```
There, this should do the trick, and keep performence for stacked sprites.
I highly recommend pre-allocation, I gained like 10-15 FPS (non-capped) and a rock solid 30 FPS (capped).

Hope this helps, I'll be glad to answer any further questions.
~ Natanavra.
Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.