Alternative to Sprites for 2000+ On-screen Animations

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

Alternative to Sprites for 2000+ On-screen Animations

(13 posts) (7 voices)

Started 2 years ago by laxcat
Latest reply from laxcat

Tags:

laxcat
Member

I'm working on an app for a client that takes your photo and does what is essentially a mosaic effect. We were then planning on performing dynamic animations to transition these "blocks" in and out of the screen. The problem is there are 2400 of them (the image mosaic is 40 x 60 blocks), and my edge phone just can't quite handle 2400 atlas animations at once. (It drops to 5fps or so.)

The obvious solutions would be to either reduce the number of blocks (sprites), or to perform an animation that doesn't require each of the 2400 objects to be unique. Unfortunately changing the resolution is not a great option at this point. (Read: the client has demanded it.) Changing the app so it doesn't require unique animations for each block is possible but not ideal. Our team really likes the animation effect. (It runs fine on a 3GS!) And even more than that we like the flexibility of the atlasanimation, allowing us to possibly come up with other animations easily.

So here's the question. Looking at what's possible with particle systems and other apps out there, it seems that what we want should be possible, but the atlassprite/atlasanimation system (and maybe even cocos2d) is probably just not designed for it. What are some other things within cocos2d that I should be looking at? Is there a way to maybe batch some of these calls together a little bit? Should I be using something other than atlassprites/atlasanimations? Would the particle system even be an option?

Some more info:
• I've done a couple of iPhone apps at this point, but I'm still super new to Objective-C and this is my first time working with cocos2d.
• There are technically only 15 unique animations, because there are only 15 different colors of blocks. Could there be a way to leverage that to fewer graphics calls?

Thanks in advance!

Posted 2 years ago #
terrym
Member

What is the iPhone Edge, as seen this in our stats lol.

Posted 2 years ago #
patrickC
Member

Well if you're already using AtlasSprites then you're already grouping your draw calls into one.
How many texture sheets do you have?
In case you have one texture sheet per animation, you could try compacting them all into one (or more), thus reducing the number of texture switches and draw calls even more.
Other than that I can't think of much else sorry, but then again I'm no expert.

Posted 2 years ago #
Matt Rix
Member

terrym, iPhone Edge is the first gen iPhone that uses Edge instead of 3G

Posted 2 years ago #
laxcat
Member

Thanks for the replies, guys. PatrickC, that's a great suggestion, but we are indeed already operating off a single spritesheet. This spritesheet is used to generate 15 different animations based of the 15 different colors possible in the final mosaic.

The real problem (I think) we're running into, is all the individual action instances. I wish I knew more about all this so I could see where the actual bottleneck is. Likely we will have to jump down a little lower level to accomplish our specific animation, but we would like to avoid it as no one on our team has much experience with that.

Mostly what I'd love to get from the cocos2d community is to figure out if there might be another approach we might take. Our animations are so simple, that we might be able to achieve what we need from the particle system, or something like it, or maybe through modifying it.

Still looking for suggestions, if anyone has them.

Posted 2 years ago #
Karl
Member

If they're all animating at the same speed, then you could just make a big list of sprites + their associated animation. Then you either make a custom action for animating the whole thing at once, or you could animate from a game loop.

Each animate action needs to do some division math and a few if statements each time its update method is called. That can add up if you have to do it 2000+ times each update. And if you're not retaining the actions, you also have the alloc/dealloc overhead (you'll see them in the debug output).

Posted 2 years ago #
bradparks
Member

If you're using actions, maybe using a schedule instead would improve your speed.... there's some other general performance tips here:

http://www.cocos2d-iphone.org/forum/topic/2677

Posted 2 years ago #
patrickC
Member

I would do what Karl suggested.
A simple way to try it would be to have a list of all the AtlasSprites and itearate over them, changing their "state" with a setTextureRect.

Can't really think of a quicker way...

Posted 2 years ago #
laxcat
Member

Awesome suggestions! I'll try some of these out and come back with an update in the next couple of days.

This is a pretty exciting project we're working on and I'm excited to share our results with the community.

Posted 2 years ago #
nsxdavid
Member

The first thing is to know for sure what's slowing you down.

Disable the animations themselves (or do half as many, etc.) and see what affect that has on your framerate.

If you are sure it's the animations, then use insturmentation (or Shark) to try and pinpoint more sepcifically what. This might give you a clue as to where you need to focus.

What kind of animation are you doing with each block?

-- David

Posted 2 years ago #
laxcat
Member

Each block is using an altas animation. Right now they're all using the same animation instance. (So just a single color.) A unique sequence action is then created for each block: block specific delay => action based off the animation.

I'm about half way through implementing a game loop as per Karl's suggestion. This method would use no animations whatsoever and would manually adjust each block's textureRect using math(!).

Update on whether it fixes my problem coming soon.

Posted 2 years ago #
laxcat
Member

Success! Stays above 20fps on the edge which is totally acceptable, given the fact that there are 2400 sprites on screen! (A near perfectly constant 60 fps on the 3GS!) Basically I removed all actions and animations for the blocks and modified the Block class so each one is running a schedule. When the "build in" is triggered I set the delay and color into each block and each block just handles itself from there.

nsxdavid, I probably won't have time to do extensive checking into what exactly the hang-up was (this IS a client project it's on a tight deadline) but we can guess it was something to do with all the actions/animations. Not knowing much about how cocos2d handles actions and delays, but since the delay is derived mathematically I think stuff might have been firing between "ticks". Is that possible?

Anyway, thanks so much for everyone's help! We'll be sure and post the final project once it's live.

Posted 2 years ago #
laxcat
Member

I doubt anyone is still looking at this, but just in case, the project in question here is now live. Check out the announcement post here: http://www.cocos2d-iphone.org/forum/topic/3766

Thanks again!

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.