Is this the right tool for vertex arrays / 2D?

[Elphaba]

Is this the right tool for vertex arrays / 2D?

Hi

I'm just about to start iPhone game development, and I want to build a 2D space shooter.

Because of the iPhone SDK and OpenGL ES implementation, all the graphics need to be stored as VERTEX ARRAYS.

I was told that Cheetah, can create these arrays WITH texture mapping / normals too, and export these straight into code (.h) files.

Is this correct?
And more importantly, can I still do by 2D ships / asteroids / alien ships etc... with Cheetah even though I ONLY need to work in 2D?

If this isn't the right app for me, can anyone please suggest one that might be?

Regards

Elphaba

 

[AnotherJake]

Because of the iPhone SDK and OpenGL ES implementation, all the graphics need to be stored as VERTEX ARRAYS.

While it's true that you will be submitting geometry via glDrawArrays or glDrawElements on iPhone, for 2D graphics you only need to submit four vertices at a time for texture mapping onto a quad, which requires geometry which is easily done by hand with something like:

GLushort	genericTexCoords[] = {  0,	0,
									1,	0,
									0,	1,
									1,	1 };
GLfloat		genericVerts[] = {	-0.5f,	-0.5f,
								 0.5f,	-0.5f,
								-0.5f,	 0.5f,
								 0.5f,	 0.5f };

Cheetah3D is helpful for more elaborate 3D geometry, but I guess you can also use it for simple stuff like a quad if so desired. The Cheetah3D output for a quad in a .h is as follows:

// Headerfile *.h (generated by Cheetah3D)
//
// There are the following name conventions:
// 	NAME			=name of the object in Cheetah3D. Caution!! Avoid giving two objects the same name
// 	NAME_vertex		=float array which contains the vertex,normal and uvcoord data 
// 	NAME_index		=int array which contains the polygon index data
// 	NAME_vertexcount	=number of vertices
// 	NAME_polygoncount	=number of triangles
//
// The vertex data is saved in the following format:
// 	u0,v0,normalx0,normaly0,normalz0,x0,y0,z0
// 	u1,v1,normalx1,normaly1,normalz1,x1,y1,z1
// 	u2,v2,normalx2,normaly2,normalz2,x2,y2,z2
// 	...
// You can draw the mesh the following way:
// 	glEnableClientState(GL_INDEX_ARRAY);
// 	glEnableClientState(GL_NORMAL_ARRAY);
// 	glEnableClientState(GL_VERTEX_ARRAY);
// 	glEnableClientState(GL_TEXTURE_COORD_ARRAY);
// 	glInterleavedArrays(GL_T2F_N3F_V3F,0,NAME_vertex);
// 	glDrawElements(GL_TRIANGLES,NAME_polygoncount*3,GL_UNSIGNED_INT,NAME_index);
//

#define Plane_vertexcount 	4
#define Plane_polygoncount 	2


float Plane_vertex[Plane_vertexcount][8]={
		{0.00000, 0.00000, 0.00000, 1.00000, 0.00000, -0.50000, 0.00000, -0.50000},
		{1.00000, 0.00000, 0.00000, 1.00000, 0.00000, 0.50000, 0.00000, -0.50000},
		{1.00000, 1.00000, 0.00000, 1.00000, 0.00000, 0.50000, 0.00000, 0.50000},
		{0.00000, 1.00000, 0.00000, 1.00000, 0.00000, -0.50000, 0.00000, 0.50000},
		};


int Plane_index[Plane_polygoncount][3]={
		{0, 1, 2},
		{2, 3, 0},
		};

BTW, this "tutorial" section probably wasn't the right place to submit this question

 

[Elphaba]

Wow, thank you for the very thorough response.

As I understand the iPhone SDK, OpenGL ES 1.1 doesn't support Quads. So I have to use triangles. Which means I'll have duplicate vertices defined unless they are 'described efficiently'.

As such, I thought that maybe using Cheetah would make that easier than trying to do it in my head or coping off graph paper.

What do you think?

Thanks again.

Elphaba

 

[AnotherJake]

Correct, there is no "quad" primitive in OpenGL ES, so just submit it as a triangle strip, using coordinates similar to the ones I gave at the top. It is standard practice on iPhone to do it this way for 2D sprites, and it is as efficient as it gets for single sprite submissions. BTW, we generally refer to anything with square geometry as a quad, even though it may be made up of other primitives, such as triangles or triangle strips or even triangle fans.

Notice in my example (not the Cheetah3D header) that there are four coordinates, which match the triangle strip submission pattern: lower left, lower right, upper left, upper right. The texCoords match that layout. If you use CoreGraphics to load your texture, which is perfectly sensible, you will either need to flip the image vertically on load, or flip your texCoords by swapping your y coordinates between bottom and top.

You will notice that there are 6 vertices being specified in the Cheetah3D header output, which as you already realize, isn't as efficient as only submitting 4 vertices for a single triangle strip "quad". The efficiency of submitting triangles using glDrawElements like that is important though if one is submitting lots of geometry, such as perhaps, lots of quads all at once, but that is whole 'nuther conversation, and only necessary if you're pushing performance limits. Typically, you can draw lots and lots of single triangle strip quads before you need to consider other options.

 

[Elphaba]

Thanks again.

So to recap to make sure I'm clear, there is no need to worry about or use cheetah to do all my 2d graphics, because I'm just going to end up texturing quads?

And you are suggesting using core animation to load the sprites? I intended to stay in OpenGL the whole time.

Doesn't that make pixel perfect collision detection much harder?

 

[AnotherJake]

So to recap to make sure I'm clear, there is no need to worry about or use cheetah to do all my 2d graphics, because I'm just going to end up texturing quads?

That's correct.

And you are suggesting using core animation to load the sprites? I intended to stay in OpenGL the whole time.

Core Graphics, not Core Animation. Look at Apple's GLSprite demo for image loading example, or the Texture2D class, if you can find it (it used to be included with their CrashLanding sample but they took that down). OpenGL doesn't have any image loading facilities. BTW, the best image format is PNG.

Doesn't that make pixel perfect collision detection much harder?

No. Pixel perfect collision detection is a pain in the a$$ with OpenGL regardless. Speaking from experience, it is unlikely you will need pixel perfect collision detection anyway. At most, all you'll need is polygonal collision detection, but simple circle or AABB are usually more than sufficient -- users rarely, if ever, notice fine detail with collision detection. If you need to use polygonal collision detection then you might consider looking into using Chipmunk Physics as well.