Acorn Heroes

We’re currently prototyping some ideas for our next game. This time round we’re looking to do something fun with light and dark. Unfortunately the fixed OpenGL pipeline has a fairly standard look to it, and we can’t move to using shaders in OpenGL 2 without alienating a large number of people (including ourselves – our personal devices are both iPod Touches).

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!

One of the weirdest / hardest things to do when starting iPhone development is setting up the connection between your development machine and your iPhone / iPod Touch (known as provisioning).  I’ve done it once, but it’s fair to say it happened in a blur and I was following instructions fairly blindly.

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.

For some time I’ve been wanting to set up unit testing as a part of my iPhone development process. Being mainly a Visual Studio developer, I’ve yet to learn all the ins and outs of XCode and GCC projects, so it seemed like a good chance to learn more.  There are a number of tools available.  I was keen to try out UnitTest++ by Noel Llopis and Charles Nicholson, as it is a) light weight, and b) designed for use with C++, which a large portion of our code will be. Noel has several articles about unit testing that I’d recommend reading.

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.

There’s one type of system that’s present in almost all games, and yet has very little functional value. It’s pure bling. I’m talking about particle systems and, when well designed, they can add greatly to the character and style of a game. When implemented well, a particle system can be applied to a wide variety of effects – rain, fire, explosions, blood, splashes, smoke and even some that might not be so obvious, such as grass or footprints.

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…

As we’ve been setting up this company, a lot of thought has gone into how and when we need to do things so that we can maximise the (spare) time we have to devote to it.  We wanted to enrol in the developer program as a company, rather than as individuals, so we set up the company first.  Then came the part we were a bit worried about.  Searching the web, you find plenty of stories of one or two month waiting times to become enrolled on the program.

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.

*Update* Brandon Mantzey very kindly pointed out a glaring bug in the code accompanying this post… Never fear, I’ve tracked down the idiot responsible (me), and it’s all good now. The bug was actually two bugs – first I was confusing the width in pixels of a character’s texture and the space it takes on screen. Secondly I was working from the bottom left corner of a string, where as I should have been working from the top left. Thanks Brandon for encouraging me to fix this! The link in the paragraph below now has the updated code.

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.
(continue reading…)

There’s a bunch of ideas for posts mulling around in my head, but perhaps the best place to begin is, as they say, at the beginning.  So here’s a quick introduction.

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!

Welcome to Acorn Heroes!  There’s not much to see here for now, we’re just getting set up.  In fact, if you’re here reading this, you’re probably either a friend or family.

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