Subclassing a CCSprite and using it with a Sprite Sheet

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

Subclassing a CCSprite and using it with a Sprite Sheet

(10 posts) (5 voices)

Started 1 year ago by Wayfarer
Latest reply from abitofcode

Tags:

Wayfarer
Member
Hey all, I'm a little confused as to how to do this. I have a class (Spaceship) that is a subclass of CCSprite, or at least I want it to be. I am also using CCSpriteSheet (I know it was changed recently, but I'm using .99.4, so when I update I will change to the new name).

So, in my subclass, I tried this:
```
+(id)initSpaceShip {
	//return [super spriteWithSpriteFrameName:@"Spaceship.png"]; //Although this worked, it returns a CCSprite, not a spaceship
	return [[[self alloc] initWithSpaceShip] autorelease];
}

-(id)initWithSpaceShip {
	if ( (self = [super spriteWithSpriteFrameName:@"Spaceship.png"]) ) {
		//custom init
		self.position = ccp(200, 50);
		self.shipVelocity = 0;
	}
	return self;
}
```
However, I get a warning saying: "CCSprite may not respond to spriteWithSpriteFrameName:" And indeed it doesn't, the code crashes at that point. So then I did some reading, and found this, which says I should be overriding that one method. So I tried that:
```
-(id) initWithTexture:(CCTexture2D*)texture rect:(CGRect)rect
{
	if( (self=[super initWithTexture:texture rect:rect]))
	{
        self.position = ccp(200, 50);
		self.shipVelocity = 0;

	}
	return self;
}

//Then I create the ship like...
self.ship = [SpaceShip spriteWithSpriteFrameName:@"Spaceship.png"];
```
And while this works, it still creates a CCSprite, not a Spaceship object. So how am I supposed to create my subclass so it's a Spaceship object, and it is also created from the sprite sheet?

Thanks for your help, I really appreciate it!!
Posted 1 year ago #
AcesWild
Member

I have a question.
Do you *NEED* to subclass CCSprite? Might it be easier to make a class (Spaceship) that has everything you need as a member variable, and one of those members will be a CCSprite, instead of subclassing and adding member variables?

Then, all of these issues will just go away.

Posted 1 year ago #
Wayfarer
Member

I'm not sure what you mean, but I definitely think in my code it would be best to have Spaceship as it's own class, (and that class should be a subclass of CCSprite), because it has methods which it should run, as well as reaction to touches. Those should all belong to it.

Thoughts?

Posted 1 year ago #

I'm doing this in mine.. I actually one class that subclasses CCSprite, and then a second that subclases the first class, so it is definitely doable.

Here's a sample of what I have.... It's not complete code, but I am not overriding the initWithXXX methods. Hope this helps some.

Here's the interfaces:

//my base class that subclasses CCSprite:

@interface PressableSprite : CCSprite <CCTargetedTouchDelegate> {

    CCSpriteFrame *pressedFrame;
    CCSpriteFrame *unpressedFrame;
}

- (BOOL)ccTouchBegan:(UITouch *)touch withEvent:(UIEvent *)event;
-(void)ccTouchEnded:(UITouch *)touch withEvent:(UIEvent *)event;

@property(nonatomic, retain) CCSpriteFrame *pressedFrame;
@property(nonatomic, retain) CCSpriteFrame *unpressedFrame;

//my class that subclasses PressableSprite:

@interface PauseButton : PressableSprite {

}

//and it's implementation
@implementation PauseButton

const float kPauseBaseX = 20.0;
const float kPauseBaseY = 300.0;

-(id)init {
	self = [super init];
	if (self) {
		[self setPosition:CGPointMake(kPauseBaseX,kPauseBaseY)];

	}
	return self;
}

// and here is where I create the instance of my class

pauseButton = [PauseButton spriteWithSpriteFrameName:@"BluePauseIcon.png"];

Posted 1 year ago #

AcesWild
Member

Let me give you an example...some pseudo code....

@interface SpaceShip:NSObject
{
   //Data Members.
   CCSprite* spaceShipGraphics;
}

Then your init looks something like this

-(id) init
{
   //Initialize data members
   spaceShipGraphics = [spriteSheet spriteWithSpriteFrameName:@"Spaceship.png"];
   spaceShipGraphics.userData = self; //don't remember off hand what the userData field is really called...but basically, it's a pointer to whatever data you want.
}

-(void) touchHandler
{
   CCSprite* spaceShipSprite = //whatever you do to return the touched sprite.
   SpaceShip* spaceShip = (SpaceShip*) spaceShipSprite.userData;
   //operate on your objects here.
}

Now you don't need to worry about subclassing. Quite often, I don't see the need to subclass CCSprite. I make a new class with all my data members PLUS the CCSprite. Then there is no confusion on how to correctly create my graphics.

Are you adding new Sprite behavior, or are you just adding your own game specific stuff? If it's just your own game specific stuff, you probably should figure out a way other than subclassing.

Posted 1 year ago #

Wayfarer
Member

Thank you for your code @sabshire, I think I've got it figured out now (Hopefully!)

@AcesWild,

I see the pseudo code, and I understand how you are doing it, but I disagree as to why you would do it that way. You end up using NSObject, instead of using a subclass of CCSprite, which I think undermines the way Cocos2D operates. Subclassing is an acceptable way to increase a classes functionality. In my case, I have my accelerometer tell my CCSprite to "Move." I can't do that with the normal CCSprite, so I've subclassed it so my specific sprite has that functionality.

And besides, you end up Subclassing NSObject, so is there really that much difference?

Posted 1 year ago #
AcesWild
Member

Thing is, I only subclass NSObject as a technicality, in that all (well, almost all) of the classes derive from there.

The only reason I am suggesting NOT subclassing is that now you are having difficulty correctly creating your objects.

I am definitely not undermining cocos2d in any way. In fact, I'm using their own sprite class! How is that undermining how it operates?

You are saying that you are having your sprite move when the accelerometer events occur. Well, that makes sense to have subclassed. But in that case, I would subclass to something like

interface CCAccelerometerSprite:CCSprite

And even then I would contain my CCAccelerometerSprite as a member in my game object class (SpaceShip, in your case)

Your game object isn't the sprite. Your sprite is the graphics for your game object.

Posted 1 year ago #
sabshire
Member

@ Wayfarer glad I could help.

@aceswild I don't want to get into the argument over subclassing with you, but it has far more advantages than disadvantages, and will produce cleaner, more reusable code. There is nothing wrong with doing what you do, and if it works for you great, but @Wayfarer was asking about why his code wasn't working, and I am sure didn't want to get into an argument over coding practices. I've done what you do, and I have done the subclassing approach, and I can say that subclassing is definitely the way to go.

Posted 1 year ago #
riq
Key Master

In case you are interested in subclassing CCSprite, here you have another sample:
http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:sprites#how_to_subclass_sprites

Both subclassing or composing are valid options. Each has its own pros & cons.
If you subclass from CCSprite or from CCNode then you'll be able to run actions against your object, schedule timers, and receive the cocos2d events among other benefits.

Posted 1 year ago #
abitofcode
Moderator

Horses for courses :D

Wierd but in Actionscript I tend to favor composition while in cocos2d I lean towards inheritance. Probably due to the built in benefits you get from subclassing CCNode as @riq mentions.

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.