Kondrian summary

Development summary for Kondrian

  • its Universal,
  • its written in Objective C (no C++),
  • home grown graphics engine (apart from the GLK* and OpenGL ES),
  • uses OpenGL ES 2.0, VBOs, VAOs and many other OpenGL ES 2.0 goodies,
  • uses GLKit, a GLKViewController and GLView – but uses standard OpenGL ES 2.0 shaders (just because they seemed slightly faster),
  • Continue reading

Drawing lines in OpenGL

(with the help of GLKit)

There are many ways to do this, its often used in paint programs.

Philip Rideout’s iPhone 3D Programming has a way to do it in C++, but its hard to abstract the method from the code.

There is a nice article written here which gives the method I used.
In my case the lines are temporary exhaust lines – so I don’t need to bake the lines into a texture as the above solution does.

The method just draws line segments from point to point as rectangles. Each line segment is a sprite which is rendered which ever way you render your OpenGL sprites.

Here is a picture of a ship emitting an exhaust – that uses the code below – the ship is moving very fast – so the sharp angles don’t matter so much.

swoop pic

And below is the code I wrote to do the lines:

Continue reading

Particle systems in IOS Game X

This is part six of a series on making iOS games.


With hundreds or thousands of particles on the screen, a particle effect is a great way to bring your frame rate precipitously down. There are so many different aspects of the particle engine that can effect performance.

Michael Daley has a whole chapter on this (see resources below – and he is right – its a big time sink).

I started off just extending the normal sprite classes which I created in the game template (which I talked about in the last post in this series), and then gradually moved to including more and more optimisations.

I (like everyone else) pre-create a number of particle engines, so that the expensive operation of memory allocation does not have to happen during the game, more as a precaution, than something I’ve rigorously tested with the profiler in Instruments.

Point sprites

Point sprites are a common thing to use with particles effects, to try an optimise things. With each particle as a point sprite you dont need to pass as much data to OpenGL, theoretically 1/6 of the data, since you are only passing one vertex per sprite, not two triangles.
In order to use point sprites you need to set the point size in the traditional vertex shader. I couldn’t see any docs on how to manage the point size in the GLKit base effect – this would be something like:  


in the normal OpenGL ES 2.0 vertex shader.
So I experimented a bit and created a particle engine using the usual OpenGL ES 2.0 vertex and fragment shaders to do point sprites, and the same (as the game template in the previous post) GLKit base effect for the other sprites such as the player, background tiles etc.

Continue reading

The iOS Game Template extras

This is part five of a series on making iOS games.

Continuing on from last week, this post describes some of the non OpenGL parts of my iOS game template, and then finishes with some discoveries.

Centre of the universe

Since the player is the centre of the universe in my game, I can apply one translation to all my sprites.

Here is the simple translation I do:

GLKMatrix4 modelViewMatrix = GLKMatrix4MakeTranslation(bounds.size.width * 0.5 - player->location.x, bounds.size.height * 0.5 - player->location.y, -6.0f);
spriteEffect.transform.modelviewMatrix = modelViewMatrix;

The z coordinate is arbitrary number – maybe I’ll use the z later at some stage.


Properties were great for memory management pre ARC – now of course ARC takes care of that, however in non games I still do tend to use only properties to access ivars. In a game I often do the opposite, I access the ivar directly, I try to avoid message passing. It can significantly deteriorate performance. With operations that are happening hundreds of times per second, messages (properties or methods), can hammer down the frame rate (I guess I could have my cake and eat it too, that is performance and classes by using C++. I don’t like C++, so I am not going to do that). Of course there is always a balance between performance and ease of use, so for my player sprite and monsters, I tend to use classes and instance methods, but for particles I use structs and functions.

Continue reading

The iOS Game Template setup

This is part four of a series on making iOS games.


A little while ago, I created a fairly generic OpenGL ES 2.0 game template (Xcode project) for a 2D game. It used standard vertex and fragment shaders. For this project I wanted to use GLKit effects, a GLKViewController (and it’s view) and storyboards.

So I used Ray Wenderlich’s excellent digital book “iOS 5 by Tutorials” to come up to speed. http://www.raywenderlich.com/store/ios-5-by-tutorials. Chapter 8&9 are the ones.

Ray’s tutorials will give you a good grounding in OpenGL for iOS 5, if you need that grounding. A bit OpenGL background might make this blog piece more interesting, because I won’t be explaining a lot of basic OpenGL things much (eg things like quads, shaders, vertexes, vertex structs, buffers etc).

In addition, Ray just recently came out with another tutorial on his excellent site which expands some on his previous OpenGL tutorials: http://www.raywenderlich.com/9743/how-to-create-a-simple-2d-iphone-game-with-opengl-es-2-0-and-glkit-part-1 and http://www.raywenderlich.com/9776/how;g-to-create-a-simple-2d-iphone-game-with-opengl-es-2-0-and-glkit-part-2.

Worth reading before reading the rest of this post

More challenging stuff

After setting up the initial story board, GLKViewController and GLKView, the next step for me was to add VAOs and VBOs (both of which Ray avoids in his most recent post).
Its fairly easy.

Here is my main VBO/VAO setup:

glGenVertexArraysOES(1, &vertexArray);

glGenBuffers(1, &vertexBuffer);
glBindBuffer(GL_ARRAY_BUFFER, vertexBuffer);
glBufferData(GL_ARRAY_BUFFER,spriteCount * 4 * sizeof(SmallVertex), vertices,GL_DYNAMIC_DRAW);

glGenBuffers(1, &indexBuffer);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, indexBuffer);
glBufferData(GL_ELEMENT_ARRAY_BUFFER,spriteCount * 6 * sizeof(GLushort), indices,GL_STATIC_DRAW);

glVertexAttribPointer(GLKVertexAttribPosition, 2, GL_SHORT, GL_FALSE,sizeof(SmallVertex), (const GLvoid *) offsetof(SmallVertex, Position));
glVertexAttribPointer(GLKVertexAttribColor, 4, GL_UNSIGNED_BYTE, GL_FALSE,sizeof(SmallVertex), (const GLvoid *) offsetof(SmallVertex, Color));
glVertexAttribPointer(GLKVertexAttribTexCoord0, 2, GL_FLOAT,GL_FALSE, sizeof(SmallVertex),(const GLvoid *) offsetof(SmallVertex, TexCoord));


One can scale the base case and just do hundreds of draw calls (each draw call with its own setup) – one for each sprite/image, but that might get slow, even if you packaged up into different VBOs/VAOs. If you had really complex shapes (3D models), you might have them in different draw calls because the shaders might make your scaling and transformations easier. The number of separate moving objects might be relatively low in a scene.

I just went straight to batching.

Continue reading

iOS Game X Technology

This is part three of a series on making iOS games.

I needed to decide on which technology to use in the game and a put down initial ideas on how elements in the game are to be structured.

Graphics Technology

I could write the game visuals using:

  1. UIKit
  2. Core Animation
  3. Third Party Framework
  4. OpenGL

1 and 2 are generally too slow for the 2D action game I am making (although I believe Core Animation is surprisingly fast and can handle hundreds of animating views on the screen).

My view on the third party issues is outlined below in a Napkin. I chose number four: OpenGL.

Continue reading

iOS Game X – Game Play

This is part two of a series on making iOS games.

How will I try to entertain the player? What sort of game play will there be?

Here is a list of things that I hope to offer in the game:

  • exploring the environment (people like a tour)
  • discovering all sorts of wierd and wonderful monsters
  • destroying them with a glorious range of weapons
  • having to do all this at speed

Source:  amigan
Remember this one?  My first mac game – I got it along with my first and only mac trojan.

Touching the World

It was tempting at first to try and squeeze this game into something which can be played with one thumb. One thumb games however, grow dull on me quite quickly.

The “Touching the world” meme, in regards to the user interface of a game, is one that Graeme Devine mentions a lot (see his excellent WWDC talks 2010, 2011), referring to the screen of iOS devices being the interface (in contrast to physical joysticks), and how you can/should manipulate the game world through that interface both more directly and more subtly.
I agree this idea has a lot of validity.

Continue reading

New Series: Making an iOS Game

Part One.


There is a common notion that has been going around the web for a while. That notion is that if you want to write games you have to be a die hard gamer and a die hard game programmer.

I don’t agree.

I think most people like lots of things. They like to play games sometimes, and like to do a lot of other things too – socialise, get out in the fresh air, exercise – whatever.

I also think that it also should be ok to make a game – even though you like making other things too.

Of course: I don’t subscribe to the other notion going around that writing a game is a waste of time either.

Writing a game can be challenging though, there are a lot of different things that go into a game, a lot of new things to learn. Its very hard to just dabble, or experiment in game writing, because you have to devote a lot of time, before getting something halfway satisfactory. Even more time than learning a J2EE framework used to take a half decade ago (before the world was taken over by Rails and its philosophical brethren).

Continue reading