Atlas Sprite (cocos vs Zwortex, best of both worlds?)

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

Atlas Sprite (cocos vs Zwortex, best of both worlds?)

(121 posts) (25 voices)

Started 2 years ago by slipster216
Latest reply from JeDi

Tags:

« Previous 1 234 5 Next »

slipster216
Moderator

We haven't really got into defining animations in a file yet, though once we have cocos running on macOS I suspect an editor would be pretty easy. And I'm sure it'd be pretty easy to add one to the zwoptex tool once that's open source; I even have some classes for sliders with events on them written for AS3 from an old project.

Once you go that route you really don't want to be defining a target at all, but rather having some class receive events by name and processing them. If thats where we're eventually headed, delegation probably makes sense. Often the model for an api is pretty different if your data driving it than when your doing things in code. While the delegation model creates a bit more processing code than calling selectors directly, it creates a nice abstraction between your event data and code. If our eventual goal is to create a robust tool set for cocos, then I'd support delegation. I like the idea of (optionally) passing a <ccAnimationDelegate> on the play function rather than assigning delegation to the animation.

Posted 2 years ago #
riq
Key Master

Sprite/AtlasSprite refartor started.

r1488:
- CCAtlasSprite can draw itself

API is still very very very volatile, and will change in future commits.

How to test it:
- AtlasSpriteTest works as expected
- SpritesTest: is using AtlasSprite insteads of Sprite to test the new code

Posted 2 years ago #
cloudmike
Member

@riq Excellent!

Posted 2 years ago #
manucorporat
Member

I question:
then, Is Sprite class deprecated?

Posted 2 years ago #
riq
Key Master

@manu: no, the one that will be depracted is AtlasSprite, but for the moment it's easier to test everything with AtlasSprite and not with Sprite

Posted 2 years ago #

riq
Key Master

questions:

Which API do you like most ?

// using offset
Sprite *sprite = [Sprite spriteWithFile:@"atlas.png" rect:CGRectMake(x,y,w,h) offset:ccp(ox,oy)];

// or using anchor point
Sprite *sprite = [Sprite spriteWithFile:@"atlas.png" rect:CGRectMake(x,y,w,h) anchorPoint:ccp(ax,ay)];

both of them have the same functionality.

offset: is in pixels
anchorPoint: is in "percentage"

Posted 2 years ago #

cjl
Member

Offset, but I tend to think in pixels.

Posted 2 years ago #
manucorporat
Member

when you set ´offset´ or ´anchorPoint´, it is for sprite position, true? or for textureCoords?.
Am I wrong?

So, my vote go to offset, because you can set the AnchorPoint(percent) with CocosNode:setAnchorPoint.

Posted 2 years ago #
slipster216
Moderator
How would percentage even work though? Thing is, the offset position can be outside of the sprites frame (following the zwopple example). Or are we really taking about anchor point and not per-frame offsets here? I think anchor points should be anchor points (and in percentage, same as now), but offsets are always in pixels (and stored on a per frame basis).

I thought that we were going to do something like so (don't have cocos source in front of me, so excuse the psudo-cocos code):
```
Sprite* sp = [Sprite springWithFile:@"atlas.png" rect:CGRectMake(x,y,w,h) offset:ccp(0,0)];
[sp setAnchorPoint:ccp(0.5,0)]; // bottom center of sprite
```
and it would use this as the anchor points for all frames, regardless of the per-frame offset. Most of the time this stuff will all get loaded from the plist, but assuming we're hand coding it, an animation might look something like this:
```
AtlasAnimation* anim = [[AtlasAnimation alloc] init];
[anim addFrameWithName:@"walk_01" image:@"atlas.png" rect:CGRectMake(x,y,w,h) offset:ccp(12,0)];
[anim addFrameWithName:@"walk_02" image:@"atlas.png" rect:CGRectMake(x,y,w,h) offset:ccp(-12,0)];

[sp runAction:[Animate animation:anim]];
```
Thus, while the sprite has a single anchor point as before, each frame has it's own offset allowing each frame in the animation to adjust correctly for non-square frames.
Posted 2 years ago #

riq
Key Master

It works like this:

anchorPoint_ = ccp( (offset.x / rect.size.width) + 0.5f,
						   (offset.y / rect.size.height) + 0.5f );

Since the default anchorPoint is (0.5,0.5), offset means: how many pixels do you want to move the anchor point from the center.

Of course, we can redefine the meaning of offset like, how many pixels do you want to move the anchor point from (0,0).

revision r1489 uses the offset API.

+(id) spriteWithTexture:(CCTexture2D*)texture;
+(id) spriteWithTexture:(CCTexture2D*)texture rect:(CGRect)rect;
+(id) spriteWithTexture:(CCTexture2D*)texture rect:(CGRect)rect offset:(CGPoint)offset;

+(id) spriteWithFile:(NSString*)filename;
+(id) spriteWithFile:(NSString*)filename rect:(CGRect)rect;
+(id) spriteWithFile:(NSString*)filename rect:(CGRect)rect offset:(CGPoint)offset;

Posted 2 years ago #

slipster216
Moderator

Just to be doubly clear to everyone chiming in:

AnchorPoint - a single center point for a sprite which acts as the center for all transformations

Offset - an additional transform for for each frame in an animation, allowing you to have varying size frames in a sprite sheet..

We actually need both, otherwise we'd be assuming all sprite's on the sheet are of constant size. I think anchor point should remain as is (percent) while offsets only make sense in pixels.

riq: It might make sense to approach this by getting the plist loading first; it will force your data to just work. If you need some good example atlases with animations that change the frame size I can send you some..

Posted 2 years ago #
slipster216
Moderator

riq:

The way that zwopples plist stores it is relative to the center of the rect (or default anchor point). So that makes sense to me.

Posted 2 years ago #
manucorporat
Member

@slipster216
thank you, I have understood the "offset" very well.
I didn't know it, because I don't use Animations.

Posted 2 years ago #
riq
Key Master

@slipster216:
Thanks, yes, probably I will need some examples.

and yes, anchorPoint (or offset) will be part of the frame so animations work ok. I'll finish the Sprite/AtlasSprite merge and then I'll play with the animation code.

Posted 2 years ago #
slipster216
Moderator

ok, I'll zip up some data and send it your way..

Posted 2 years ago #
abitofcode
Moderator

I've stuck up a quick XSL stylesheet for anyone wishing to convert the Zwopple plist into AtlasSprite statements via Firefox. Available here http://www.abitofcode.com/sites/default/files/example.zip

Can't wait for version 0.9 :)

Posted 2 years ago #
rolando
Moderator
I was playing today with the plist outputted by Zwopple, and I found a drawback: the "frames" although name referenced, are not in order when you take them out: since they're stored as a Dictionary (where the name is the key and the value is another dictionary specifying x,y,width,height and offset), if you try to store your animations, the frames do not end ordered.

NOTE: I'm not using Zwopple's code, only the plist

For instance:
```
frames:
  animation1 0001 => {x, y, w, h, offx, offy}
  animation1 0002 => {x, y, w, h, offx, offy}
  animation1 0003 => {x, y, w, h, offx, offy}
  animation1 0004 => {x, y, w, h, offx, offy}
  animation2 0001 => {x, y, w, h, offx, offy}
  animation2 0002 => {x, y, w, h, offx, offy}
  animation2 0003 => {x, y, w, h, offx, offy}
  animation2 0004 => {x, y, w, h, offx, offy}
```
When you get the NSDictionary, frames is a Dictionary and the frames name's are the keys... If you want to build animations you either have to fetch each frame by name (slow!) or sort the frames in AtlasAnimation after adding each frame...

How did you guys solved this?
best,

rolando.
Posted 2 years ago #
slipster216
Moderator

The zwopple code has you fetch them by name to build an animation. I generally name things with a prefix and number anyway, so I just loop through the frame count and add them by name. There's no concept of an actual animation in the plist format, just frames, though we could certainly create an editor to allow you to define them through a plist as the next step.

Remember, your sprites might not even have animation; you might just pack them all on to the same page to save memory and optimize drawing.

Posted 2 years ago #
Blue Ether
Member

Rolando: What I've done is to pre-fetch the frames by name. I create constant arrays of CGRects (I don't use offsets so you might declare your own struct to include those) and have static class methods run on startup to do the fetching and storing of the necessary frames. Then at run time I access the CGRects stored in the constant arrays.

Posted 2 years ago #
rolando
Moderator

@slipster216 yeah, I realize that the sheet might not necessarily have an animation, but some times you need to have the frames in order. Anyway... in the end I think that what I'm doing now (sorting frames) was not entirely wrong :-)

thanks!

Posted 2 years ago #

riq
Key Master

r1502 has:

* zwoptex animations
* fixes

how to use it:

// add the sprite frames in the sprite frame manager
[[CCSpriteFrameMgr sharedSpriteFrameMgr] addSpriteFramesWithFilename:@"animations/grossini.plist"];

// helper function: create an sprite with the values of an sprite frame
CCSprite *sprite = [[CCSpriteFrameMgr sharedSpriteFrameMgr] createSpriteWithFrameName:@"grossini_dance_01.png"];

// add the sprite
[self addChild:sprite];

NSMutableArray *animFrames = [NSMutableArray array];
for(int i = 0; i < 14; i++) {

	CCSpriteFrame *frame = [[CCSpriteFrameMgr sharedSpriteFrameMgr] spriteFrameByName:[NSString stringWithFormat:@"grossini_dance_%02d.png",(i+1)]];
	[animFrames addObject:frame];
}

// create an animation action
CCAnimation *animation = [CCAnimation animationWithName:@"dance" delay:0.5f];
animation.frames = animFrames;

// run the action
[sprite runAction:[CCAnimate actionWithAnimation:animation]];

What's missing:
- support events in animations
- API fixes.

Doubts:

a)
- I don't like these names:
* SpriteManager: This is the old AtlasSpriteManager
* SpriteFrameMgr: This is used to cache to sprite frames

I think they are very confusing.
I was thinking of renaming SpriteManager to Spritesheet. What do you think ?

b)
Also, I was thinking of changing the Animation API.

old:

// delay is part of the animation
CCAnimation *animation = [CCAnimation animationWithName:@"dance" delay:0.5f];
id action = runAction:[CCAnimate actionWithAnimation:animation];

new:

// delay is part of the action
CCAnimation *animation = [CCAnimation animationWithName:@"dance"];
id action = [CCAnimate actionWithAnimation:animation delayBetweenFrames:0.5f];

What do you think about it ?

Posted 2 years ago #

slipster216
Moderator

How about delay is part of both. So you can set it when you create the animation, or override it when you play the action.

That said, if I had to choose one I'd go with the delay being part of the animate action; seems more 'correct' to me.

SpriteSheet or SpritePage seems more correct than SpriteManager, since it's really the frame manager thats an actual manager. We could then shorten SpriteFrameManager to SpriteManager, so you'd have:

SpriteSheet* // the actual texture/optimized drawing object
SpriteManager* // the frame manager

Posted 2 years ago #
M2281
Member
+1 for SpriteSheet

I also prefer [SpriteFrameCache shared] not sure if just using "shared" is a problem, or [SpriteCache shared]

I also have another idea for animations on multiple sprites, on the parent node you call animate and pass a bitmask, Sprite1 | Sprite2, and the actions are executed on only those two sprites. the sprite then get a flag property.

We used this for animations in our previous framework and it worked well, we also used a helper enum, shown below, which has the bitmask values predefined. In this example there is a 31 sprite limit in this use case, but I believe that can be upped to 63, enough for most use cases.
```
enum {
 Sprite0   = S0
 Sprite1   = S1
 Sprite3   = S2
 SpriteAll = SAll
}

enum {
 SNone	= 0,
 S0     = 1 << 0,
 S1     = 1 << 1,
 S2     = 1 << 2,
 SAll   = 4294967295
} SFlag;
```
Posted 2 years ago #
mromanuk
Member

SpriteSheet and delayBetweenFrames are better than the original names.

Posted 2 years ago #
slipster216
Moderator

delayBetweenFrames is so long though. Verbosity can be good, but it's nearly a curse in Objective C..

We could also express it in fps, which is way shorter and understood by everyone here. I also doubt many people talk to their artists about doing animation at .03333ms..

Posted 2 years ago #
riq
Key Master

Update:
- the Sprite/AtlasSprite merge was finished.
- the SpriteFrameManager (zwoptex support) was finished.
- the Animation (zwoptex support) was finished

Documentation (draft):
http://www.cocos2d-iphone.org/wiki/doku.php/developers:sprite_refactoring

missing:
- Animation is still using the old API.
- Animation with events. I have nothing against supporting events, but I think the logic will be very similar to the Sequence + Spawn action. So I was thinking of supporting actions instead of callback-events.... just a thought.

doubts:
- CCSpriteFrameMgr or CCSpriteManager or CCSpriteCache or CCSpriteFrameCache or another one ?

If we are going to use the Cache suffix, then I think that CCTextureMgr should be renamed to CCTextureCache

Is there a convention in Cocoa for these type of classes ?

Posted 2 years ago #
M2281
Member
@riq

Thanks for getting this done so fast.

I would love to have a way to setup frames in code, and also specify a int tag. IMHO the zwoptex support should be a utility or wrapper, containing a dictionary that indexes the underlying frames, this allows us to bypass the use of strings.
```
Advantages/Disadvantages

+ Ability to use int enums for frame tags
+ Ability to run from tagStart to tagEnd
- May require refractoring out the dictionary
```
Posted 2 years ago #
riq
Key Master

@m2281:
Could you post a draft of the API that you would like to have ? thanks.

Posted 2 years ago #
slipster216
Moderator
@riq:

I'm extremely busy lately and haven't had a chance to play with it yet; but looking at the example it looks great! Nice work.

@M2281:

Could you also provide a use case? I suspect what you want to be able to do is effectively something like:
```
[anim addFramesWithStart:kFirstFrame end:kEndFrame];
```
If that's the case, perhaps we could just have a helper function like this:
```
[anim addFramesWithPrefix:@"framename_" start:kFirstFrame end:kEndFrame numDigits:2];
```
Which would be a very convenient way to add numbered frames. Btw: NumDigits is for specifying your frames like frame_02 instead of frame_2.
Posted 2 years ago #
rolando
Moderator
+1 for @slipster216 idea:
```
[andim addFramesWithPrefix:start:end:]
```
sounds about right. The problem I see is numDigits... you have to build the format string to build the final string... I think it would be better this way:
```
[anim addFramesWithFormat:@"framename_%02d" start:firstFrame end:endFrame]
```
That way you take care of your format, because someone might like to name their frames "%05d weird frame.png" (remember that the zwopple tool puts the extension on the name of the frame)
Posted 2 years ago #

RSS feed for this topic

« Previous 1 234 5 Next »

Reply »

You must log in to post.