Problem with spritesheet based animation and collision detection.

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

Problem with spritesheet based animation and collision detection.

(15 posts) (5 voices)

Started 1 year ago by NickFalk
Latest reply from indy2005

Tags:

Hi there, I've hit a brick wall (or at least a wooden one). I've had the majority of my game code running fine for a while now, but today I decided it was time to ad some animation to one of my sprites. Suddenly my collision detection, based on a simple CGRectIntersectsRect call won't work anymore. (It has been working fine until now). This is where I create my enemy-sprite:

CCSpriteSheet *devilSheet = [CCSpriteSheet spriteSheetWithFile:@"devilFlyer.png"];

		CCSprite *devilSprite = [CCSprite spriteWithTexture:devilSheet.texture rect:CGRectMake(0,0,59,101)];

		// A couple of random floats to vary the devil's position slightly
		float x = arc4random() % 150;
		float y = arc4random() % 300;
		// sets the initial position of the devilSprite
		devilSprite.position = ccp(320, -50+y);

		// We need to create the actual animation of frames
		CCAnimation *devilAnimation = [CCAnimation animationWithName:@"devilFlyer" delay:0.1];
		int counter = 1;
		while (counter < 48) {
			// we need a string to held onto the name of the image
			NSString *frameName;
			frameName = [NSString stringWithFormat:@"devilFlyerFrame%i.png",counter];

			CCSpriteFrame *nextFrame = [spriteCache spriteFrameByName:frameName];

			[devilAnimation addFrame:nextFrame];
			counter += 1;
		}
		// OK, now we have an animation defined,
		// time to turn it into a usable action
		//
		// First we create an animate-action with
		// the newly created animation (yes it's
		// a bit over-complicated I agree!)
		CCAnimate *devilAnimate = [CCAnimate actionWithAnimation:devilAnimation];
		// Then we create a infinitely looping
		// action to run through the animation
		// again and again
		CCRepeatForever *devilAnimationLoop = [CCRepeatForever actionWithAction:devilAnimate];
		// which we run on the sprite (phew).
		[devilSprite runAction:devilAnimationLoop];
...

Posted 1 year ago #

sodank808
Member

It must be related to how you are retrieving the CGRect for the sprite. You could try creating the CGRect from other sprite properties. This may be a better approach in the long run if you have hit-rects that have different dimensions than your sprite.

If you post a snippet of the intersect checking someone is bound to know exactly why its not working.

Posted 1 year ago #

NickFalk
Member

Thanks! You're probably right 'cause it seems to me that the animated sprite returns a vastly different CGRect than the plain sprite. (We're talking co-ordinates waasay off). Anyway I used a code-snipet I found on the web to get sprites to report their rect back. (Would like to credit the original programmer but haven't been able to relocate the tutorial). Anyway it looks like this:

-(CGRect) getBoundingRect{
	CGSize size = [self contentSize];
	size.width  *= scaleX_;
	size.height *= scaleY_;
	return CGRectMake(position_.x - size.width * anchorPoint_.x,
					  position_.y - size.height * anchorPoint_.y,
					  size.width, size.height);
}

This is how I check for those collisions:

// CHECKING FOR COLLIDING SPRITES
//
// This is where the game actually becomes a game
// if the player crashes in an object it's GAME OVER
-(void) collisionChecking{
	CGRect playerSpriteRect;// gets the rectangle of the player sprite
	CGRect baddySpriteRect;
	float playerY = eyeSprite.position.y;
	float baddyY;
	int counter = 0; // used to go through the sprites
	// yet again running through all
	// the existing baddy sprites
	while (counter < [spriteAndActionArray count]) {
		baddyY = [[spriteAndActionArray objectAtIndex:counter] position].y;
		// making a less expensive check first
		// is the baddy even in the vicinity
		// of the player?
		if (baddyY > (playerY -30)) {
			// Needs to get the rectangles
			playerSpriteRect = [eyeSprite getBoundingRect];
			baddySpriteRect = [[spriteAndActionArray objectAtIndex:counter] getBoundingRect];
			// Then checking for the actual collicion
			if (CGRectIntersectsRect(playerSpriteRect, baddySpriteRect)) {
				[self gameOver];
			}
		}

		// jumps ot the next sprite in the array
		counter += 2;
	}// ends while
}

My guess is that the different animation-frames somehow overrides the rect I've defined for the sprite(?)

Posted 1 year ago #

steg90
Member
Hi,

Can you not use the sprites bounding box they already possess? Something like:
```
if (CGRectIntersectsRect(playerSprite.boundingBox, pSprite.boundingBox)) {
// collision occured
```
Instead of using that getBoundingRect function? Probably not related, but just a thought.

Regards,
Steve
Posted 1 year ago #
NickFalk
Member

Thanks steg90 that will save me a few lines of code. If I get it to work with the animated sprites that is(!)

Posted 1 year ago #
steg90
Member

It will also save you some fps :-) Hope it helped.

Posted 1 year ago #
NickFalk
Member

Sure did Steg, but unfortunately not with my main problem. Anyone else have a clue? Or at least similar experiences? Will I have to ditch the whole collision checking method and implement one of the physic libraries just to catch some simple rectangle collisions?

Posted 1 year ago #
araker
Moderator

A couple of questions:

Why the counter + 2, are there other objects in your array?

So does your getBoundingRect returns the same coordinates as the boundingBox property?

Suppose you position a baddy on (0,0), what coordinates, width, height does your getBoundingRect method return?

Posted 1 year ago #
NickFalk
Member

@araker

First, thanks for taking an interest, then let's get down to business:

counter += 2 - Yes, there's also a description of what kind of sprite it is (baddy, bonus etc.) not used for anything just yet.

Yes the two methods return identical CGRects. However they do return a size that's wildly off the size of the graphics. I have frames sized 59x101 while the CGRect I'm returned is 200x400(!) Where on earth this this come from?

Posted 1 year ago #
indy2005
Member

Hi,

Its not returning the dimension of the whole underlying texture of the spritesheet, is it?

Regards

i

Posted 1 year ago #
NickFalk
Member

That was rather clever indy2005! Unfortunately I just checked after reading your post and there's no correlation between the two figures.

Posted 1 year ago #
NickFalk
Member

OK I've found where the 200x400 number is coming from. Seems Indy2005 was either very close or spot on (if I misunderstood him). The size reported back is the source size of the image imported into Zwoptex. Seems like I'll have to trim down all the frames before importing them to Zwoptex or change the plist manually. A bit cumbersome, but t least it should solve my problems... (Hopefully).

Posted 1 year ago #
indy2005
Member

Hi,

would be good to know the best way to do sprite collision detection from sprites sheet frames? Is there a sample which demonstrates this?

Regards

i

Posted 1 year ago #

NickFalk
Member

Well, the stuff above works fine now. The possible problem is the fact that the Zwoptex saves the size of the untrimmed image for each frame, as long as you either correct this in the plist manually or trim the images before importing them to Zwoptex it should work fine. Here it is with the change suggested by Steg90:

// CHECKING FOR COLLIDING SPRITES
//
// This is where the game actually becomes a game
// if the player crashes in an object it's GAME OVER
-(void) collisionChecking{
	CCSprite *baddySprite;
	float playerY = playerSprite.position.y;
	float baddyY;
	int counter = 0; // used to go through the sprites
	// yet again running through all
	// the existing baddy sprites
	while (counter < [spriteAndActionArray count]) {
		baddyY = [[spriteAndActionArray objectAtIndex:counter] position].y;
		// making a less expensive check first
		// is the baddy even in the vicinity
		// of the player?
		if (baddyY > (playerY -30)) {
			baddySprite = [spriteAndActionArray objectAtIndex:counter];
			// Then checking for the actual collicion
			if (CGRectIntersectsRect(playerSprite.boundingBox, baddySprite.boundingBox)){
				[self gameOver];
			}
		}

		// jumps ot the next sprite in the array
		counter += 1;
	}// ends while
}

The first check isn't needed in most cases and I'm not even sure it's needed here, just trying to reduce the overhead when there's a lot of baddies on screen.

Note: I've tried to clean it up a bit before posting it here so I might have introduced a couple of new errors. playerSprite is a global CCSprite as I find this more convenient than passing it back and forwards between different methods all the time...

Posted 1 year ago #

indy2005
Member

that sounds like a zwoptex issue? why would you want a zwoptex frame to store the overall texture size per frame? excuse my ignorance, not a zwoptex user (yet!!)

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.