What is the easiest and most practical way to implement smooth frame-based animation on the iPhone? I know that image sequences are easy to do, but if I have say 30 images flashing per second (30 fps) for 5 seconds, will it freeze up? Are there massive memory implications with this method?
I'm designing a game that will be mostly static, but there will be animations for some of the user actions. I'm hoping that OpenGL (etc.) won't be necessary.
I'd recommend looking at the Cocos2d-iPhone open source game engine.
Using an AtlasSprite it should be relatively straight forward to achieve the result you want.
This question needs to be more clear. Are you trying to display a sprite based animation? Or animate an image along a path? Or both?
If you have a series of images to animate, using UIImageView's animationImage is an easy way to go about it, although it is probably not efficient enough for a full scale game.
Related
Im just wondering what would the best way to display multiple instances of a small (10x1) image. I have an array of about 480 points and I would like to draw the image at each of these points to draw path. Would it be faster to use Core Graphics or should I be using something like cocos2d?
It depends on whether you need it to animate. Core Graphics is probably fine if you are drawing it once and then displaying it as an image, but it it will be really slow if you need to redraw it each frame.
UIKit is actually much quicker because UIView drawing is hardware accelerated, so you could just add a UIImageView for each point in the graph, but from my own experiments that will probably be too slow for realtime interaction if there is more than about 200 image views (at least if you want it to run on anything older than an iPhone 4S).
If you do need realtime performance, that really only leaves OpenGL, which is quite fiddly to set up unless you use a library like Cocos2D or Sparrow to simplify it. I'd suggest Sparrow for your purposes because Sparrow views can be used in a regular UIKit application, whereas Cocos2D provides a whole app framework and is harder to use for just a single view in an otherwise regular UIKit app.
http://www.sparrow-framework.org/
Without more context, another option is to use OpenGL and create a display list for the composite image.
I am trying to implement the style of 3D rotational animation you see in the Elements and the Wired iPad applications. The animation has the UIScrollView style acceleration so it looks like they have connected a UIScrollView to a sequence of images.
I have tried implementing it in UIKit, using an "empty" UIScrollView to increment through an array of images and set the contents of a UIImageView, based on the content offset. This works but even with scaled down images on the simulator, it is very sluggish. I am not sure how I could optimise it to make it run faster.
Source Code on GitHub
I have also tried doing something similar in Cocos2D. Cocos could animate the sequence very smoothly but I couldn't control the animation. I tried using a scroll view and setDisplayFrame to step through an animation but it didn't work.
Any help or suggestions on either option would be greatly appreciated.
I'm not 100% sure I understand the effect you're trying to achieve, but if you're referring to the images in "The Elements" app which you can spin around, then yeah, you probably don't want to be doing that with an UIScrollView.
You can control the animation of content in Cocos2d. While you can set an animation to "just run", you can also manually set frames directly out of an animation, so if you can get smooth animation out of Cocos, you should be able to do it interactively. Look at the atlas sprite object - you can set the rect of an animation frame directly.
However, again, I'm not sure this is the best approach, either, since that's a lot of frames for a texture. If you're going to be doing a lot of 3D photographic objects, you might consider looking into the video codecs and scrubbing along a video instead of trying to pack all the frames of a rotation animation into a series of textures.
Just so you know, the guy who made "The Elements" wrote an article about the development of the app, and here's what he had to say about the 3D rotatable objects:
"Creating fluidly spinning objects with the level of crystal clear photographic quality I demanded is actually harder than it might seem. A number of the obvious things the more technical of you might think of turn out not to work for reasons too complicated to get into here. Suffice to say that John designed a brilliant solution that uses the iPad's excellent graphics subsystem to lend a hand in ways it's not normally intended to."
I don't know how exactly they achieved the 3D objects, but perhaps that "uses the iPad's excellent graphics subsystem" mention gives you a clue where to head from here...
I'm creating an interactive e-book for the iPad. This book will contain multiple pages that will consist of a lot of animations (frame and motion animations), transitions,... I was wondering what my development options are, should I use OpenGL, Quartz,...?
I've use UIImageView.animationImages before and found that it had really bad performance. What's the best way to draw frame based animations?
Does anybody have some good pointers to resources on this?
thanks in advance,
Thomas
I guess that depends a bit on what you'll be drawing. If you have a need for 3D, then OpenGL is the way to go, but it doesn't sound like it. I have a feeling Quartz2D is going to be just fine for your 2D drawing needs. I've done drawing with both and they have a very similar API. I think the downside of using all the raw power of OpenGL is that you have then signed up for doing most of the work yourself. I don't recommend attempting to using Core Animation high level APIs to manipulate OpenGL views.
If you do use Quartz2D and "normal" UIViews instead of OpenGL/EAGLView, then you can take advantage the many pre-canned animations Apple already build with Core Animation. This include the card flip left/right, resizing, moving (x/y translation), rotation and the ever popular e-book page curl.
The best example of iBook like custom page curl functionality I could find is this example code from High Caffeine Content. However, you don't have to bring that much math to the table if you just want to use the out of the box Core Animation stuff. The bad performance you may have encountered could have been due to anything, including older/slower hardware. They have revved the graphics chips on the new devices.
I'm developing a 2D game for the iPhone using OpenGL ES and I'd like to use a 320x480 bitmapped image as a persistent background.
My first thought was to create a 320x480 quad and then map a texture onto it that represents the background. So... I created a 512x512 texture with a 320x480 image on it. Then I mapped that to the 320x480 quad.
I draw this background every frame and then draw animated sprites on top of it. This works fine except that the drawing of all of these objects (background + sprites) is too slow.
I did some testing and discovered that my slowdown is in the pixel pipeline. Not surprisingly, the large background image is the main culprit. To prove this, I removed the background draw and everything else rendered very fast.
I am looking for advice on how to keep my background and also improve performance.
Here's some more info:
1) I am currently testing on the Simulator (still waiting on Apple for the license)
2) The background is a PVR texture squeezed down to 128k
3) I had hoped that there might be a way to cache this background into a color buffer but haven't had any luck with that. that may be due to my inexperience with OpenGL ES or it just might be a stupid idea that won't work :)
4) I realize that the entire background does not always have to refresh, just the parts that have been drawn over by the moving sprites. I started to look into techniques for refreshing (as necessary) parts of the the background either as separate textures or with a scissor box, however this seems less than elegant.
Any tips/advice would be greatly appreciated...
Thank you.
Do not do performance testing on the simulator. Ever!
The differences to the real hardware are huge. In both directions.
If you draw the background every frame:
Do not clear the framebuffer. The background will overdraw the whole thing anyway.
Do you really need a background texture ?
What about using a color gradient via vertex colors ?
Try using the 2bit mode for the texture.
Turn of all render steps that you do not need for the background.
E.g.: Lighting, Blending, Depth-Test, ...
If you could post some of your drawing code it would be a lot easier to help you.
If you're making a 2D game, is there any reason you aren't using an existing library? Specifically, the cocos2d for iPhone may be worth your time. I can't answer your question about how to fix the issue doing it all yourself, but I can say that I've done exactly what you're talking about (having one full screen background with sprites on top) with cocos2d and it works great. (Assuming 60 fps is fast enough for you.) You may have your reasons for doing it yourself, but if you can, I would highly suggest at least doing a quick prototype with cocos2d and seeing if that doesn't help you along. (Details and source for the iPhone version are here: http://code.google.com/p/cocos2d-iphone/)
Thanks to everyone who provided info on this. All of the advice helped out in one way or another.
However, I wanted to make it clear that the main issue here turned out to be the behavior of simulator itself (as implied by Andreas in his response). Once I was able to get the application on the device, it performed much, much better. I mention this because, prior to developing my game, I had seen a lot of posts that indicated that the device was much slower than the simulator. This might be true in some instances (e.g. general application logic) but in my experience, animation (particularly 3d transformations) are much faster on the device.
I dont have much experience with OpenGL ES, but this problem occurs generally.
Your idea about the 'color buffer' is good intuition, essentially you want to be storing your background as a frame buffer and loading it directly onto your rendering buffer before drawing the foreground.
In OpenGL this is fairly straight forward with Frame Buffer Objects (FBO's). Unfortunatly I dont think OpenGL ES supports them, but it might give you somewhere to start looking.
you may want to try using VBOs (Vertex Buffer Objects) and see if that speeds up things. Tutorial is here
In addition, I just saw, that since OpenGL ES v1.1, there is a function called glDrawTex (Draw Texture) that is designed for
fast rendering of background paintings, bitmapped font glyphs, and 2D framing elements in games
You could use frame buffer objects similar to the GLPaint example from Apple.
Use a texture atlas to minimize the number of draw calls you make. You can use glTexCoordPointer for setting your texture coordinates that maps each image to its correct position. Remember to set your vertex buffer too. Ideally one draw call will render your entire 2D scene.
Avoid enabling/disabling states where possible.
I'm working on a game where I need to let the player look at a plane (e.g., a wall) through a lens (e.g., a magnifying glass). The game is to run on the iPhone, so my choices are Core Animation or OpenGL ES.
My first idea (that I have not yet tried) is to do this using Core Animation.
Create the wall and objects on it using CALayers.
Use CALayer's renderInContext: method to create an image of the wall as a background layer.
Crop the image to the lens shape, scale it up, then draw it over the background.
Draw the lens frame and "shiny glass" layer on top of all that.
Notes:
I am a lot more familiar with Core Animation than OpenGL, so maybe there is a much better way to do this with OpenGL. (Please tell me!)
If I am using CALayers that are not attached to a view, do I have to manage all animations myself? Or is there a straightforward way to run them manually?
3D perspective is not important; I'm just magnifying a flat wall.
I'm concerned that doing all of the above will be too slow for smooth animation.
Before I commit a lot of code to writing this, my question is do you see any pitfalls in the plan above or can you recommend an easier way to do this?
I have implemented a magnifying glass on the iPhone using a UIView. CA was way too slow.
You can draw a CGImage into a UIView using it's drawRect method. Here's the steps in my drawRect:
get the current context
create a path for clipping the view (circle)
scale the current transformation matrix (CTM)
move the current transformation matrix
draw the CGimage
You can have the CGImage prerendered, then it's in the graphics memory.
If you want something dynamic, draw it from scratch instead of drawing a CGImage.
Very fast, looks great.
That is how I'd do it, it sounds like a good plan.
Whether you choose OGL or CA the basic principle is the same so I would stick with what you're more comfortable with.
Identify the region you wish to magnify
Render this region to a separate surface
Render any border/overlay onto of the surface
Render your surface enlarged onto the main scene, clipping appropriately.
In terms of performance you will have to try it and see (just make sure you test on actual hardware, because the simulator is far faster than the hardware). If it IS to slow then you can look at doing steps 2/3 less frequently, e.g every 2-3 frames. This will give some magnification lag but it may be perfectly acceptable.
I suspect that performance between OGL / CA will be roughly equivalent. CA is built ontop of the OGL libraries but your cost is going to be doing the actual rendering, not the time spent in the layers.