I'm working on an app that basically revolves around 2D shapes (mostly simple polygons) being dynamically drawn and animated.
I'm looking for a way to easily time my animations. It's basically just moving a vertex to a specified point in a specified time, so just interpolating floats, with all the usual easing parameters. I come from a Flash/ActionScript 3 environment, so if you're familiar with that, think Tween Classes.
I probably could easily be doing this with Core Animation (BasicAnimation etc), but i will have up to a hundred gradient-filled shapes with varying opacity being animated dynamically,
and I need good performance (60fps would be great). So i went for OpenGL ES. Plus I'm totally for investing time into learning something that I'll be able to reuse cross-platform.
So I know OpenGL is only for graphic rendering, and I'm not going to find any 2D animation methods built in. And I heard using CA with OpenGL (if feasible) was not a good idea performance-wise.
But before I look deeper into interpolation algorithms to increment my vertex's coordinates every frame, I juste wanted to make sure I wasn't totally missing out on something much easier!?
Thanks!
I would look into the popular cocos2d library. It looks really nice; supports animation and uses OpenGL ES behind the scenes.
Related
I would like to know what kind of advantages I get from using Core Graphics instead of Open GL ES. My main question is based on this:
Creating simple View animations.
Creating some visual appealing objects (Graphics like Core Plot for instance, Animated Objects, etc).
Time consuming (both learning and implementing)
Simple 2D Games
Complex 2D Games
3D Games
Code maintenance ad also cleaner code.
Easier integration with other UI elements.
Thanks.
First, I want to clear up a little terminology here. When people talk about Core Graphics, they generally are referring to Quartz 2D drawing, which is a 2-D vector-based drawing API. It is used to draw out vector elements either to the screen or to offscreen contexts like PDFs. Core Animation is responsible for animation, layout, and some limited 3-D effects involving rectangular layers and UI elements. OpenGL ES is a lower-level API for talking with the graphics hardware on iOS devices for both 2-D and 3-D drawing.
You're asking a lot in your question, and the judgment on what's best in each scenario is subjective and completely up to the developer and their particular needs. I can, however, provide a few general tips.
In general, a recommendation you'll see in Apple's documentation and in presentations by engineers is that you're best off using the highest level of abstraction that solves your particular problem.
If you need to just draw a 2-D user interface, the first thing you should try is to implement this using Apple's provided UIKit elements. If they don't have the capability you need, make custom UIViews. If you are designing Mac-iOS cross-platform code (like in the Core Plot framework), you might drop down to using custom Core Animation CALayers. Each step down in this process requires you to write more code to handle things that the level above did for you.
You can do a surprising amount of stuff with Core Animation, with pretty good performance. This isn't just limited to 2-D animations, but can extend into some simple 3-D work as well.
OpenGL ES is underneath the drawing of everything you see on the screen for an iOS device, although this is not exposed to you. As such, it provides the least abstraction for onscreen rendering, and requires you to write the most code to get something done. However, it can be necessary in situations where you want to extract the most performance from 2-D display (say, in an action game) or to render true 3-D objects and environments.
Again, I tend to recommend that people start at the highest level of abstraction when writing an application, and only drop down when they find that they cannot do something or the performance is not within the specification they are trying to hit. Fewer lines of code makes applications easier to write, debug, and maintain.
That said, there are some nice frameworks that have developed around abstracting away OpenGL ES, such as cocos2D and Unity 3D, which might make working with OpenGL ES easier in many situations. For each case, you'll need to evaluate what makes sense for the particular needs of your application.
Basically, use OpenGL if you are making a game. Otherwise, use CoreGraphics. CoreGraphics lets you do simple things embedded in your normal UI code.
Creating simple View animations.
-> CG
Creating some visual appealing objects (Graphics like Core Plot for instance, Animated Objects, etc).
-> CG
Time consuming (both learning and implementing)
-> OpenGL and CG are both kind of tough at first.
Simple 2D Games
-> OpenGL
Complex 2D Games
-> OpenGL
3D Games
-> OpenGL
Code maintenance ad also cleaner code.
-> Irrelevant
I need to create a virtual tour tool for iOS. It's an archaeological application: the user could open it when he's inside an historic building or when he's visiting an archaeological dig. No need of doom-like subjective point of view: just a skybox. The application will have a list of points of interest (POIs). Every POI will have its own skybox.
I thought that I could use using OpenGL-ES to create a sort of textured skyboxes that could be driven/rotated by touches. Textures are hi-resolution PNG photos.
It's a funded project and I have 4 months.
Where do I have to go to learn how to develop it? Do I have to purchase a book? Which one?
I have just moderate Objectve-C and Cocoa-touch skills, since I've built just one application for the iPad. I have zero knowledge of OpenGL-ES.
Since I know OpenGL ES quite well, I had a go at a demo project, doing much of what you describe. The specific intention was to do everything in the simplest way available under OpenGL ES as long as the performance was good enough.
Starting from the OpenGL template that Apple supply, I have written one new class with a heavily commented implementation file 122 lines long that loads PNG images as textures. I've modified the sample view controller to draw a skybox as required and to respond to touches with a version of the normal iPhone inertial scrolling, which has meant writing less than 200 lines of (also commented) code.
To achieve this I needed to know:
the CoreGraphics means for getting pixel data from a PNG
how to set up the PROJECTION stack to get a perspective projection with the correct aspect ratio
how to manipulate the MODELVIEW stack to ensure two-axis rotation (first person shooter or Google StreetView style) of the scene according to member variables and to ensure that the cube geometry I defined doesn't visibly intersect the near clip plane
how to specify vertex locations and texture coordinates to OpenGL
how to specify the triangles OpenGL should construct between vertices
how to set the OpenGL texture parameters accordingly to supply only one level of detail for the texture
how to track a touch to manipulate the member variables dictating rotation, including a tiny bit of mechanics to give an inertial rotation
Of course, the normal view controller lifecycle instructions are obeyed. Textures are loaded on viewDidLoad and released on viewDidUnload, for example, to ensure that this view controller plays nicely with potential memory warnings.
The main observations are that, beyond knowing the Objective-C signalling mechanisms, most of this is C stuff. You're primarily using C arrays and references to make C function calls, both for OpenGL and CoreGraphics. So a prerequisite for coding this yourself is being happy in C, not just Objective-C.
The CoreGraphics stuff is a bit tedious but it's all just reading the docs to figure out how each type of thing relates to the next — none of it is really confusing. Just get into your head that you need a data provider for the PNG data, you can create an image from that data provider and then create a bitmap context with memory that you've allocated yourself, draw the image into the context and then release everything except the memory you allocated yourself to be left with the result. That result can be directly uploaded to OpenGL. It's relatively short boilerplate stuff, but OpenGL has no concept of PNGs and CoreGraphics has no convenient methods of pushing things into OpenGL.
I've assumed that textures are a suitable size on disk. For practical purposes, that means assuming they're a power-of-two in size along each edge. Mine are 512x512.
The OpenGL texture management stuff is easy enough; it's just reading the manual to learn about texture names, name allocation, texture parameters and uploading image data. More routine stuff that is more about knowing the right functions than managing an intuitive leap.
For supplying the geometry to OpenGL I've just written out the arrays in full. I guess you need a bit of a spatial mind to do it, but sketching out a 3d cube on paper and numbering the corners would be a big help. There are three relevant arrays:
the vertex positions
the texture coordinates that go with each vertex location
a list of indices referring to vertex positions that defines the geometry
In my code I've used 24 vertices, treating each face of the cube as a logically discrete thing (so, six faces, each with four vertices). I've defined the geometry using triangles only, for simplicity. Supplying this stuff to OpenGL is actually quite annoying when you're starting; making an error generally means your program crashes deep inside the OpenGL driver without giving you a hint as to what you did wrong. It's probably best to build up a bit at a time.
In terms of a UIView capable of hosting OpenGL content, I've more or less used the vanilla stuff Apple directly supply in the OpenGL template. The one change I made was explicitly to disable any attempted use of OpenGL ES 2.x. 1.x is more than sufficient for this task, so we gain simplicity firstly by not providing two alternative rendering paths and secondly because the ES 2.x path would be a lot more complicated. ES 2.x is the fully programmable pipeline with pixel and vertex shaders, but in ES land the fixed pipeline is completely removed. So if you want one then you have to supply your own substitutes for the normal matrix stacks, you have to write vertex and fragment shaders to do 'a triangle with a texture', etc.
The touch tracking isn't particularly complicated, more or less just requiring me to understand how the view frustum works and how touches are delivered in Cocoa Touch. Once you've done everything else, this bit should be quite easy.
Notably, the maths I had to implement was extremely simple. Just the touch tracking, really. Assuming you wanted a Google Maps-type view meant that I could rely entirely on OpenGL's built-in ability to rotate things, for example. At no point do I explicitly handle a matrix.
So, how long it would take you to write depends on your own confidence with C and with CoreGraphics, and how happy you are sometimes coding in the dark. Because I know what I'm doing, the whole thing took two or three hours.
I'll try to find somewhere to upload the project so that you can have a look at it. I think it'd be helpful to leaf through it and see how alien it looks. That'll probably give you a good idea about whether you could implement something that meets all of your needs within the time frame of your project.
I've left the view controller as having exactly one view, which is the OpenGL view. However, the normal iPhone compositing rules apply and in your project you can easily put normal controls on top. You can grab my little implementation at mediafire. StackOverflow post length limits prevent me from putting big snippets of code here, but please feel free to ask if you have any specific questions.
It's going to be pretty tough if you're learning OpenGL ES from scratch. I'd use a graphics engine to do most of the heavy lifting. I'm currently playing Ogre3d, from what I've seen so far I can recommend it: http://www.ogre3d.org/. It has Skybox (and much more) out of the box, and should be pretty straight forward to do.
I think you can do this, here are some links to help get you started:
http://sidvind.com/wiki/Skybox_tutorial
common problems:
( i would post direct links but stackoverflow wont let me )
look on stackoverflow items no 2859722 and 2297564.
some programs and tips to help make the textures:
spacescape
there are some great opengl tutorials here:
nehe.gamedev.net
they are not iphone specific, but they explain opengl pretty well. i think some folks have ported these to the phone as well, i just cant find them now.
I want to create an iPhone/iPod game. I want it to be 3d, but I want to use sprites instead of OpenGL to do this (I assume this would be easier since I don't know OpenGL).
I was thinking of simply layering sprites over top of each other and changing their size to give an illusion of 3d. It doesn't need to be too convincing since the game will be somewhat cartoony.
How can I use sprites as an alternative to OpenGL on the iPhone platform?
You can use CoreAnimation for this. Either using UIImageViews (or plain UIViews) or CALayers.
It's usually the best choice for some types of 2d games (board games, for example), since animation, rotation and scaling are really easy. Just keep in mind that if performance is your concern, OpenGL will always be better.
Depending on how much 3d, I'd recommend taking a look at cocos2d. It supports multiple layers, sprites, animations, etc, but is pretty straightforward to pick up & learn. (Much easier than OpenGL to me) The example code is very comprehensive.
http://code.google.com/p/cocos2d-iphone/
I have built a game using core animation with upto about 17 - 20 objects floating about the screen scaling and rotating and performance was fine on the iPhone (make sure you check regularly on the iPhone as the simulator doesnt simulate iPhone memory or CPU speed).
CoreAnimation is pretty simple and really powerful. Use PNG's for images and I don't think you will have to many issues. The real killer of this will be alpha's in your images, this is hard work for the iPhone. So the less transparency you have the better you app will go.
In addition to Marco's answer I want to add: Not using OpenGL may also tax the device battery a little more. As I understand it, OpenGL ES can be more efficient on a device power supply (if implemented properly). Of course, this depends on how much animation is going to be used with UIImageView, UIView or CALayers, etc.
I'm sure there is a tipping point.
I've seen a lot of bandying about what's better, Quartz or OpenGL ES for 2D gaming. Neverminding libraries like Cocos2D, I'm curious if anyone can point to resources that teach using OpenGL ES as a 2D platform. I mean, are we really stating that learning 3D programming is worth a slight speed increase...or can it be learned from a 2D perspective?
GL is likely to give you better performance, with less CPU usage, battery drain, and so on. 2D drawing with GL is just like 3D drawing with GL, you just don't change the Z coordinate.
That being said, it's easier to write 2D drawing code with Quartz, so you have to decide the trade-off.
Cribbed from a similar answer I provided here:
You probably mean Core Animation when you say Quartz. Quartz handles static 2-D drawing within views or layers. On the iPhone, all Quartz drawing for display is done to a Core Animation layer, either directly or through a layer-backed view. Each time this drawing is performed, the layer is sent to the GPU to be cached. This re-caching is an expensive operation, so attempting to animate something by redrawing it each frame using Quartz results in terrible performance.
However, if you can split your graphics into sprites whose content doesn't change frequently, you can achieve very good performance using Core Animation. Each one of those sprites would be hosted in a Core Animation CALayer or UIKit UIView, and then animated about the screen. Because the layers are cached on the GPU, basically as textures, they can be moved around very smoothly. I've been able to move 50 translucent layers simultaneously at 60 FPS (100 at 30 FPS) on the original iPhone (not 3G S).
You can even do some rudimentary 3-D layout and animation using Core Animation, as I show in this sample application. However, you are limited to working with flat, rectangular structures (the layers).
If you need to do true 3-D work, or want to squeeze the last bit of performance out of the device, you'll want to look at OpenGL ES. However, OpenGL ES is nowhere near as easy to work with as Core Animation, so my recommendation has been to try Core Animation first and switch to OpenGL ES only if you can't do what you want. I've used both in my applications, and I greatly prefer working with Core Animation.
I want to do the following:
Tap the screen and draw 3 cricles around the the tapped point.
Is it better to do this with Core Animation or OpenGL ES?
Where do I start?
My experience is this: the more complex my app became, the more I realized I should have had used OpenGL ES for what I was trying to do.
So, for your situation, If what you described is all there is, sure, Core Graphics does the trick. But, I'm guessing there's more to it than three circles.
With no experience with OpenGL at all, the learning curve for ES was about 20 days.
Thus, my advice is: OpenGL ES for pretty much every frame-to-frame graphics based app.
As mentioned, the Core Graphics framework is probably what you want. A good way to go about it would be to subclass UIView, then override the two methods drawRect: and touchesEnded:withEvent:.
When a touch event ends on the UIView, you can get the point of the last touch from the event passed to touchesEnded:withEvent:, and store it somehow in the instance of your subclassed UIView.
Then, in your implementation of drawRect:, you'll get the stored last touch point, and draw three circles around it using three calls to CGContextAddEllipseInRect, as discussed here: Quartz 2D Programming Guide: Paths (registration as Apple Developer required).
The advantage of learning OpenGL ES is that the time you put in to learn it will serve you well in the future on iPhone Apps and on other devices.
In OpenGL ES, there's no built-in way to draw a circle, so use sine and cosine to build your circles out of line segments.
Core Graphics is definitely simpler, and better for 2D. OpenGL ES is made for 3D, but can also be used for 2D. Both can be used, so if you already know one, use that. It shouldn't really matter that much.
I already knew OpenGL, so I tend to use OpenGL ES even for 2D, but if you haven't used either before, go with Core Graphics.
This could best be done with Quartz 2D (also known as Core Graphics)
See Apple's Quartz programming guide