I'm working on an iPhone App where I rely heavily on timers and animations, but I've realized my game is really slowing down and lagging on certain aspects of the game. I'm not quite sure how to improve this without removing any animations or anything.
Essentially what I'm using is the accelerometer to update my character's position (Left/Right). I also use several timers to read from different URLs, update images and the one that lags the most is one that loops an image to move from left to right.
Basically I'm using about 6 or 7 timers and the Accelerometer, is there a way I can improve the performance of my game without having to remove any of my animations or changing the interval of the timers?
Thanks in advance!
Try use Allocation
RUN-> RUN WITH PERFORMANCE TOOLS->Allocation
to see which part is overload in the application
Instead of using NSTimer to animate, you might want to look at using the animationImages property in UIImageView (which lets you show multiple frames of animation, possibly looping) or beginAnimations within UIView (which lets you move an object along a path, among other things).
A good place to start is with this question on recommend reading for iPhone animation, although for reference the documentation in XCode and Apple's programming guides are good sources by themselves.
What others have suggested - in terms of using a game loop - make sense, too, but depending on the complexity of your game, sometimes just letting the iOS SDK take care of your animations for you can be good enough.
Related
I'm working on an iPhone game that involves only two dimensional, translation-based animation of just one object. This object is subclassed from UIView and drawn with Quartz-2D. The translation is currently put into effect by an NSTimer that ticks each frame and tells the UIView to change its location.
However, there is some fairly complex math that goes behind determining where the UIView should move during the next frame. Testing the game on the iOS simulator works fine, but when testing on an iPhone it definitely seems to be skipping frames.
My question is this: is my method of translating the view frame by frame simply a bad method? I know OpenGL is more typically used for games, but it seems a shame to set up OpenGL for such a simple animation. Nonetheless, is it worth the hassle?
It's hard to say without knowing what kind of complex math is going on to calculate the translations. Using OpenGL for this only makes sense if the GPU is really the bottleneck. I would suspect that this is not the case, but you have to test which parts are causing the skipped frames.
Generally, UIView and CALayer are implemented on top of OpenGL, so animating the translation of a UIView already makes use of the GPU.
As an aside, using CADisplayLink instead of NSTimer would probably be better for a game loop.
The problem with the iPhone simulator is it has access to the same resources as your mac. Your macs ram, video card etc. What I would suggest doing is opening instruments.app that comes with the iPhone SDK, and using the CoreAnimation template to have a look at how your resources are being managed. You could also look at allocations to see if its something hogging ram. CPU could also help.
tl;dr iPhone sim uses your macs ram and GFX card. Try looking at the sequence in Instruments to see if theres some lag.
I have been making my game in a pretty conventional manner. I just created a new window based application and have built off of that using my own images, table views, etc. Now I am about to begin programming the gameplay, and I just recently discovered Cocos2D. My question is this: In order to use Cocos2D for the actual gameplay (Which would take place in a single view) do I need to recreate my app from scratch? Or can I just make the one view using Cocos2D?
You could go down the mix-and-match route, but it would likely drive you insane.
If you want to embrace Cocos2D, you will likely be better off moving to it fully. More likely than not the time invested will be yield improvements in your existing code that you'll find surprising (certainly, I've found that rewriting something pretty much always yields a better solution in fewer lines of code).
You do not want to keep using the standard SDK in your game, if you're going to use Cocos2D for the game view (which you totally should).
Re-do the entire app in Cocos2D -- you'll have way more possibilities to make your game menus awesome and much less headaches; both while developing and while maintaining your game.
I am developing iphone application similar to the Talking Larry Application. I am facing an issue of Low Memory when i pre-load the animations into an NSMutable Array. If i do not pre-load the animations and load it into the Animation Images when the user touch the button then it takes Time and it play back the animation very Slow. And during video making it does not play the complete animations. How can i resolve this issue. I want to play back the animations similar to the Talking Larry app and do not want to get Low Memory Issue.
You have to “juggle” the images, freeing those that are not needed and preload those that will be needed soon. The trick is probably preloading a decent number of images beforehand, so that the animation does not slow down when started. You have to experiment to get the right numbers.
And of course, it also depends on the image resolution. I don’t know Talking Larry, but if you are trying to animate full-resolution retina images, it might be too much for the machine.
I have multiple UIView animations running in my app. They are very short, and then make callbacks to a method that then usually fires off another animation. This leads to a lot of little animations running at the same time, each firing back callbacks.
This actually performs pretty well, and for the first few levels (the app is a game), no problems are observed. However, as you continue to play deeper into the game, I'm starting to get memory warnings and ultimately crashes. I've put NSLog in all of my dealloc methods, so I can see that everything is being properly released and dealloc'd. I've also run static analysis on the app and fixed anything it found.
The weird part to me is this: Shouldn't any performance problems caused by running multiple animations be processor bound (i.e. shouldn't I see a bunch of slowdown and such)? It seems that everything performs just fine, it just runs up memory too fast and there's nothing more I can free. Is there something in the framework on the UIView side of things that will need lots of memory to do these operations? Is there perhaps a leak in the framework I need to avoid when doing these?
Additional note: I'm animating a custom class that extends UIView and has a label and a UIImageView inside of them.
Multiple animation shouldn't cause memory warnings..
I suggest you should run Instruments for Leaks, ObjectAlloc & CPU Samplers..
That would give a much better view than NSLogs in dealloc
You don't show any code so it's hard to give specific advice, however, have you considered using Core Animation layers instead of UIViews? If you need to animate text, you'll have to use a view since there is no CATextLayer on the phone, however, Core Animation provides the facilities to draw complex sprites in a 2d space making it a great candidate for many games.
Best Regards.
My app is doing some pretty but heavy weight core animations during scrolling. Sometimes it crashes due to bad performance. So I need some way to find out if there is enough capability to make the animations, and if not, I just leave them away. Best way would be if I could ask the system how busy it is.
UPDATE: I mean especially Core Animation.
By animation, do you mean frames that play after one another (like an animated GIF) or some CoreAnimation (OpenGL) effect that is moving polygons with mapped textures around?
If it's the former, I'd really consider some way of optimizing the animation or eliminating it in all cases.
If it's the latter, I'd do some deeper digging into the source of the problem. Core Animation under normal circumstances will drop frames in order to keep from getting into situations like this in the first place.
In either case case you might consider loading the texture assets a little earlier. I have had some trouble in my apps with animation methods that take a UIImage parameter when I created the UIImage in the function call. Preloading the asset a little earlier in my code took care of the problem nicely.
As an example:
BAD
[[UIImage imageNamed:#"checkmark.png"] drawAtPoint:p];
BETTER
//declared at top of class
static UIImage *checkmark = nil;
in init:
checkmark = [UIImage imageNamed:#"checkmark.png"];
in drawRect:
[checkmark drawAtPoint:p];
You would need to adapt this technique to your particular situation. In my case, checkmark is used often, and it quite small, I don't mind dedicating the memory to it permanently.
I wonder if your crashes could be fixed by making sure the assets were ready to be used by the application.
I wouldn't do that. If your app crashes, it's to heavy. You could run your app with some instruments to see where your bottlenecks are.
So, without trying to sound too harsh, your best way is to rewrite some parts in order to make you app run on an iPhone at all times.