I did this last year, and it might be fun to review what I wrote… So let’s see, I ended last year’s post with this

So, by this time next year I’ll be happy if I’ve created at least one complete game of some description. I don’t even care if it’s just Pong with a computer opponent you can’t beat. Let’s set the bar nice and low to start with.

And if you go over to iTunes you’ll see I did indeed manage to create a game called Ship Goes Up It took me a number of months and was somewhat fiddly. Some people that bought it even commented that it was quite fun to play. I think that constitutes success. I also managed to help out a friend with an Android game called Retro Blitz that he’d wanted to put on the App Store (it was created using some cross-platform tool so converting it to an iOS app was as difficult as compiling the supplied XCode project, tarring it with the App Store glue and waiting for Apple to do their thing).

In other news I received a BBC Micro for Christmas along with a Fignition AVR-based computer. The BBC Micro needs me to buy an SD card reader for it, and the Fignition needs me to learn Forth. I have ideas to type out some of the simple “games” from several 80s computer books that I own. It might make a nice diversion from the other thing I spent this year doing…

If you’ve read this blog recently you’ll have seen several videos of me slowly getting to grips with ‘Real’ OpenGL ES 2.0. Real, full-fat OpenGL ES, complete with me having to learn basic linear algebra and other highly confusing concepts. All I can say is that learning something confusing like what a ‘ModelViewMatrix’ is takes more than an afternoon of playing in OpenGL. Learning all this stuff seemed to follow the pattern of me reading a book or blog entry about it, getting confused, reading several others, asking some questions, fiddling around for a week or so, then re-reading the books and blogs while thinking “oh right, that now makes sense!”. I can’t learn the stuff without reading the books first, and I can’t make sense of the books without fiddling with the examples.

Go and learn proper 3D maths now, it’s really hard

So, in the name of progress I want to achieve two things next year

1. Make a fun 3D game that people play for more than 30 seconds
2. Have it sell more than 10 copies

so that it’s worth me renewing my iOS dev license in August. I mean, £59 isn’t so bad – it’s more fun than spending the equivalent on an XBox Live Gold account or shovelling money into WoW or Rift (and I can’t play those games anyway, I don’t see a level 50 warrior elf running through the forest, I see a scenegraph apply matrix transformations to a 3D mesh while the entire world is translated down the Z axis).

Many things are cool, like this screenshot of XCode for example…

The 'Capture OpenGL ES Frame' view in XCode 4

this is what happens when debugging iOS apps that use OpenGL, there’s a handy button to click that lets you poke around in the OpenGL ES state. It shows running GLSL programs and the state of the buffers. Quite useful when you’re confronted with a black screen.

Anyway, that’s not what a scene graph is, I’m not even sure if what I constructed is really a scene graph either. I do know it’s a really handy concept that has made structuring my 3D code so much simpler. I always had the problem of how to put a 3D object in the game world at one position, and then have something like a ‘drone’ ship orbit that object, or make ‘bullets’ shoot out of the ship. Or something simple sounding like have a camera that follows an object (this is not simple BTW, it effectively involves undoing all the transforms made to your scene so that the bit the ‘camera’ looks at is positioned at 0,0,0. The maths is horrid but this thread explains matrix inversions well enough).

Click here to view the embedded video.

What I created was a simple tree structure that holds the relationships between game entities. Each Entity object has a list of pointers to child Entity objects and so on. This is just an STL vector of pointers to ‘Entity’ objects. There’s an update function that recursively goes down the tree calculating the ModelView matrix of each entity based on the ModelView matrix of its parent. Recursion is cool like that, if you’ve got a tree you need recursion it makes calculating things very easy.

However, traversing a deeply nested tree isn’t so useful if I want to find a specific entity (like the player ship because the user just poked the screen), so rather than the tree being a container for all the entities it merely defines relationships between entities. The entities themselves live in a bog standard array that I can quickly loop through pulling out things to draw on the screen, etc. Making an Entity first involves finding a free slot in the master Entity array, then adding its pointer to a suitable parent Entity.

Oh in the demo video ignore the missing right-hand edge of the canyon, I was testing out different camera angles. One day I’ll work out how to smoothly move the camera from one angle to another to do fly-bys and different game modes. I’ll probably work that out on the same day I make the enemy ships fly by themselves since it’s the same thing

Next thing – multi touch so there can be steering of the ship and shooting. I got rid of the tilt controls, they were annoying me (mostly because the light in my room was reflecting off the screen!).

It's getting a bit nippy out

There has been progress on my “fly endlessly down some sort of canyon” iPad thing. Quite a lot of this progress has been non-visual infrastructure code where I’ve taken hastily hacked test code and rewritten it in a more reusable and thoughtful manner. The main visual changes are that we’re now flying over ice and snow after I watched the BBC’s Frozen Planet series and decided the bit where we fly down a canyon carved out of the Arctic ice sheets looked kind of cool. It’s also winter and getting a bit cold outside.

I’ve also got some basic tilt controls working so that the ship moves left and right depending on how you tip the device. Tapping the screen makes the ship rise and fall. I need to adjust this as everything is a bit slow and smooth but for now it’ll be enough to let me try the next thing on my todo list. There’s a video to watch below.

Click here to view the embedded video.

So what’s next? Maybe a few nights spent playing with Milkshape3D drawing low polygon ships to shoot at. I can do quite a lot of gamey stuff if there’s some opponents, rather than plugging away at invisible infrastructure code – I wrote some linar algebra to generate an orthographic view for the HUD (that’s the thing saying ‘Yo’ on the screen) and worked out how to have two different shader programs running. All that effort to make a small square appear on the screen. And lots of effort working out how to make this automatically scale to different screen sizes, which works rather well and means an iPhone version just “plops” out the compiler with no effort.

It takes hours to make that stuff work, but since it doesn’t produce anything worth looking at I’ve not bothered writing about it! I really need to work out some sort of tripod arrangement for my iPhone so I can record videos better, one-handed iPad waving while holding a phone doesn’t work very well.

Uh oh... someone's deleted one of my standard C++ headers?!

If you use XCode and have to deal with C++, Objective-C and Objective-C++ you might one day come across utterly mind-bending compiler errors that seem to defy logic. Weird things like header files not being found, or GCC somehow forgetting what the keyword ‘class’ or ‘template’ means.

And it can take hours of head-banging to work out the cause. So here’s a hint…

Make sure XCode thinks your source is the correct type. Is it compiling your crazy mix of C++ and Objective-C as Objective-C++, or has it got in a mess and is trying to compile it as Objective-C?

This can happen quite innocently if you hand create an Objective-C++ source file and name it foo.m instead of foo.mm. Especially since nothing bad will happen until you try to #include something that somewhere eventually #includes some C++. So you might have a load of Obj-C that through a chain of #includes/#imports eventually tries to use some C++. And then it’ll all go wrong.

The compiler doesn't seem know what the 'template' keyword means?!

You’ll know it’s gone wrong when illogical things happen. Things like a file that used to work fine suddenly no longer compiles, even though you’ve not altered anything inside it (all you did was #include it).

Time to find bug – ten minutes. Time to fix bug – less than a second.

Coming next… how to find the location of those bizarre backward_warning.h #warnings.

Back when I owned an ST (well, I still have it, but you know what I mean) one of my favourite demos was Ooh Crikey! Wot a Scorcher By The Lost Boys. The main “menu” consisted of a scrolling 3D landscape you had to pilot a small ship over. I think I spent more time exploring that than watching the demos.

To further my learnings of OpenGL I figured it’d be a nice achievable goal to reproduce something similar on my iPad. Here’s some screenshots to represent today’s progress.

My first attempt didn’t go so well… there were a few issues with the simple task of drawing some triangles on the screen to represent a flat 2D plane. Amusingly the bugs were nothing to do with drawing vertices, calculating vertex normals or orienting the screen correctly. No, I’d got my pointer arithmetic a bit messed up and was merrily scribbling all over allocated ram then shovelling nonsense into the GPU. Still, it’s a nice shade of orange, I might find the RGB for that later.

Here in DaliWorld everything is all melty and strange

After regaining sanity and having something to eat I managed this lumpy mess. Definitely not the look I am after, I’ll leave blocky landscapes to other people

Look out Notch

Ah, now we’re getting somewhere… somewhere very angular but correctly (ish) lit and a whole lot more fun to show on the web. Everything looks a bit too “big” and mashed against the screen though.

Not safe to land here!

Here we go, much better… if it were 1984 and we still used BBC Micros. Reminds me a bit of Captain Blood on the ST too. Maybe I’ll have an option to turn the filled triangles off, it’s a doddle to do. Oh yeah, and I made the iPad the right way around.

Pointy Polygons aren't retro enough

And so this is where I am at now. The light shines on the correct side of everything in a WELCOME TO THE EMERALD CITY OH MY ISN’T EVERYTHING SO VERY GREEN AND SHINY! kind of way that seriously needs some attention. Currently it’s just drawing random data with a canyon carved into it since I couldn’t be bothered drawing a heightmap and writing yet more text parsing code. Today was “do fun visual things in OpenGL” day.

Do not adjust your set, allow the soothing green to burn out your eyes

When I next get time I want to turn down the colour a lot and make the landscape scroll towards the player. What you can’t see is a whole jumble of polygons off the screen edges that I really don’t need to draw. This code is so inefficient

You’ll notice this is a landscape game now, that’s mostly because it’s much easier to take videos of and stick them on YouTube. I don’t quite know what the game will be, it could be a sort of Virus/Zarch type thing, or a Captain Blood canyon flying thing. Ship Goes Down The Z Axis anyone?

After a lot of chopping of code, rewriting bits and pieces and generally trying to turn a hacked mess into something more structured I have this…

Click here to view the embedded video.

What you’re looking at is a pair of spinning spaceship things lit with a moving light. What you’re really looking at is a clever arrangement of triangles that get coloured in according to some slightly complex maths so that it looks like there’s a moving light. OpenGL ES 2.0 is funny like that, you get to write your own lighting algorithms (or find them on the Internet).

Now I have the basics of “construct a 3D model” “put it on the screen” and “light it so it looks 3D” working I can get on with making something that isn’t a tech demo.

So after creating a fun little iOS game using OpenGL ES 1.1 I decided the next thing I create should use ‘real’ 3D, rather than simply bashing OpenGL into managing 2D scenes for me. To make life even harder I decided OpenGL ES 2.0 would be better to learn.

Yeah, there are easy challenges, then there is the equivalent of doing a weekend’s walking in the Lake District then booking a flight to go walk up Everest. I think I picked the equivalent of trying to swim to the moon. You see the thing with OpenGL ES 1 is that a lot of the ‘hard’ stuff is neatly hidden behind handy GL commands – gl_rotate, gl_lighting and so on. Not so in GLES 2.0, you get to do it all yourself, plus you get to learn all about shaders. In fact you need to learn about them to make anything appear on the screen.

Shaders are fun, they’re little programs that run on your graphics hardware. They look like C, they get compiled by your code and executed. Little programs that can contain bugs. The interesting part of all this is when you feed wonky code into your machine and it simply quits the software. No errors, no popup warnings… it just stops working. Or you get a black screen.

I like the challenge of learning this stuff. At one time I had trouble understanding what a ‘modelview’ matrix was. Then there was the confusion over linear algebra, and the fun few weeks spent hand coding a Wavefront OBJ loader using vi, gcc and my Wyse serial terminal (who says tedious coding can’t be fun! Also it’s quite distraction free coding on a device that can only show 80×25 ASCII characters). Once I’d done that I managed to make this appear

Pointy things

Oh yeah, to make that I needed to get a 3D modelling package that wasn’t Blender, learn how to use it and then make it save its data in a format I could actually use. What you can’t see in that image are the many many failed attempts at getting anything on the screen. Did you know that if you feed a badly constructed vertex buffer object into OpenGL ES on an iPad the device will lock up hard and reboot itself? Yeah debugging that was fun, it doesn’t do that on the simulator.

So after mastering the difficult technique of making coloured objects appear on the screen I thought it’d be fun to light them. And this is where I learnt many new things, none of them to do with gouraud lighting algorithms or to do with surface normals. No I learnt lots about how to debug shaders.

Imagine having a horribly complex piece of software that is broken. Imagine your only way to debug it is to look at the code and think really hard. The code either works, or it does something odd that results in a black screen (that’s why the screen is green in my pictures, at least then I can tell the difference between ‘broken’ and ‘no colour’). There’s no registers to look in, no debugger to play with.

The most important lesson I learned was all to do with connecting the C++ code to the shader. In my code I have a list of vertices, normals, colour data, and so on. The shader code has to somehow receive this data and process it, meaning somehow there is a link between my C++ code and the shader code. It’s a bit like using LUA in an application, or linking to a DLL. There are symbols and a way to bind them to handles.

This is shader code to define a sort of input variable to the shader, called ‘LightPosition’, you can probably guess its purpose.

uniform vec3 LightPosition;

And in the C++ code you do this to connect the two together

_lightPosition = glGetUniformLocation(programHandle, "LightPosition");

‘_lightPosition’ is a sort of handle used by other GL commands. glGetUniformLocation() looks into the shader code and finds the ‘LightPosition’ variable so that data can be put into it using code such as

vec3 lightPosition(1, 0, 0);
glUniform3fv(_lightPosition, 1, lightPosition.Pointer());

(oh yeah, you get to write your own matrix functions too, isn’t that fun!)

So magic happens and inside the shader the variable ‘LightPosition’ gets given the value (1,0,0).

Unless you spell ‘LightPosition’ wrong and call it ‘lightPosition’. Then it doesn’t do anything at all! And nothing notices, nothing gives an error… it just continues but you see black, unlit shapes instead.

I spent way too many hours taking my code apart and systematically replacing bits of working code with test code, and so on trying to find out why nothing was working. Eventually, quite by accident I found the bug, had a little swear and shout, fixed it, recompiled and …

It works!

So what’s next on this severely overhanging learning curve? I think moving the lights around the scene might look quite pretty. Yeah, that can’t be too hard

… and a bit of iOS file faffing.

Getting paths to files inside the iOS application’s bundle:

NSString* objPath = [[NSBundle mainBundle] pathForResource:@"test" ofType:@"obj"];

‘objPath’ will now contain the full path to the file (test.obj in this example). Which is great if you’re going to poke it into an Obj-C function that understands NSStrings. However if you have C++ code it’ll probably want to be a std::string.

So to convert an NSString to a C++ std::string you can do this:

std::string filepath = [objPath cStringUsingEncoding:[NSString defaultCStringEncoding]];

And now you have a std::string with the contents of the NSString. Coding in Objective-C++ is like this, lots of converting one version of a concept to another.

If you like, you can also extract the path to a file using some simple C++:

std::string path = "root/data/home/file1.txt";
// no error checking here
std::string prefix = path.substr(0, path.find_last_of('/'));

C++ and Objective-C, making your programming efforts feel like it’s still 1990. I wrote a file parser in straight C++, it was like stepping back into my software engineering degree. There will be a post about it later, it’ll involve vi and a 9600bps serial terminal.

I found the following Stack Overflow questions useful:

• http://stackoverflow.com/questions/6319628/c-get-directory-prefix
• http://stackoverflow.com/questions/4313759/files-in-folders-not-found-in-ios-app-using-c
• http://stackoverflow.com/questions/3552195/how-to-convert-stdstring-to-nsstring

I don't see the 3D shapes, all I see is... err a black screen or OpenGL errors...

There will be a less predictable image in a future post, once I produce something worth looking at that makes sense to you.

I’ve been spending the past few weeks learning how to persuade OpenGL ES 2.0 to behave and draw things on my iPad. During those two weeks I’ve encountered black screens, madly spinning 2D triangles and even the odd occasion where my iPad force-rebooted itself.

Slowly I’ve gone from knowing enough OpenGL 1.1 to draw a 2D textured quad, to knowing enough OpenGL ES 2.0 to draw a 3D unlit, untextured shape. And some fiddling with shaders, which they teach you first. Can’t beat dipping your toes into some entry-level coding tutorial that begins with GPU programming.

Matrices went from a vague mystery to something that no longer gives me a headache, and stuff isn’t upside down any more. Remember kids, pay attention in maths at school, 16 years later you might need that knowledge.

It’s a steep learning curve with fractal-like diversions as you learn just enough to be dangerous, getting ideas like “so then… rotating an object to face another, that’d be useful to do”.

My next two things are “load Wavefront OBJ files” and “lighting”.

If you have a freshly installed copy of Snow Leopard, and an equally freshly installed copy of XCode 4 you’ll find that XCode 4 doesn’t support the git source control system. This can be a problem that suddenly happens after reinstalling OSX, but fortunately the fix is very simple.

XCode expects the git binary to be in /usr/bin however OSX installs Git in /usr/local/git/bin. Fixing it is as difficult as setting up an appropriate symbolic link and restarting XCode:

Find out where git is

cubee:~ james$ which git
/usr/local/git/bin/git

Create a symbolic link

cubee:~ james$ sudo ln -s /usr/local/git/bin/git /usr/bin/git