cocos2d , openGL ES or Quartz2D

Nibbie
Posts: 4
Joined: 2011.07
Post: #1
Hello everyone

plesae excuse me if this is a trivial question but i havent found any good answer so far.

i have started learning game programing with intention to write 2D games (for start) for the Iphone. i almost completed one general iphone programming book and i want to start learning how to work with an animation library

i am having problems to decide among the 3 options above. this is the impression i got from doing some reading.

openGL - is flexible powerful and cross platform but very low level and takes long to learn

Quartz2D - is simpler but less flexible and not cross platform

cocos2d - well all i know its easy to use and i can port it to android easily.

What would you suggest ?
maybe i should start with one and slowly move to another ?

Thanks in advance
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #2
OpenGL is low level, but it's not that hard to learn really. It's very flexible and can be extremely fast.

Quartz2D is too slow to use for games as it's all software rendered. IMO it is also harder to draw sprites in than OpenGL anyway. It draws nice anti-aliased vector stuff well, other than that, don't use it.

Cocos2D has decent performance, and an easy learning curve. It's fine if you just want to draw sprites, but makes it hard to draw fancy stuff as you have to understand both OpenGL and how Cocos2D uses it. Porting to Android is only possible if you use Cocos2D-x (or whatever it's called) and write your game in C++. Probably the best thing about it is that it makes it very easy to go from having an image file to a sprite moving around on the screen.

A ton of people use Cocos2D, but I don't like it personally. I prefer the flexibility of OpenGL and just write a renderer that does what I need. If you don't go feature crazy, you don't need to write a lot of OpenGL code. The renderer for Twilight Golf (http://howlingmoonsoftware.com/twilightGolf.php ) is ~500 lines of OpenGL code including the lighting/shadowing. If I took out everything except the texture loading/sprite drawing code it would be about 200.

It depends on what you want to do with your game. If you just want easy simple sprites, Cocos2D is for you. If you want fancy effects, you might find yourself fighting it instead.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Moderator
Posts: 1,562
Joined: 2003.10
Post: #3
(Jul 18, 2011 12:21 PM)shrakrak Wrote:  openGL - ... takes long to learn

Not as much as you'd think. Using the red book, it only took me two days to learn enough of the basics to make a game with it.
Quote this message in a reply
Nibbie
Posts: 4
Joined: 2011.07
Post: #4
Hey guys

thanks for the answers

im starting to get the feeling that openGL ES is worth the effort. i still have 2 doubts.

in 2D animation most of the times you are moving sprites around. this is quite simple to do in cocos2D. is it also simple in openGL? i find it hard to believe since openGL is based on drawing primitives.

And also, cocos2D handles many stuff besides graphic, stuff like touches and other user interaction. isn't that something worth using.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #5
Sure, it's easy in OpenGL too. A sprite is just 4 vertexes and a pair of triangles from them. Here is some sprite rendering code I ripped out of one of my projects quick. I didn't take the time to comment it super well, but you should get the idea that it's not terribly hard to do.

Code:
struct vertex { GLfloat x, y, tx, ty; };
struct triangle { struct vertex v0, v1, v2; };
struct quad { struct triangle t0, t2; };

// This function will be used in packing a vertex array full of sprites for us.
// 'center' is the position to draw the sprite, 'rot' is the rotation,
// 'rect' is the location of the sprite in the texture atlas, and 'tsize' is the size of the texutre atlas.
static inline struct quad quad(cpVect center, cpVect rot, CGRect rect, CGSize tsize){
    CGSize size = rect.size;
    GLfloat tx0 = rect.origin.x/tsize.width;
    GLfloat tx1 = (rect.origin.x + size.width)/tsize.width;
    GLfloat ty0 = rect.origin.y/tsize.height;
    GLfloat ty1 = (rect.origin.y + size.height)/tsize.height;
    
    GLfloat hw = size.width*0.5f, hh = size.height*0.5f;
    cpVect v1 = cpvrotate(cpv(-hw, -hh), rot);
    cpVect v2 = cpvrotate(cpv( hw, -hh), rot);
    
    struct vertex a = {center.x + v1.x, center.y + v1.y, tx0, ty0};
    struct vertex b = {center.x + v2.x, center.y + v2.y, tx1, ty0};
    struct vertex c = {center.x - v1.x, center.y - v1.y, tx1, ty1};
    struct vertex d = {center.x - v2.x, center.y - v2.y, tx0, ty1};
    
    return (struct quad){{a, b, c}, {a, c, d}};
}

-(void) draw;
{
    // This is the array we will dump the OpenGL geometry data.
    const int maxQuads = 16;
    struct quad quads[maxQuads];
    int count = 0;
    
    CGSize tsize = CGSizeMake(textureAtlas.pixelsWide, textureAtlas.pixelsHigh);
    CGRect rect = CGRectMake(6*32, 2*32, 32, 32);
    
    // Call these lines a few times to add sprites to the list...
    assert(count<maxQuads);
    quads[count] = quad(position, rotation, rect, tsize);
    count++;
    
    // Set up some OpenGL state
    glBindTexture(GL_TEXTURE_2D, textureAtlas);
    glVertexPointer(2, GL_FLOAT, sizeof(struct vertex), &quads[0].t0.v0.x);
    glTexCoordPointer(2, GL_FLOAT, sizeof(struct vertex), &quads[0].t0.v0.tx);
    
    // Draw them all in one pass.
    glDrawArrays(GL_TRIANGLES, 0, 6*MIN(maxQuads, count));
}

As for Cocos2D's input handling. It's exactly like the normal iOS stuff, it basically just forwards the method calls to the Cocos2D objects. In fact, because it does this, it makes it harder to do advanced input processing because you can't easily use Apple's gesture recognizer APIs. Though games mostly don't need that sort of input.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Nibbie
Posts: 4
Joined: 2011.07
Post: #6
hey skorche

thanks for the answer and sharing your code

i might start with cocos2D after all just to simplify stuff for me, but im sure i will move on to openGL ES. I guess the two can also be mixed since cocos2D is based on openGL and is open source
Quote this message in a reply
Nibbie
Posts: 2
Joined: 2012.01
Post: #7
I just finished my first iOS game and used both cocos2d and openGL.

I used cocos2D for scene management and texture loading and wrote the rest of the openGL myself.

For our next game, I'll probably ditch cocos2D altogether now that GLKit has a texture loader.
Quote this message in a reply
Post Reply