I have a game with a number of animated "monsters". The animation is made with ~20 png images for each monster. So I use UIImageView with setted animationImages:.
The problem is that sometimes there can be a lot of monsters on the screen (up to 110 in total and up to 10 different). So when all of them are on the screen at the same time - I see animation problems (very low fps).
Please, can you give me some advice - how can I solve this problem?
You can use CoreAnimation as described in this tutorial. It explains pretty well all the techniques you can use to increase the performance from where you are now (first of all it doesn't use UIViews and the standard animationImages, second it makes use of sprites (also called texture atlases) which will not only increase performance but also will make your life a lot more easier when it comes to managing the image resources).
Also you can use CADisplayLink to create a game loop in which you can make all the updates. There are several questions/answers here on SO that describe just that.
Related
I want to make a pool game where the user can pinch the pool table to zoom so he can
precisely shoot the pocket.
So, this means I need a large pool table graphic.
What is the best way to handle such a situation in cocos2d?
How do I load the graphic? What is the limitation on graphic size?
I have a lot of doubts because Im not sure which path to take.
Regards
Mirza
For something as simple as a pool table it might be better to render it all using vector graphics. This means you will need less graphics (perhaps only a few for textures) and you get infinite zooming without all the graphic image overhead.
How to correctly implement the blocks in the drawing view, so that when they could cut the line in two parts. Using UIImageView or UIImage?
After the cut blocks should fall under the influence of physics.
First, how many cuts could happen in total? How many independent pieces of block could result? 10? 100? Before implementing any of these, test moving that number of objects around on an iPhone or iPod touch. Just because it works on the simulator does not mean it will be fast enough on the actual device.
Second, as already noted, there are libraries for game graphics and physics that may do a lot of the work for you. Cocos2D appears to be a popular option, combining OpenGL drawing with relatively easy access to physics libraries.
Anyway, to do your own drawing, here are the choices:
Move all the graphics into OpenGL. This should not be undertaken lightly - you lose a lot of the ease of working in Cocoa Touch. You also have maximum control over your graphics and animation, and can achieve the smoothest performance if you take the time to optimise it.
Have a single UIView, adding CALayer sublayers to its main layer for every independent block. CALayers are designed for rapid moving and compositing. However, if you're running a physics simulation, your first step will be to remove their animation behavior. This tutorial series may be useful.
Have a separate UIView for each block. This will have similar performance to using CALayers, as UIViews are actually drawn with CALayer. This option will use up more memory, (you have at least as many layers and more views than before), but you have all of the power of CALayers plus a few drawing options that are easier on views.
Have a single UIView, and draw every block during its drawRect method. This may look easy to implement, but it will almost certainly be too slow.
If at all possible, test each of these. Before you continue with the cutting and physics parts, how many blocks can you animate across the screen before it slows down too far? Can you make a game with that Remember that your physics system will slow the game down when it does work.
I'm trying to build a weather application on the iPad but it seems that I need some help in animation. Say I'm animating a Radar, so the radar source files have 10 gif/jpeg pictures in 900x700 pixel size. I've tried the UIImage animation technique using the tutorial here:
http://www.icodeblog.com/2009/07/24/iphone-programming-tutorial-animating-a-game-sprite/
but it seems that loading 10 images that big is too much for the iPad to handle and its crashing due to memory warnings. I'm researching other techniques to animate but I can't seem to find something that will do this efficiently.
I've looked at others like Core Animation using sprites, and Cocos2D with sprites. Can someone point in the right direction the best way to animate these big images? (keep in mind that these images are dynamic and changes often so the sprites will have to be recreated on a server and fetched from the iPad to do the animation). Thanks
OpenGL only creates textures with dimensions at powers of 2. In the case of your images, that's 1024x1024, which is a meg of memory per image. Still, that shouldn't be a problem with the iPad.
First, investigate using Xcode's profiling tools to ensure the images aren't being repeatedly loaded into memory at each loop of the animation (likely by way of new objects that aren't sharing cached textures). That could solve your problem from the start.
Second, I recommend using Cocos2D if only for the easy handling of textures and caching. Toss the images into a CCAnimation, pop that into a CCRepeatForever, run it with a CCSequence. When you're done hit CCTextureCache to release unused textures.
Third, lower your animation framerate to 30 or less (if only for this animation). It may be the iPad, but you making a weather app. Not a video game.
Finally, downgrade the size of your image. Justify all you want, but a large radar animation will not sell your app. And just because a website might already be playing that animation beautifully, remember that a desktop has vastly more memory and power than any smart phone.
Try breaking the animation image into into smaller parts and animate those instead by treating each components as sprites. It would be best if you use primarily code (CoreGraphics) and draw your radar "by hand" instead of just using images as if they were animated GIFs.
What I am trying to do is to have many small rectangles on the screen (up to several thousand) which move randomly.
I have the mechanics behind this figured out (in terms of determining the coordinates for the movement), but I can't figure out the best way to draw the shapes or model their movement.
A couple strategies I have tried have been, first, to subclass NSView (this is on the Mac) and create thousands of these. I then change their drawRect: function in order to draw a square inside of themselves. Then it is pretty simple to just change their locations to move them around. However, with several thousand allocated instances of these, performance is obviously terrible.
I tried a less object-oriented route also, just using NSRectFill to draw the thousands of rectangles. However, I had trouble implementing the movement I needed with this, though it was blazing fast.
Does anyone have any suggestions on how I could successfully create this animation?
Layers and Core Animation are the best approach for the platform.
Several thousand rectangles may be too much for CoreAnimation. You should consider using OpenGL.
I have a game that's moving fewer than 10 small animated UIImageViews at once, maximum. I'm driving their animation with a CADisplay timer running at 60fps. Here is an example of how I move the views in my update method:
// for each insect in insectArray
insectView.center = insect.hitCenter // I pull a position from my model object
The graphics are 32 x 32 pixels with up to 5 animation frames each, if that helps. They have an alpha channel for transparency. I've profiled and eliminated any in-game calculations as a bottleneck. I've also made the opacity property = YES, for a very small speedup. Having the animated frames playing or not makes no difference.
The frame rates are mostly great, except on older devices like the iPhone 1G and 3G. There I get intermittent stuttering.
Before switching to OpenGL, is there any way to get a bit more performance?
I experienced the same kind of bottleneck with CoreAnimation; it is very limited in terms of system complexity that you can display with decent performance. From what I have read and discussed with others, there is no silver bullet for you (or me) there, sorry!
My usage was actually quite close to yours (no animated frames, though), and using OpenGL ES made it go from painfully sluggish to perfectly snappy, so there's hope for you!
CoreAnimation isn't designed for frame-by-frame animation, you tell it a few keyframes and times, and it will do the rest for you. Why not switch to OpenGL? You can't support the old devices forever...
I agree with FX that there is no silver bullet, but if you provided a little more code, we could make some specific suggestions. Here are a few general ones:
Don't round corners using -setCornerRadius on the UIImageView's layer. You'd never believe how much this can degrade performance
If you're using drop shadows behind your view, make sure you specify a shadow path on the layer as well.
Try turning -shouldRasterize on on the UIImageView layer: [[insectView layer] setShouldRasterize:YES];
Hate to say it, but after this, as others have said, OpenGL is the only other choice.