A fast, easy to use, free, and community supported 2D game engine
@slipster216: I'm glad you like it.
I'll add more animation examples and documentation regarding how to use it.
Regarding the cache thing, I found that cocoa as an NSURLCache
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Foundation/Classes/NSURLCache_Class/Reference/Reference.html
So, renaming the SpriteFrameMgr to SpriteFrameCache (or SpriteCache) (and TextureMgr to TextureCache) could be a good idea.
Opinions ?
hmm.. I like the idea of using the format string, but still think numdigits would be useful as an optional parameter. So, you'd do:
[anim addFramesByString:@"frame_%@.png" start:0 end:23 numDigits:2];this would produce a filename "frame_00.png" for the first frame. If numDigits is not specified, it would produce "frame_0.png" for the first frame.
The only thing I dislike is having the format string required like that. You have to know to provide a %@ in there for the number insertion (since you'll be inserting an NSString in this case). I suppose we could do:
[anim addFrameWithPrefix:@"frame" postfix:@".png" start:1 end:65 numDigits:2];to avoid that.. Which is not as bad as I thought it would be.. hmm..
[anim addFrameWithPrefix:@"frame" postfix:@".png" start:1 end:65 numDigits:2];
The problem with this is you're now treading dangerously into an API-enforced style (in this case, file naming convention).
It's not that hard to whip up a quick animation loader singleton that does:
for(int i = 0; i < numFrames; i++)
{
[animation addFrameWithFilename:[NSString stringWithFormat:@"%@.%04d.png", baseFileName, i]];
}
M2281
Member
Maybe I am missing something here, I haven't had time to spike the frame cache, but let me toss out some thoughts in the mean time:
1) This whole idea of prefix string formats, if you really need it should IMHO be a utility extension wrapper, whatever you like. We have the concept of a tag on a CocosNode why not use that for frames as well.
2) My current issue with FrameCache is the tight coupling with zwoptex and also the dictionary as it's only needed for zwoptex. I would like to be able to do something like:
enum {
stand,
walk1,
walk2,
walk3,
sit
}
[FrameAnimation animationFromFrame:walk1 toFrame:walk3];3) Loading Frames: Still getting my head around this one, but there was something at the start of this thread that got me really exited and that was the CCSpriteSheet, and being able to either use it or not and it just works, but much faster with the sheet as a parent. With that said, aren't frames really just pointers to textures/rects on a sheet, and if so do we even need the FrameCache could we possibly just use the CCSpriteCache?
[characterSprite setFrame:sit]; // character is now sitting4) Strings, if you want need string frame names then you just use a dictionary to map them to the frames. The question is where do we store this dictionary?
Hey All,
Sorry I've been absent from this thread! Just been wrapping up a project that's been a bit of a monster. I love all the work Riq is doing here and some updates to the tool are in order but I'm just waiting to get some downtime to implement a few of them.
Let me know if there is anything I can do to help with this or the tool.
Thanks,
-Robert
I guess I don't see an issue in being tightly tied to zwopple's tool output since he's agreed to donate the code to the cocos project and it's only outputting a plist and texture, so alternate tools could do that as well. You can still create it all through code if you'd prefer, or have your own format you wish to parse.
Maybe use an IOC system where you pass the parser into the loader?
I haven't looked at the code so I'm not sure if this is how it's done already or not, but if you IOC it, you can pass in any implementation you want.
And of course make the default the zwopple implementation if none is specified.
M2281
Member
Totally understand, and thanks zwopple for the code, it's awesome!
My point was the dictionary storage located on a singleton, and then seeing a bunch of string formatting to accomplish what an enum / tag could do quite well. I haven't had the time to dig any deeper, but I would just love to be able to grab a frame by tag, like on a sprite. Tags work well on node because we have a parent that holds children, almost feels like it needs a CCSpriteFrameSet, but not sure.
@riq
I love the new names, nicely done!
m2281: I've just added this method:
/** Adds an sprite frame with a given name.
If the name already exists, then the contents of the old name will be replaced with the new one.
*/
-(void) addSpriteFrame:(CCSpriteFrame*)frame name:(NSString*)frameName;So, you can use the sprite frame cache by:
- adding frames from a zwoptex file
- adding frame from an NSDictionary
- or by adding frame manually
SVN r1522
GemNg
Member
Hi all. I found this thread(haven't read it thoroughly yet) and have a look at Sprite refactoring for v0.9 on WIKI.
I found following statement.
Drawbacks of v0.8:
* Sprite frames don't include anchorPoint / offset
* This causes wasted texture space because all sprites in an animation need to be sized to the bounding rect of the entire animation
* Atlas Sprites can't be parented to anything but a AtlasSpriteManager
* System is hard to understand for new users
So the new frames should have:
* Texture2D (not needed if the animation uses only one texture)
* Rect
* OffsetPoint
I just wonder if we should add flipX and flipY to animation frame. Sometimes, flipX can be useful. For example, your character walking left or right can be represent by flipping the sprite. I have change the cocos2d source of AtlasSprite and add flipxX and flipY support. Do you guy think it is useful?
@gemNg:AtlasSprite already supports flip-x and flip-y. and the new CCSprite supports it too.
I think it's useful. I can add a flipX and flipY in the CCSpriteFrame definition.
Zwoptex doesn't support 'flips' but it would be nice to support them.
Reducing the textures' size is a desirable feature on the iPhone.
BTW: you can achieve a flip_x by scaleX=-1.
The difference is:
flip_x modifies the texCoords, while scale_X modifies the transformation matrix (the vertex).
I am just starting a new iphone game and learning cocos and I hit the limitation about not being able to parent things when using atlases. Then I find this thread and its like, what an amazing timing co-incidence ;)
From reading the entire thread I gather that it will now be possible to do a joined sprite where you have say a center and then attach a head, arms and legs and let them bob a bit a-la-zombieville.
Just to make sure I understand, if you do multiple children of a single node but all the images are from the same texture file, the renderer can batch them correctly and still get the "same texture" performance boost correct(when using this new system)?
Also I get the impression that if we don't mind api changing we can start using this off the dev branch now right? Or is it not quite ready for that?
@GemNG: added flip support in animations. If you want to try it, see tests/SpriteTest.m. SVN r1523
@greyhoundgames: You will still need to add the children to an SpriteSheet object in order to get them batched, and they must use the same texture.
But yes, the API is much simpler now. You can code all your game using Sprites and if you want to batch them you need to added to a different parent (SpriteSheet), that's all.
GemNg
Member
Actually, what i am doing right now is define animation in a .plist file, and i have written a Class called AnimationNode to play animation simply by passing the name of animation.
e.g. [animationNode playAnimation:@"Walk"];
If frame do support flipX, we can setup animation at loading and just forget it and play it. Otherwise, we will need to keep check with the sprite every cycle to change the flipX/scaleX.
Also, will cocos2d plan to support any animation editor like MotionWelder.
Why is it not possible to batch things from the same texture atlas when their parents are other nodes in the same texture atlas?
My engine that did batching basically created a giant array of vertex\text co-ords and I just keep writing to it until I hit a sprite who is tied to a different texture. Then i render it all and then continue rendering the next big batch. Is that something doable? I could provide code if needed. Basically I guess I am missing what the connection of the parent hieracrchy is to what texture things come from. Thanks!
@greyhoundgames: SpriteSheet only supports one texture id. It's a "dumb" class, if you add an sprite with a different texture id, it will raise an Assert.
But You can do what you are saying by creating a new class that moves the sprites to the correct SpriteSheet.
The only problem I see is the Z-order between the batches. But that can be "workarounded" by using the real OpenGL Z-vertex and a 2D projection.
eg:
class BatchSprite:
def addChild( sprite ):
// returns the correct sprite sheet from a dictionary of sprite sheets
SpriteSheet *sheet = getSpriteSheetForTextureId( sprite.texture );
sheet.addChild( sprite )I was reading this thread today for the first time, good thing too cus there's a ton of great info in here.
One thing I'd like to say, that I really love about cocos2d and a primary reason why I enjoy using it. Is how it doesn't try to be 'too smart' about everything, I can create wrappers for things I want to.
I don't find myself wrestling with the framework because it was so customized and tailored for a specific game/type of game/usage to the point where its difficult to use for anything but that narrow case. This is a big drawback of many frameworks as they mature, and it looks like cocos2d is not suffering from that at all.
Keep up the good work dudes!
So if i have 20 images on a spritesheet I can make 2 sprite nodes and have #2's parent be #1? If so then thats exactly what I wanted. I thought when you said they had to be on the same sprite sheet you meant attached to the sheet as its parent, but now I think I see what you are saying. And my other question, is it stable enough to start coding against? Just grab the latest and replace my current cocos2d? Did you chance any of the other lib's versions etc or just replace the cocos folder and thats it.
@greyhoundgames:
For the moment (there is an open issue: http://code.google.com/p/cocos2d-iphone/issues/detail?id=346 ) SpriteSheet only render it's children, but not it's grandchildren.
So if you have:
p = SpriteSheet
s1 = Sprite
s2 = Sprite
s3 = Sprite
p.addChild( s1 ) // OK
p.addChild( s2 ) // OK
s2.addChild( s3 ) // WON'T WORK at least todayregarding the 2nd question:
yes, you can use it, but take into account the API is not frozen, so it might change during the following weeks.
trunk contains what will be more or less 0.9.0-alpha.
Perhaps the zorder should be a delta of the parent. So if its 0 its at the same 1, 1 means its ontop of parent and -1 behind. It sounds like its fairly easy to re-enable this by just removing the override stuff you put in for addChild and it looks like one other place. I will look at it some more when I get closer to needing that functionality in my app.
So you would render all children who's z is less, then render yourself and all children>= your z. They would do the same with their children etc.
@greyhound: yes, the z-order is relative to the parent. Sprites whose parent is not an SpriteSheet work as you said. Take a look at CCNode.m / CocosNode.m.
But we are discussing how to batch the rendering... a possible solution is described on the issue I mentioned before.
Hey Robbert (zwopple),
Would you mind either creating a new project or submitting your tools source somewhere? I ran into a few errors tonight that prevented me from exporting textures and plist files, and it would have been really nice to load the project up in eclipse and see what was going on. Additionally, I know a lot of people would love an air version, and I could start the port if you don't have the time.
@robert (or any other one who wants to modify the Zwoptex code once it is available):
0.9-alpha, when parsing the plist, it supports 2 new properties:
flipX: if not present, it defaults to false
flipY: if not present, it defaults to false.
if flipX is true (it is parsed as a boolean value), then the frame will be displayed flipped across the horizontal axis.
The same the flipY, but with the vertical axis.
@riq sounds great! I'm unsure how useful it will be in the tool directly but it's definitely something I frequently do manually when in Obj-C.
The source code for the app should be coming shortly! Great work with 0.9!!
-Robert
@zwopple I sent you an email with a feature request a couple of days ago, but it indeed seems email is bouncing...
It would be very nice to have a tool in zwoptex to modify the anchor point for each sprite in the sheet. The coordinates could either be saved instead of the offset value now (which is how much is cropped from the image, right?) or as new properties. When rotating or scaling sprites for example, the anchor point has to be set right. I am using a fixed anchor now, because manually setting each anchor is a bit tiring.
Great tool by the way! Saved me tons of memory already
iisystems
Member
I have not yet moved to 0.9. Does this Zwoptex code have support for variable sized sprites? I was about to post a new topic, but figured I should check here first since there is so much discussion about added sprite flexibility. I have AtlasSprites which I currently swap out AtlasSpriteFrames to show health damage mid-animation. I also purge the animation frames at various points and completely replace them with another set. It's at this point, that I would like to be able to resize the sprite rect as only a portion of the character is visible when I swap in a new set of frames. Currently, my atlas has a lot of wasted pixels because I've sized each frame to the maximum size for each character. I thought I could shrink my sprite by calling:
CGRect rect = CGRectMake( /*smaller size*/ );
[self setTextureRect:rect];But even this ends up stopping my animation (or preventing it from starting?) and fixing it on the frame defined by rect.
So does Zwoptex have support for changing a sprite's size once it's initialized or is anyone doing this a different way? I am trying to not have to destroy the sprite and create a new one...
Thanks!!
You must log in to post.