I'm planning on developing a 2D game.It's a traffic control game with many different entities -lanes with variety of complexities, pedestrians,bike riders,cars with different privileges and off course traffic lights, etc. Although it's going to be 2D I want it to be as smooth as possible. The objects will mostly not be as realistic - a pedestrian, for example, will more like a cartoon personage than a real man- but the flow of the game should be natural. I'm having a little difficulty in making a decision as to whether to use Quartz or OpenGL. I read lots of threads in SO but I still need some more guidance. Thank you a lot.
For the performance view, OpenGL will be the best. Cocos2d a link is a very good framework, you can put images on canvas with very good performance.
I haven't use GLKit (from iOS5), but you can put OpenGL view in the UIKit, that will be good if you still would like to draw using core graphics, you can layer the UIKit and OpenGL.
I personally recommends Kobold2d: http://www.kobold2d.com/display/KKSITE/Home because it comes with many sample projects, you can start changing from.
Related
I have just delved into the world of Metal, and I thought that I'd got the hang of it! But then it occurred to me that if I wanted to make a game, then static objects moving around a screen wouldn't suffice. So my question is, 'Is it possible to create animations for models with Metal?'
I have looked at using other APIs, such as SpriteKit, and SceneKit, but I found that they do not support shaders, and are not as powerful as Metal.
The only way that I can think about how I would go about this, is by creating 60 different models, and then loading each one one after the other, to give a 'stop-motion' kind of effect, but I think that this would probably be incredibly inefficient, and was hoping that there was an easier answer?
Thanks a lot!
Yes, there are other, more efficient ways to do animation. But before getting into that, a warning: it really looks like you're barking up the wrong tree here.
Metal is a (conceptually) very low-level interface. You use Metal to talk (almost) directly to the GPU, so to work with it you need to think (sort of) like a GPU: in terms of data buffers, vertex transformations, etc. You seem to be working at a much higher conceptual level, so you're probably better served by one of the high-level game engines: SpriteKit for 2D or SceneKit for 3D. (Or a third party engine like Cocos or Unity.) Metal, on the other hand, is better suited for building those game engines.
SpriteKit and SceneKit do support shaders. Look at SKShader and SCNShadable in the docs (and be sure to click the "More" links to read the full overviews). SceneKit also supports character animations (aka skeletal animation aka skinning): typically one designs and rigs a model for animation in an external authoring tool (Maya, Blender, etc), then uses SceneKit to work with the animations at run time.
It is possible to do things like GPU-based skeletal animation in Metal. But I haven't seen any tutorials or similar written about it yet, probably because Metal is such a new technology. Fundamentally, though, it'd be based on the same sorts of techniques you'd use for skeletal animation in OpenGL or Direct3D — and much has been written about animation for those technologies. If you're willing to invest the time and energy to work at a low level, adapting the subject matter from GL/D3D tutorials is relatively easy.
You can do skeletal animation in Metal, SCNKit would be using the GPU to deform the mesh as well. But to do it in Metal you would need to pass skin weights, along with bone matrices for the bind pose and the transformations of the bones as they animate then calculate the new vertex positions based on these. In fact I think you need the inverse of the bind pose matrices. Each mesh vertex is then transformed by a weighted sum of transformations dictated by the skin weights.
I tried it but screwed it up somehow it didn’t deform properly, I don’t know if I’d obtained the wrong matrices from my custom script to grab animation data from blender or a bug in my shader maths or from the weights.
It was probably close, but with all the possible things that I may have got wrong in the process it was difficult to fix so I abandoned it in the end.
Probably easier to stick with SceneKit and let apple take care of the rest or use an existing game engine such as Unity.
Then again if you want a challenge, I’m sure it’s possible, just a little tricky. You could try CPU first to make sure the maths is ok then port it to the GPU to make it faster?
SceneKit do support shaders. And an object that manages the relationship between skeletal animations and the nodes and geometries they animate is SCNSkinner from SceneKit.
Typically, you need to create a skinned model using, for example, Autodesk Maya, save it along with animations that use the skeleton, in a scene file. You load the model from the scene file and pose or animate it in your app, either by using animation objects also loaded from the scene file or by directly manipulating the nodes in the skeleton. That's it.
Watch this 7-parts video about Blender's skeletal system and how to use it in SceneKit.
convenience init(baseGeometry: SCNGeometry?, //character
bones: [SCNNode], //array of bones
boneInverseBindTransforms: [NSValue]?, //ibt of matrix4
boneWeights: SCNGeometrySource, //influence on geometry
boneIndices: SCNGeometrySource //index mapping
)
Are these classes supported in Stage3D? Or are there equivalents or similar classes that exist?
flash.display.BitmapData;
flash.display.GraphicsSolidFill;
flash.display.GraphicsStroke;
flash.display.GraphicsPath;
flash.display.IGraphicsData;
flash.display.Shape;
flash.filters.BlurFilter;
flash.geom.ColorTransform;
Stage3D is an entirely different, fairly low-level beast. Those classes you list there are all related to the traditional Flash DisplayList, which is a CPU-driven rendering engine, so no, they don't exist, per se. But there's much more to it than that:
If you're using the raw Stage3D APIs (example tutorial here), then it feels very much like OpenGL programming. You're loading Vertex buffers, Index buffers, and textures into the GPU, and defining Vertex and fragment shader programs in an assembly language called AGAL. All this gets you a cross-platform, hardware accelerated application that's probably very fast, but it's very different than the traditional Flash DisplayList. Can you get gradients, filters and vector shapes - sure, but probably with custom shaders and such, not using those classes.
In some applications, it makes sense to use the traditional DisplayList for interactive UI controls on top of the Stage3D hardware accelerated backdrop. The DisplayList sits on top of the Stage3D plane, so this is entirely possible.
However, if such low-level 3D programming is not what you're interested in, you can choose to build on top of a framework. There are many Stage3D frameworks - some are intended for creating 3D applications, others are intended for 2D (but using the underlying 3D acceleration for speed). Adobe has a list of these frameworks here.
For example, Starling is a Stage3D framework that's intended to mimic the traditional Flash DisplayList, so it'll get you close to some of the classes you've mentioned above - check out their demo and API docs for specifics.
Another technique that Flash enables is blitting, which generates Bitmaps for 3D acceleration on the fly. You can draw into Bitmaps (aka blit) any Flash DisplayObjects you like (Shapes, drawn gradients, with filters, whatever), then push those Bitmaps into the 3D acceleration framework. You can blit individual objects separately, or blit the entire stage into one full-screen texture using this technique. But you have to be careful how often and how much you upload new textures into the GPU, because this can affect performance significantly. In fact, a significant performance consideration in GPU programming is the ability to batch several bitmaps into a single texture.
So there are many facets to consider when thinking about transitioning from the traditional DisplayList to Stage3D. Hope this helps. :)
I'm trying to implement a painting app with brush texture and blending, similar to that of an oil painting. I'm finding that even though Quartz 2D has been relatively simple to pick up, I've found it hard to implement the ideas of stroke texture/blending. Naively I tried hacking the shadow, and it looks "okay," but the performance sucks. I have a feeling that if I try to use a bitmap image for drawing I will have similar performance issues, but I do not know that to be the case. Meanwhile, the only alternative I see around is OpenGL, which feels like overkill and also is pretty intimidating. I've looked at GLPaint and I can't claim to understand some parts of it. Further working against me is that my knowledge of C is extremely limited and it really feels like if I understood C better I might understand OpenGL ES for iOS better as well.
Basically, I am wondering: given my requirement of producing an "oil painting" type effect for iOS painting, am I relegated to either the poor performance of Quartz 2D or learning the gigantic and honestly scary OpenGL framework? Are there any frameworks that "wrap" OpenGL functionality for mere mortals like myself?
Or, is there some other way of achieving stroke texture and blending that I am not aware of in Quartz?
iOS 5's GLKit will wrap a lot of OpenGL functionality for you, but it's going to be difficult to find an "oil painting library" because it is quite specific. If you want to work with graphics, sooner or later you are going to have to deal with OpenGL I imagine. It seems intimidating, but if you read a good book on it you will start to understand it better.
However, make sure you exhaust your possibilties on Quartz first. Perhaps you can find the function that is taking the most time and ask another question about how to improve its efficiency.
To answer the main question though, "yes".
However it focuses mainly on game development, there is a popular framework called cocos2d that wraps around OpenGL and provides simple APIs for 2D gfx development. If you decide to go on with OpenGL ES, I found this tutorial excellent and very comprehensible, even if it is focusing on 3D.
I understand that cocos2d it's really simple API, and that I can use it to do simple and huge 2D or even sometimes 3D games/applications. As well I understand that OpenGL it's more complicated, it's lower level API etc.
Question: What is better for implementing 2D/3D games? Why do we need to learn OpenGL if we have simple frameworks like cocos2d? What you can do with OpenGL that you can't do with cocos2d?
Thanks in advance!
What is better for implementing 2D/3D games?
Hard to tell, but a higher level API is always there to make things easier for you. For example you are writing a 2D shootem up. You will likely use a game loop, you will want to use sprites and make those move on the screen. You may want animations like explosions taking place. You'll end up writing your own higher level API to do those things. Cocos2D has solved those problems for you already. Any other frameworld should have solved it.
Why do we need to learn OpenGL if we have simple frameworks like cocos2d?
In case you like to cusomize the standard behaviour of a framework, especially the drawing part, you should get into openGL. If there is something you like to have which doesn't come out of the box you may find yourself reimplementing a base framework class. For example, look at the shaders used in Cocos2D 2.0. If you like some special blending mode, like a tinting effect, you won't get it for free. There is a colour attribute for a CCSprite but this may not be the result you're expecting. So you'll have to write your own shader and plug it into the sprite you like to be displayed in a different way.
What you can do with OpenGL that you can't do with cocos2d?
This comparison doesn't really work out, since cocos2d facilitates opengGL for the drawing part to build up that higher level api and make your life easier as a game developer.
Cocos2d is a wrapper around the 2D features of OpenGL (as of this: http://www.cocos2d-iphone.org/about) . Under the hood it itself uses OpenGL ES to implement its features. This is good because it means that there will be minimal performance overhead so you can start using its simpler API without having to get immersed to the definitely bigger learning path of OpenGL.
It has however only strong 2D support and if you plan to write later 3d games you loose all benefits of Cocos2d: why would you rewrite a 3d rendering engine with a 2d framework that under the hood uses a very strong 3d engine? You loose performance for a lot of unnecessary work.
So the simpler answer is: for 2d Cocos2d, for 3d OpenGL.
If you want to start OpenGL ES, this is a very good tutorial for beginners: http://iphonedevelopment.blogspot.it/2009/05/opengl-es-from-ground-up-table-of.html
I have several fundamental questions to clearify to myself, hope you'll help...
I'm developing a game application. It has game loop and on each iteration i draw about 200 sprites. What is the fastest way of drawing bitmap? Currently I use [UIImage drawAtPoint] method to draw a sprite (sprite sizes can be 16x16 ... 64x64), but something tells me, this is not the best approach. As I understand, UIImage is based on Quartz technology? Can cocos2d provide the better performance?
I also thought about using OpenGL ES to reproduce drawing mechanism via textured objects.
If you're making a game you'll probably want to avoid Quartz/UIKit/CoreAnimation. They're designed to be simple and easy to use, at the cost of performance.
Opengl is the fastest way to draw sprites to the screen on the iPhone. There are two versions of Opengl in iOS: OpenglES 1.1 and OpenglES 2.0. If you're looking to support the iphone 3G and earlier, you'll need to either use 1.1 exclusively, or be able to determine the device you're running on and switch versions on the fly. Opengl is very fast but at the cost of a fairly steep learning curve and a lot of what you'd see as boilerplate code.
Cocos2d is an iOS game engine built on top of Opengl. It's designed to make using opengl easier (among many other things). If you're making a game, I'd suggest you use cocos2d as they've done a lot of the hard work already. If you don't you'll be spending 99% of your time getting opengl to work, rather than focusing on the game.
Good luck! :)