I would run the performance stuff in instruments (or roll your own) and see where the bottlenecks are in the code. If it seems like you are spending too much time in the CA methods, then double check how you are loading your layer contents and make sure you arent re-loading them every frame, etc. (so load the contents once, and then change the contents rect every frame etc..)

Good luck!
-B

I have made a lot of headway with my game, learned so much about animation, specifically, looking out for dropped frames and catching up, velocity calculations and determining key frames. However (you know this was coming), one thing still alludes me.

When I used the UIKit animation routines, the animation where faultless, especially when it came to a scaled UIView and animating position. Using the manual frame by frame animation seems to suffer from dropped frames a little when using a scale of 1, however, when changing the scale of the entire scene to, say, 0.75, I get really bad choppy movement.

I thought this was probably because I was rendering frames perhaps twice in the same position and hence giving the allusion of choppy animation and compensated by calculating the number of frames required to traverse the scaled distance based on non scaled velocity. Even though, I was rendering less frames in the scaled view and increasing my delta per frame, I was still getting really choppy animation. When I reverted back to UIKit, it was silky smooth.

I think I am missing something fundamental about animation in iOS, do you possible see what it might be?

When I first implemented the CADisplayLink, I noticed that my frame rates would stall, especially under situations where there was a lot of gestures going on. I kept thinking how using NSTimer didn’t seem to suffer from this but DisplayLink does. I was beginning to question this entire approach but thought surely these guys knew what they were talking about, hence I must be doing something wrong.

I then decided to roll my own gesture recognition methods and that seem to have cleared it all up. The UIGestureRecognizer appears to play havoc with high frame rate animation. The NSTimer seems less prone to it but call still suffer dropped frames.

Now I guess I just need to do some trial and error to determine what speed gestures constitute a swipe and how much travel needs to occur. FUN…..not!

in relation to a master clock, I would say that in most cases this is the best way to go. If performance isn’t an issue (a rarity on the iDevices :-) then having multiple clocks is an OK solution. However, each timer you have running requires extra overhead, so if you can keep it to a single master then all the better.

the CADisplayLink is basically already a singleton master clock, however I generally make another object (sometimes a singleton) that handles all the scheduling for any objects that need it.

However, once you have a master scheduler then you can also do clever things like set up delayed scheduling (much like NSObject’s performSelector:withDelay method, but synced to your timer.) So i will set up some methods that are like: call this selector on this object after this many seconds, or call this selector on this object every x seconds etc… and let the scheduler handle the dispatch. (basically as you suggested, this is how I have objects ‘register’ for updates. but I have a few different ways so that I can have one-offs and somethings that are only updateing every 5 seconds or something as well as things that need updates every frame.)

Once you have a master scheduler, then things like sharing information between threads becomes a bit easier. You can schedule some special times to query the other threads and let them update your scene objects at times when you are not calling any other scheduled objects.

Cheers!
-B

I implemented the design pattern you gave and it really has made such a difference to the animation. I have such a granular level of control and the animation is really smooth. Great tip about having odd and even frames, where by using odd and even frames for positioning and only even frames for image masking, that a fine example of knowledge vs experience.

I have a question about the clock implementation. Is it standard practice to implement a master clock that all animations are driven from or implement a clock per animation group?

If the practice is a master clock, then I was thinking of making a singleton static clock object where by I register and de-register selectors to perform in the background. But is it worth the effort, or is just having a clock per animation group adequate.

FYI, my term animation group refers to say a clock for the sprite that is allocated dynamically as the sprite does something and a clock perhaps for an animation that is constantly going in the background.

Sorry to keep firing off these questions at you but getting access to a seasoned game developer is a rarity and ever so valuable.

I will need time to digest what you have written and look into it’s implementation.

I cannot thank you enough for your guidance. This site is a very valuable resource for people like me as I have out grown stackoverflow (well perhaps not from what you are showing me).

I’ll look into the IGDAM, this is all new to me :-)

For anything sprite related (even when I am not using OpenGL) I tend to implement a master clock that runs at some integer fraction of the display rate (ie nowadays I use the CADisplayLink, but used NSTimers or NSThreads before CADisplaylink was available on most devices. (I think for now it has become pretty safe to support 3.3.1 and above which mean you always have a CADisplaylink for your timing needs :-)

So with that in mind I tend to design all my animating objects with an update method built in (sort of standard game loop style) and in that update method I handle any state changes that need to occur. So if my update is running a 60 fps and my animation is running at 12 fps then every 5 frames I update the animation sprite, but every frame I might be updating the position so that the movement is nice and smooth.

Obviously this is more work than just using the core animations but if you need to sync your animations with movement, then I would say that trying to shoehorn CA into that role is probably not the best idea. (this isnt to say it cant be done, but once you get more than a few independently moving and animating sprites then it gets a bit dicey in terms of performance and keeping everything in sync)

A great deal of the really slick UIKit stuff is really good for user interfaces (where much of the animation is secondary to the actual function of the interface, so if you miss a frame here and there, or your slide out animation is a few frames too slow nobody will ever notice) Once you start doing games you generally need to have better control so it is usually worthwhile to roll your own animation system that is tailored to your specific problem set.

Cheers!
-B

Hey, if you are in melbourne you should be coming to the IGDAM meetups, http://igdamelbourne.org/ once a month, usually on a tuesday (was one just last night) come and say howdee :-)

This saved me such a lot of R&D. Before reading this post, I was actually using cached arrays of images depending on what the sprite was doing, however I was using the NSTimer to swap images much like your approach. I have gone from 60 image frames to one, and re-implemented my cached arrays of image to caches arrays of frames.

Thanks so much for the blog post….

I have one question though. In my old approach, I have two animations going, one to swap out images and the other to move the location of the spite and I am not sure I had the best practice implemented.

I would use an animation block (iOS4 style) for the center position over a duration “x” and implement the animation delegate “animation did start” where I would start a timer. The timer would call a selector to swap out the images every x/(Frame Numbers). I can’t help but feel this approach is prone to falling out of sync between the two animations. Should I be doing this all from a timer where the selector not only draws the new frame but moves it too using the transaction block?

Your insight and design pattern would be greatly appreciated.

P.S. I am in Melbourne too ;-)

Basically I vote for you doing a post on your program =)

Yes you are absolutely correct. In fact I would definitely suggest pre-calculating your atlas positions prior to your animation.

I have a little program that builds the atlases for me from individual images (if I ever have free time, i might even do a post about it).

In any case I generate a plist meta file with all the frame positions in the atlas and then load that meta data at the same time I load the image (usually sometime before the animation is required)

This is also handy because you can then be very clever about your image usage. For instance, the last four or five frames of the example animation are really only about half the height of the first few, that is a pretty big waste of space (and memory). Instead I pack them into the atlas with the minimum amount of space around them and just record a center offset so that I can (in core animation or OpenGL) move it to the right position in the animation cell.

This way you can pack your atlases much much tighter and save tons of space on the iPhone :-)

Anyway, it is early here so hopefully that makes some amount of sense.

Cheers!
-B