Sledgenet.co.uk

“Why are you only writing games for iPhone and not for Xbox too?”

It’s a good question that my friend asked me recently and I really didn’t have a similarly good answer, so having recently got my bearings with C++ I thought it’d be worth skipping swiftly onto C#. And while I’m only a coupla days into my faffery with XNA, I’ve noticed some interesting things about how, lately, my coding style has… well, regressed!

For example, a year or so ago I would’ve told you that lists are The Answer. Coming from a Blitz background I naturally tended towards solving everything that possibly could be solved with doubly-linked lists with the lovely lil’ buggers. The thing is, once you move into the mobile realm, object persistence becomes really important because instantiation is so costly. On iPhone you’ve also got to contend with the fact that garbage collection is half-arsed (the worst kind of arsed) so that, as well as taking time, object creation and deletion is FRAUGHT WITH DANGER. The sensible developer, therefore, soon realises that creating a pool of objects at start-up and leaving it the hell alone until the application terminates allows one to avoid a whole minefield of performance issues.

Of course this begs the question “If you’re not going to take advantage of the flexibility of linked lists, and given that modern arrays can contain objects, why not just use arrays. Like in the eighties?” And while the issue is kinda moot under Cocoa Touch (because arrays and lists are conceptually merged into the NSMutableArray) it is a consideration that I have brought back with me to the desktop: The particle system in Vaders, for example, eschews dynamic object creation/destruction in favour of a persistent linked list with newly assigned particles being split to the back of the list — this could well be a memory-management nightmare for STL under the hood and therefore wholly inappropriate for mobile devices, but it was hella simple to code! Porting the game to XNA I’ve gone back to arrays completely, with each entry maintaining a reference to the next and the element considered “first” traversing the circle as each particle is activated. It was a bit more work than list-splitting, but offers a pretty much ideal combination of persistence and utility.

And sometimes I just sit, look at my code and go: “Fixed size arrays? In 2010? Really?!”

But yes, don’t be embarrassed. If it works, it’s right. We really don’t have to use swanky language features if they aren’t necessary and carry unwanted baggage (which the Xbox garbage collector kinda does). This is a philosophy which I have resigned myself to wholesale where the particle system is concerned. Leaving the specific collection class aside, I had actually planned to write The Mother Of All Particle Systems for VadersXNA because, on the surface, this seems like an ideal area to apply modern language features like inheritance and generics.

Only it’s not. Not necessarily.

The thing is, explosions aren’t fire and fires aren’t smoke and smoke isn’t fireworks. Not remotely. While you might think a particle is a particle is a particle, the members and therefore parameters required by different kinds of efficient particle vary wildly. So much, in fact, that expressing them in terms of an extended common class, to a generics noob, is far from trivial compared to simply duplicating an existing class and editing it to taste. So, each kind of particle in VadersXNA is its own distinct class and, yes, that is something that will have OOP aficionados clutching at their chests in horror… but y’know what? It’s performant, fast to implement, easy to maintain and it works.

As a kid I remember an L-Cars comic strip where one of the characters had constructed a massive, warehouse-filling machine. He sat casually in front of the behemoth, fag in mouth (hey, different times!), tapped a foot-pedal and — click! — it lit his cigarette. Sometimes, with modern programming languages, we create complex solutions for problems that really aren’t worthy of them. Here’s to matches!

Daft lil’ Space Invaders-alike that I wrote while trying to wrap my noggin around C++ (I’m proudly at the “It’s C with classes!” level at the moment and I think I’ll be here a while.) Check it out in The ComPile.

…learning C++! Of course when I say “learning C++” what I really mean is “learning to express the OOP principles I’m already familiar with in C++’s parlance”, so it’s not like I’ve gone from zero to a working knowledge in seven wee evenings. We’re also talking games development, which essentially amounts to defining object classes and populating linked-lists with them (and not much else), and having such a narrow remit certainly helps. In fact the hardest thing, by far, was getting a working development environment up and running in the first place: Visual Studio is superlative, but I wanted C++ not C++.net; DevC++ throws a wobbler if you have a prior MinGW installation (which I do, for compiling BlitzMax modules) and there are an overwhelming selection of DevPaks for SDL and Allegro (because I wasn’t going to learn C++ writing console apps); Code::Blocks looks lovely but its project wizards are confused by just about every library you direct them towards, never being able to locate the required files. It’s a good job I don’t have any hair!

So, for the similarly inclined, I’m going to quickly outline what I went with because trawling through the available options ended up being a couple of grim days’ work. Here we go:

www.cprogramming.com: For actually learning the language, this place is pretty good with straightforward, easy to follow examples. Again, this is from the perspective of learning the lingo rather than the concepts — personally I wouldn’t actually want to try to grasp OOP via C++ (I’d opt for something higher-level, like BlitzMax) but YMMV.

iMiniB3D: It was the example source code that comes with iMiniB3D that gave me an idea of what clean, sensible C++ looks like. Even if you’re not interested in iPhone development, it’s worth a squiz.

Code::Blocks: Sure, the project wizards for SDL, Ogre and whatnot are squiffy, but as I wound up going with a different media library with a manual setup (see below) it ended up not mattering. It’s a really sweet editor.

SFML: Simple and Fast Multimedia Library is an SDL/Allegro-alike that is just exceedingly clean. You’ll notice I’ve linked directly to the Code::Blocks/MinGW setup tutorial — take the fact that it needs a particular version of MinGW seriously because, from (bitter, bitter) experience, it won’t work otherwise. I would recommend using Search Directories for library installation rather than copying files (in fact your Code::Blocks directory won’t even resemble the one in the tutorial).

irrKlang: Cleaner than BASS and supporting more formats than SFML’s equivalent, irrKlang is a thoroughly decent choice for audio. It will load files from MoleBox packages (which I couldn’t get BASS to handle) and the license allows you to compress the dll (which will UPX to about 200k).

The above should be all you need to get going and write, say, an example little game such as, ooooooh, some sort of Space Invaders clone?

I’ll upload that to the ComPile once I’ve finished writing a lil’ tunelet for it (EDIT: Voila!), but we’re not quite done with the links yet! One of the nice things about SFML is that your window is already an OpenGL context, so it’s an excellent springboard for leaning raw OpenGL (indeed you can even go mySFMLImage.Bind() to bind a texture, and that’s on top of the delight of having SFML’s image laoders). Now there’s a school of thought that says you should no longer learn fixed-function OpenGL but, as I’m specifically interested in OpenGL ES (and therefore iPhone) compatible code, I didn’t pay that advice any heed. Bearing that in mind, I found the following places useful:

Zeus CMD: Nice set of tutorials specifically aimed at OpenGL ES. You’ll have to amend the code a bit to get things running under SFML (‘glOrthof’ becomes ‘glOrtho’, for example, and there is no ‘gluLookAtf’ out of the box) but that’s half the fun, right? RIGHT?!

The Game Programming Wiki: A comprehensive set of tutorials (and links to other sites) with some very useful 2D framework code.

Have fun!