So as well as game play ideas, we’ve been prototyping the tech we’ll need to bring our world to life. The game will be 2d, but we really want to find a good way to render lights and shadows to create a dark, threatening experience.

After some Google-ing I found a good starting point over on GameDev.net. The basic idea is that each light is rendered into a buffer (the alpha buffer in this case), and then any shadows are rendered on top, blacking out the light. The alpha buffer is then combined with the scene geometry to add colour to the scene.

Fairly quickly I was able to get the basic algorithm up and running. The problem though is that each light requires rendering a screen’s worth of data, and frame rates drop drastically after adding more than 2 or 3 lights. So I started looking around for other options.

One idea that appealed was to render all the lights into a single buffer, and then use a single pass to lay this back over the scene. The problem here is that we can’t just render each light’s shadows into the buffer as black.

The answer here is to calculate the shadows for a light and incorporate them into the mesh used to render the light – i.e. instead of, say, a circular triangle fan for a light source, we generate a mesh for the circular fan minus the shadows.

So, after a few false starts I managed to get the basic algorithm working, and you can see its development in the screen shots on this page. The good news is that we can have large (double digit) numbers of lights in a scene, all casting shadows and all able to be moved or turned on and off dynamically each frame. Currently performance is about 45fps on a 2nd gen iPod Touch, but I’m fairly confident that can be drastically improved with some basic optimisation.

Once I’ve got the code properly under control, I’ll write an article covering the technique in some depth, if people are interested.

The last screen shot here shows the algorithm working at the moment. I still need to add spot lights rather than point light sources, but that should be a fairly simple thing to add. There’s a couple of bugs still to iron out too, but I think it proves the concept well enough to let us move onto prototyping other parts of the game. The addition of textures makes a huge difference too. While this is still very rough, I think there’s some real promise here, and can’t wait to start building the game that makes the most of it!

Dan Grigsby over at Mobile Orchard has put together a screencast that explains the process of provisioning an iPhone / iPod touch.  It’s well explained, simple to follow, and a very handy resource to have around.  It’s a free download for the next week, after that it’ll be US$5.  So if you’re a new developer, or if this is something that you’re a bit unsure of, grab the screencast while it’s free.

So here’s the plan.  I want to set up libraries of useful code that I can re-use across projects.  For the iPhone this currently means statically linked libraries.  Next, I want to create unit tests for the libraries and have the tests run as a part of my build process.  If you just want to get your hands on a working sample, grab it here.

OK, let’s get started.  I’ve created a new project in XCode.  Any will do, but I like to see something visual, so I created an OpenGL application called CoolGame.  By default, XCode adds new files into one monolithic folder, which is a pain.

Instead, open the project folder in the Finder, and add a folder called UnitTest++ under the main project folder, for example,  {YourProjectPath}/CoolGame/UnitTest++.  Download the latest version of UnitTest++. Open up the downloaded folder, we want to copy all the files from the src folder into our UnitTest++ folder.  You can leave out the Win32 and tests folders if you like, we won’t use them.

Going back to XCode, control-click (or right-click) on ‘Targets’ and add a new iPhone static library target, calling it UnitTest++.  From the finder, drag and drop the UnitTest++ folder into XCode, just below the project name in ‘Groups & Files’.  In the dialog that pops up, uncheck ’Copy items…’, select ‘Recursively create groups…’ and ensure we’re adding them only to the UnitTest++ project.  Control click on the UnitTest++ target, and try building it.  If all is going well, it should build happily.  Now we need a test case to prove it’s all working nicely.

Lets add two new targets to the project.  One is a static library (‘FrameRateLibrary’ in my case), and the other is an application (‘FrameRateLibraryTest’).  FrameRateLibrary represents our library code, and FrameRateLibraryTest will run unit tests on that library.  FrameRateLibrary will also be used by our main application, CoolGame.  In a larger project, you might have multiple versions of these, one for your renderer, one for a sound, one for UI and so on.

Control click on ‘Groups & Files’ to add a new group called FrameRateLibraryTest.  Add a second one called FrameRateLibrary.  This will help us keep the code nicely organised. It may seem a bit strange, but we’ll get FrameRateLibraryTest working before FrameRateLibrary.  This is a fairly common approach with Test Driven Development – prove the test works before you write the code to pass it.

Control click on the FrameRateLibraryTest Group to add a new C++ file.  I’ve called it FrameRateLibraryTestMain.cpp.  In the dialog that pops ups, uncheck the ‘create a .h file’ option (we won’t need one), set the location to be {YourProjectPath}/CoolGame/FrameRateLibraryTest, and ensure that it’s being added to the FrameRateLibraryTest target only.  You’ll be asked if you want to create a new folder, say yes.

I added the basic code below, then tried to build the test application and it failed.  Apparently the build is trying to include some Object-C code from somewhere, probably a precompiled header file.  If anyone can fill me in on what’s happening here I’d appreciate it.  Anyway, rename the file to FrameRateLibraryTestMain.mm and it should build happily.

int main(int argc, char *argv[])
{
    return 0;
}

Next step is to link in UnitTest++ library and add a simple test.  Change FrameRateLibraryTestMain.mm by adding the code below.  Select the FrameRateLibraryTest target, and click the info button (big blue button with an ‘i’ in it).  Add libUnitTest++.a both as a dependancy and a linked library.

#include  "UnitTest++.h"

TEST(FailSpectacularly)
{
    CHECK(false);
}

int main(int argc, char *argv[])
{
    return UnitTest::RunAllTests();
}

Now let’s test what we have.  From the project menu choose “Set active target…” and set it to be our FrameRateLibraryTest target.  Build and Go, and the iPhone Simulator should pop up briefly, but more importantly, if you look at the console output (you may need to switch to debugging view), you’ll see that our tests ran, and failed spectacularly, as we would expect.  Hurrah!  Note, that clicking on the error takes you straight to the test case that has failed.

Failure, excellent!

So, to recap.  We have a separate application that runs tests, which is linked to the UnitTest++ static library.  We can run the application to run our test code.  We have two things left to do:

1. Set up our FrameRateLibrary library, and tests for it, and
2. Run the tests as part of the main (CoolGame) target’s build process.

Let’s tackle the second of those problems first.  Switch the active target back to CoolGame (from the Project menu).  Control click on CoolGame target, and choose ‘Add new build phase | New Run script’.  Get info on the run script phase, either by clicking the ‘i’ button as we did before, or control clicking on the CoolGame target and choosing ‘Get Info’.  In the info dialog, add:

$TARGET_BUILD_DIR/FrameRateLibraryTest.app/FrameRateLibrary

Build and go now, and this fails, but not in the way we want.  This problem caused me some grief until I realised that the problem was my script trying to run an iPhone application as a Mac one.  Oops.  What we actually need is to get the iPhone simulator to run the test application for us.  After much gnashing of teeth (and some of googling), I found a description of what to do on CocoaWithLove, using a trick from the Google Toolbox for Mac.  So the final script ends up looking like:

export DYLD_ROOT_PATH="$SDKROOT"
export DYLD_FRAMEWORK_PATH="$CONFIGURATION_BUILD_DIR"
export IPHONE_SIMULATOR_ROOT="$SDKROOT"
export CFFIXED_USER_HOME="$USER_LIBRARY_DIR/Application Support/iPhone Simulator/User"
$TARGET_BUILD_DIR/FrameRateLibraryTest.app/FrameRateLibraryTest -RegisterForSystemEvents

If you try to build now, the build should fail (in a good way), pointing to the test that’s (deliberately) failing.  This is a good thing!  Let’s ‘fix’ the test by removing it in FrameRateLibraryTestMain.mm, and next time we build we’ll get a nice green tick.  Note, you may need to ‘get info’ on the CoolGame target, and add FrameRateLibraryTest as a dependency, otherwise, when you change the code in FrameRateLibraryTestMain.mm, it won’t recompile it when you build the CoolGame application.

OK, one last thing to do, let’s actually put in place a useful test of our static library.  Get Info on FrameRateLibraryTest, and add FrameRateLibrary as both a linked library and a dependancy.  Let’s make out test code for the library. As a proof of concept, let’s create a test that asks the library for our application’s frame rate – 60 frames per second in this case.  Add the following to FrameRateLibraryTestMain.mm:

#include "FrameRateLibrary.h"

TEST(CheckFrameRate)
{
     CHECK_EQUAL(60, GetFrameRate());
}

With our test done, we can write the code that it’s testing.  Add a FrameRateLibrary.cpp file (and .h) to the FrameRateLibrary group  In the dialog that pops up, choose {YourProjectPath}/CoolGame/FrameRateLibrary as the location to create the files and ensure they’re added to the FrameRateLibrary target.

Add the following to FrameRateLibrary.h:

extern int GetFrameRate();

and FrameRateLibrary.cpp:

#include  "FrameRateLibrary.h"

int GetFrameRate()
{
    return 30;
}

Note, in the best traditions of TDD, I’ve set up the test to fail before it succeeds.  This is to prove the test is actually running correctly and is an essential step.  Try building now, and the build fails, highlighting the test case that is broken.  Let’s fix the GetFrameRate() function to return 60, not the 30 I ‘accidentally’ put in there.  build now, and we should be all happy again.

Well almost.  One last thing is to link our FrameRateLibrary into the actual application we’re creating.  This is fairly simple and uses the techniques we’ve seen several times already (adding the FrameRateLibrary to our target as a dependancy and a linked library).  When I did this though, the build failed with an unresolved symbol error for GetFrameRate().  The place I’d used the GetFrameRate() function was in CoolGameAppDelegate.m – which was being compiled as pure Objective-C due to the .m suffix.  Renaming the file to CoolGameAppDelegate.mm fixed the problem.

Phew!  This was a long post, but we’ve achieved a lot.  We can set up static library targets, test them and run the tests automatically as part of the build process.  It seems like a lot of work, but in fact it can be set up fairly quickly.  Adding UnitTest++ target and code as part of a project template would make the setup signifcantly easier.  I’m still learning the ins and outs of iPhone / XCode development as I go, so please feel free to point out areas where I could do things a little bit better.  Full source code for this tutorial can be found here.

Particle systems also lie between the realms of artists and programmers, so they make an appealing option for a company built around two programmers with limited artistic abilities!  So in this article (and the ones that follow on from it) I’ll jump on the bling train and discuss the design, implementation and optimisation of a particle system engine for the iPhone. Here’s my want list of features from a design point of view:

• The ability to manage a wide range of types of particle systems.
• Creating a new particle system should require a minimum of coding, and rely on the underlying engine to handle the more mundane tasks, such as rendering, frustrum culling, memory management and so on.
• Particles should be able to act as emitters, generating new particles (or maybe even entire particle systems?)
• Rendering should be as fast as is feasible – the more particles we’re able to render, the more we can achieve visually.

From a technical point of view, there’s a lot of issues to address:

• Designing base functionality that can be easily extended with the minimum of code.
• Avoiding frequent memory allocation (this can be a significant performance killer).
• Choosing between point sprites (fast) and textured quads (more flexible).
• Fast floating point operation – particle systems typically involve massive numbers of vector operations.
• How to store and hand off data to OpenGL for maximum efficiency - because of a particle systems dynamic nature, we’ll be resubmitting our vertex data every frame.

So, armed with a set of design goals, it’s time to do some hunting around for inspiration.  One of the better articles out there is this one by John Van Der Burg.  Also, Apple offer some handy tips for good OpenGL performance on the iPhone here.  There’s also some useful tips in various Game Programming Gems books.

Wow, look at me still talking when there’s science to do.  I’ll wrap this up here and get some coding done so that I can have something pretty to show off next time…

Here’s how it went down for us:

• Create company on the 9th of May.
• Submit for application for developer program on the 10th.
• Email from Apple asking for our Certificate of Incorporation on the 12th.
• Finally get a chance to fax off the Certificate on the morning of the 14th.
• Get a phone call / email from Apple about noon.
• Purchase license about 5 minutes later.
• Prepare to wait ‘up to 48 hours’ for activation code.
• It turns up 4 hours later.
• Go to the Apple’s iPhone Dev Center and remember to log out and log back in again to see the update.
• Done, we have the keys to the Magic Kingdom.

That’s right, the bulk of the process happened in a single day.  Start to finish was only five days, two of which were a weekend, and one of which was lost due to my inability to get close enough to a fax machine.  Thank you Apple, you’ve made my week, possibly my month.

Now admitedly we haven’t sorted out all the financial details yet, but we don’t have an application to sell yet either, so I’m not too worried.  What we do have is the ability to deploy applications to an iPhone or iPod Touch now, and the first time you do that is a little magical

Sam and I also had a design session last night where we started seriously planning our first two applications.  More on that later.

A bit of a change of pace this week as we dive into something more technical.  Code that accompanies this post can be found here, and is free for you to use as you see fit.

While OpenGL provides a lot of graphical power, it’s typically at a fairly low level, giving the programmer a set of tools with which they can build higher level, more useful code.  Rendering text is one example of this.  Pretty much every OpenGL application needs to put text on screen at some stage.  But with no built in font rendering support, we’re left to our own devices.  In this blog I’ll show you one easy way to get text on screen. We’ll end up with something like the screen shot on the right.

There’s a number of different strategies we can use.

One simple option is to use an image editor like Photoshop.  We can generate a texture file with the text ‘baked in’.  It’s then a reasonably simple process to load the image into a texture and render it.  This is possibly the quickest way to render text on screen.  However, it means we need to know in advance what text we want to render.  Also, every piece of text uses another chunk of texture memory.

A second option is to render the text into a texture on the fly.  Noel Llopis from Snappy Touch describes how this can be done for the iPhone on his Games from Within blog. While this allows us to generate text on the fly, it still suffers from each piece of text chewing up more texture memory.  We’re also limited to fonts already installed on the iPhone.

Both of these techniques are useful, but sometimes we need the ability to generate large quantities of text using our own custom font.  What we can do is pre-render our character set into a texture map, and generate text as a series of textured quads, with one letter per quad.  This way we store the font once, and can render as much text as we like.  The trouble here is that we need to store all the font’s kerning information.  Now you could delve into all sorts of documentation to get the information you need.  But someone else has already done the heavy lifting for us, and we can reap the rewards.

Paul Nettle has written a nice utility for us that will take any given font and dump out a data file with all the information we need.  His Font Generation tool is Windows based, but most of us can find a Windows machine if we really need to…

So, enough talking, let’s get started.  The first thing you’ll need to do is to choose your font and install it.  There are large numbers of freely available available fonts on the net.  One good source is dafont.com.  Next, grab the Font generator from Paul Nettle’s site, under the ‘Code’ section.  It’s a fairly simple tool, select the font you want, specify a file to save it to and hit the ‘go’ button.  Transfer the generated file to your Mac and add it to the Resources section of your XCode project.

We create a class, CFont, to store our font information.  It’s constructor takes the path to our font file as an argument.  We can get the path within our application bundle using the following code:

NSString *galacticaFontPath = [[NSBundle mainBundle]
				pathForResource:@"Battlestar"
				ofType: @"fnt"];
mGalacticaFont = new CFont([galacticaFontPath cStringUsingEncoding:1]);

The file is in a simple binary format, so we use fopen() to open it and read out the each character:

void CCharacterData::Load(FILE *fontFile)
{
	fread(&byteWidth, sizeof(int), 1, fontFile);
	fread(&byteHeight, sizeof(int), 1, fontFile);
	fread(&xOffset, sizeof(int), 1, fontFile);
	fread(&yOffset, sizeof(int), 1, fontFile);
	fread(&screenWidth, sizeof(int), 1, fontFile);
	fread(&screenHeight, sizeof(int), 1, fontFile);

	buffer = new unsigned char[byteWidth * byteHeight];
	fread(buffer, byteWidth * byteHeight, 1, fontFile);
}

The array buffer contains the pixel data that we will transfer to our texture map. The other fields are used to tell us how and were to render the character. Or in other words, they contain the relevant kerning information that we need.  We load all the character data from the file and store it away for later use.

The next task is to turn this data into a useful texture map.  We calculate the size of texture we need, using the CFont::GetHeightForTexture() method, and allocate a suitably sized data array.  In the code below, each character is added to the array, and we generate and store texture coordinates as we go.  Finally we generate and bind a GL texture using our data array.

// Allocate texture data
GLubyte *textureData = new GLubyte[textureWidth * textureHeight * 4];

// Should really clear out data array...
int texX = 0;
int texY = 0;

for (i = 0; i < 256; ++i)
{
	if (!mCharacterData[i].isWanted)
	{
		continue;
	}

	if (texX + maxSizeX >= textureWidth)
	{
		texX = 0;
		texY += maxSizeY;
	}

	int offX = texX + cCharacterPadding / 2;
	int offY = textureHeight - 1 - (texY + cCharacterPadding / 2);

	// Calculate texture coordinates for this character
	float widthScale = 1.0f / (float)(textureWidth - 1);
	float heightScale = 1.0f / (float)(textureHeight - 1);

	float left = (float)offX * widthScale;
	float right =
		left + (float)mCharacterData[i].byteWidth * widthScale;

	float top = (float)offY * heightScale;
	float bottom =
		top - (float)mCharacterData[i].byteHeight * heightScale;

	mCharacterData[i].texCoords[0] = left;
	mCharacterData[i].texCoords[1] = bottom;

	mCharacterData[i].texCoords[2] = left;
	mCharacterData[i].texCoords[3] = top;

	mCharacterData[i].texCoords[4] = right;
	mCharacterData[i].texCoords[5] = bottom;

	mCharacterData[i].texCoords[6] = right;
	mCharacterData[i].texCoords[7] = top;

	// Store the pixel data in the texture
	// Should investigate using a single channel texture
	for (int x = 0; x < mCharacterData[i].byteWidth; ++x)
	{
		for (int y = 0; y < mCharacterData[i].byteHeight; ++y)
		{
			int texIndex = ((offY - y) * textureWidth) + (offX + x);
			int charIndex = y * mCharacterData[i].byteWidth + x;

			textureData[4 * texIndex + 0] = 255;
			textureData[4 * texIndex + 1] = 255;
			textureData[4 * texIndex + 2] = 255;
			textureData[4 * texIndex + 3] =
				mCharacterData[i].buffer[charIndex];
		}
	}

	texX += maxSizeX;
}

OK, so we have a font texture, what do we do with it? What we need now is a class, lets call it CGLString, to build our text and render it as needed.  The CGLString constructor takes a string with the text we want to render and the font we want to render it with.  The first time the Render() method is called, we construct a series of textured quads that are textured with the font's texture.  The actual rendering is fairly simple. We just call the CGLString's Render method:

mGalacticaText->Render();

Inside the Render() method, here's what's going on:

// Enable texturing, bind the font's texture and set up blending
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, mFont->mTexId);

glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

// Bind our vertex data
glVertexPointer(2, GL_FLOAT, 0, mVertices);
glEnableClientState(GL_VERTEX_ARRAY);
glTexCoordPointer(2, GL_FLOAT, 0, mUVs);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

// Draw the text
glDrawElements(GL_TRIANGLES, 6 * mNumberOfQuads, GL_UNSIGNED_BYTE, mIndices);

We bind the font texture, enable blending and render the textured quads. Fairly simple, eh?

And there we have it - your favourite font rendered in OpenGL.  Now what we have here is a good starting point, although there's a lot more we could add here.  A string that will be rendered repeatedly could be rendered using Vertex Buffer Objects for efficiency.  Drop shadows can be added fairly simply.  A useful method would be one that calculates the size of a piece of text. Then we'll be able to align and justify the text, or scale it if it's too large. There's lots here we can do. The code here is a useful basis on which to build. I plan to post an updated version later to show you what this could be like when fully developed.

Who?

There’s two of us, Sam and George.  ”Sam and George’s well designed and written software for the iPhone and iPod Touch” was catchy and, most surprisingly, available as a domain name, but it was perhaps just a smidge long for a company name, and so we settled on Acorn Heroes instead.  Between us we have over twenty years experience in the gaming and real time animation business, not to mention six kids, several cats, a dog, rabbit and two very understanding wives.

What?

We’re developing quality software for the iPhone and iPod Touch.  What do I mean by quality?  Careful design, consideration for the user and solid, reliable code that we will use ourselves.  While our primary goal is to bring to life some of the hundreds of game ideas floating around in our heads, we’re also keen to build useful applications that just help to make life easier, more organised, more fun, more meaningful, more… well, you get the idea.

Where?

Well ‘here’, obviously  Here for us being Dunedin, in the lower reaches of New Zealand.  It’s a lovely place, with a wealth of very talented people, beautiful scenery, and great beer.

When?

Weekday evenings, especially Thursday, because there’s nothing on TV.  And the odd weekend too.  You see, with families and mortgages, we can’t quite turn our back on ‘The Man‘ just yet.  And besides, in my case ‘The Man’ is a friend and good employer.  So this is a part time effort – although that doesn’t mean we’ll sacrifice the quality of our work, just that we need to ensure we work smarter, not harder.

Why?

Partly it’s the challenge, partly it’s the prospect of earning some extra money.  Oh, and it could be that the iPhone is one of the coolest toys out there.

So now that you know us so well, what can you expect from this site?  That’s one of the things we’re still figuring out.  So feel free to pop in and see what we’re up to, leave a note, or subscribe to our RSS feed, and we’ll come to you!

In the near future we’ll be putting up details of our plans for world domin… er… great products for the iPhone.