Author Archive

Status update – 20 weeks

July 31st, 2009 Comments off

In my last status update three months ago I said all the technical risks were overcome and I could focus on the actual gameplay. If you have a very limited amount of spare time for your project and find yourself in a similar position, here are a few hints that should help you get on with the task of creating a fun game:

  • Don’t start a blog.
  • Don’t drag out the old junk you wrote a lifetime ago (and which no-one gives a rat’s toss about) in order to provide content for the blog.
  • If you need to write a tool to help you achieve something, stop writing it after a couple of hours when it does what you need, rather than spending a week polishing it up so you can stick it on your blog.

Anyway, after the first month my only real progress (besides the blog) was to get text displayed in my game.

The second month was more interesting. After delving through all my old junk I found another half-finished Amiga game that could work really well on the iPhone. It seemed more achievable than the game I’d already started and the code I’d written could mostly be kept. So I decided to do that one instead.

I’ve come quite far with game number two but have discovered that the ‘fun factor’ is heavily dependent on a lot of variables that will need polishing and balancing over time. So as the third month comes to a close, I have decided to remould game number one into a much smaller project and try to finish that one.

That’s right – Hyperwares currently has several games in the pipeline. We’re a software production powerhouse!

I should mention that I’d still probably be nowhere if I hadn’t gotten a leg-up with writing my OpenGL 2D engine. A chunk of code came from an early tutorial I found at 71 squared. My code has diverged from that tutorial, but I’ll definitely return there in the weeks to come.

Categories: iPhone

Convert a font to a bitmap and an array of rectangles

June 4th, 2009 3 comments

Recently I’ve been working on adding text to my game. It turns out that you hit a few speedbumps when you attempt to add text output to your OpenGL game on the iPhone:

  • OpenGL ES does not have any support for rendering text. Bummer.
  • If you use Core Graphics or Cocoa Touch to draw your text over the top of an OpenGL view, your performance goes down the tubes.
  • If you resort to using Core Graphics, you can only use the inbuilt iPhone fonts. At the time of writing there does not appear to be any easy way for a developer to install new fonts, or even use a font file included in the app’s bundle.

As far as I was concerned, the only respectable approach for a game was to use OpenGL to render the text. The standard approach is to put all the characters from the font into a texture, then render each character of your text as a textured quad. To do this you need to know the rectangle that each character occupies within the texture. If you had an array of these rectangles, you could compute the offset into the array using the ASCII code of the character itself and easily write a little function to draw a text string,  using the rectangle widths to proportionally-space the characters.

I found a funky free font at then started searching for a tool that would produce the texture image and rectangles automatically. There are lots of ad hoc solutions out there but nothing fit the bill exactly.

I wanted my font in a standard bitmapped image format so I could post-process it in Photoshop for gradients, drop-shadows and other effects. This meant that I needed to be able to add user-definable padding space around each character. I also wanted to be able to copy-paste the font characters into the same texture as my other game elements, so my game could avoid a texture-swap operation. And naturally I wanted each character’s bounding rectangle in a form I could easily paste into my Objective C code.

I ended up writing a Windows utility called Font Scraper. It lets you choose a font on your system and produces two files – a nice anti-aliased PNG containing characters in a colour of your choice over a transparent background, and a text file containing the rectangles which is suitable for pasting into a statically-initialized array in C, C++, C# or Objective C. The actual source code that makes use of these resources is left up to you!

Here’s a sample of a suitably game-like font, processed with Font Scraper then tweaked in Photoshop.

I’m aware that proper kerning requires more information than just the bounding rectangle of each character, but I think that’s getting overly complicated for game use. If you need the best-possible rendering, then look at FreeType instead. The rectangles produced by Font Scraper let you display simple proportionally-spaced type in your game.

When you display the string, your code may need to use an appropriate tracking value to increase or decrease the space between characters. For example, if you use an italic or script-like font or you add padding, you will need to reduce your character spacing so that they overlap. Otherwise the characters will appear too far apart.

Unfortunately Font Scraper is for Microsoft Windows only, which I acknowledge might be frustrating when you consider that all iPhone developers have Macs. But I’m a Windows developer and my interest in programming for Apple platforms currently extends only to the iPhone, so now might be the time to check out Bootcamp!

Please leave any comments specific to Font Scraper itself on the Font Scraper download page.

Categories: iPhone, Useful

Croak! The Amphibian Migration Simulation for the Amiga

May 14th, 2009 Comments off
Croak! title screen

Croak! title screen

Croak! was written in 1992 because a friend wanted a decent Amiga version of Frogger. At that point I hadn’t managed to complete anything worthwhile for the Amiga, a machine which had so many other fun ways of wasting your time. Croak! took about a month to write, then I submitted it to Amiga Format magazine, and it took off from there.

If you are unfamiliar with the game concept then here is the synopsis from the readme file:

This program attempts to simulate, as accurately as possible, one of the most fascinating stages in the life-cycle of the Australian Cane Toad. As everyone knows, the eggs of the Cane Toad are laid within the carcasses of dead sheep. In this nutrient-rich environment the tadpoles quickly mature, and soon there are a multitude of young toads ready to begin their famous migration to the nearest creek or river bed. This journey frequently takes them across busy roads, and rivers whose erratic currents and high toxicity defy the bulky toad’s best attempts at swimming.

Croak! gameplay

Croak! gameplay

Croak! was not an exact conversion of Frogger and never tried to be (one reviewer described it as perversion rather than conversion!) The only Frogger I’d ever played was Hoppy for the TRS-80 Model 1. I didn’t even like Frogger and would have preferred to have released a completely original game. I know, however, that the success of Croak! was entirely due to the fact that there was a demand for Frogger on the Amiga. So I’d like to take this opportunity to kiss Konami’s butt and encourage everyone to buy whichever official Frogger they’re selling at the moment.

Croak! was never placed in the public domain. Amiga Format solicited for coverdisk submissions and paid me a token amount for the right to publish it, but that’s as far as it went. So now I officially declare Croak! to be in the public domain and all you people who copied it can finally sleep at night!

If you have an Amiga emulator (or a real Amiga) you can download CROAK.ZIP which containes a bootable ADF file. Make sure you emulate an early Amiga like the A500, or the game will run too fast (as seen in the YouTube video below).

Croak 2

The sequel, Croak 2, was released in 1995, resplendent with magic butterflies, an NTSC mode for the Yanks, spreadable blood stains, less flicker, no speed issues and generally more polish. This time I included a shareware notice.

Croak 2 title screen

Croak 2 title screen

A friend of mine uploaded it to Adam, a local BBS. Two years later it appeared on an Amiga User International coverdisk.  Two very noble individuals have sent me the optional fee. Many thanks to them.

I later discovered it had a bug where the frog was invisible if you launched the game from Workbench on some Amigas (something to do with setpatch?) but it was fine if you booted into it.

If you want to play Croak today, then Croak 2 is the version to get. Download CROAK2.ZIP for the bootable ADF file.

For a bit of fun, I’m going to maintain Croak 2’s status as shareware. Here’s a PayPal button to make it easy for you if you’ve been plagued by guilt all these years.

Read more…

Categories: Retro

Games I made when I was a kid #4 – Yacht

May 8th, 2009 Comments off


This is the penultimate entry in this series of posts. For my final entry I plan to feature the game that made me an international superstar. No really – I actually physically met someone from overseas who knew me from that game. And this was before the Internet took off. But this isn’t that game.

Introducing  Yacht – a Frankenstein’s monster of code that combined BASIC with machine language subroutines and was so difficult that I never even tried getting friends or family to play it.

The sad thing is that this was 1987. That makes me 16 or 17 years old and a first-year university student. It also makes the System-80 totally obsolete! What was I thinking? Well, I was too young for the University Bar…

You pilot your yacht around 9 different courses, adjusting your sail to make best use of the wind. The idea was to angle the sail so that if you imagined the wind bouncing off it, it would bounce behind you. It was actually possible (and frequently necessary) to tack into the wind like a real boat.

If you want to accept the challenge, load the Yacht cassette image into your emulator and follow these instructions:

Read more…

Categories: Retro

Games I made when I was a kid #3 – Stompy

May 8th, 2009 Comments off


“Oh no!” you wail, “not another game he made when he was a kid that no-one played or cared about, and which no-one cares about now either!”

I’ve actually skipped at least ten games, so stop complaining. Stompy (1985) is a lot like the last game I featured, Splatter. The difference is that Splatter was written in Microsoft BASIC and Stompy is 100% Z-80 Assembly Language.

To play it, load the Stompy cassette image in your emulator. Type “SYSTEM”, then type “S”. When the game is loaded, type “/” to run it.

If you’re interested I’d like to tell you how you write a program in Assembler on a 48K Dick Smith System-80 cassette-based system…

Read more…

Categories: Retro

Games I made when I was a kid #2 – Splatter

May 8th, 2009 Comments off


Splatter (1984) is another game I wrote when I was a kid, that no-one ever played.

You are the guy on top of the rows of bricks. The bird-thing is trying to come up to the top. You try to kill the bird by jumping, which dislodges a brick beneath you to hopefully fall on its head. Dislodge too many and you fall through.

As before, if you want to play this you will need a TRS-80 Model 1 emulator and the Splatter cassette image. The game is written in BASIC, you type CLOAD to load it and RUN to run it.

Keep reading if you would like to see what the vintage BASIC source code looks like. I actually went to some effort to de-tokenize it from the cassette image, just for you.

Read more…

Categories: Retro

Games I made when I was a kid #1 – Protector

May 6th, 2009 Comments off


This is the first entry in a series that will showcase games I wrote when I was a kid that no-one ever cared about or played. No-one. Nobody cared what I did alone in my room for hours on end. Maybe they thought I was doing something else. Anyway, I’m not bitter.

This game is called Protector. The guy with the gun is you. The guys with the clubs are harp seal hunters. The things on the right are harp seals. One of them has been clubbed and skinned already…

According to the title screen, this game was made back in January 1984, which would have made me a very disturbed 13 year old environmentalist. To this day I still can’t explain why everyone appears to be wearing clown shoes.

If for some bizarre reason you want to play this, you will need a TRS-80 Model 1 emulator and the Protector cassette image. The game is written in BASIC, you type CLOAD to load it and RUN to run it. That’s as much help as I’m going to give you. I suspect that if you’re into this sort of thing, you’ll really enjoy working out the rest! You’ll certainly enjoy it a lot more than actually playing the game.

Categories: Retro

Reducing your game’s power consumption

May 6th, 2009 Comments off

Battery life is the one major thing I hope improves with the next generation of iPhones and iPod Touches. My wife and I use our Touches almost exclusively for gaming, and nothing sucks juice like my wife playing games. She will typically drain a full battery in one gaming session – we’re talking about less than two hours here.

Don’t tell her, but I’ve just bought her a USB charger for Mother’s Day (no, I’m not married to my mother, but my wife is a mother and she thinks that entitles her to presents from everybody). She can hopefully then just sit in bed plugged in to the mains and stop bugging me to recharge the thing.

So this brings us to the topic of the day. What are the things that we developers can do to reduce battery usage and the carbon footprint of our games? I have three suggestions, and they are all related to frame rate.

1) Use the minimum frame rate that looks good

The iPhone and Touch can update their screens at a maximum of 60 frames a second. So there’s no point going faster than that – give your app little microsleeps. With people, microsleeps can make you feel more refreshed. Conversely, the idea with games is that they will make your screen less refreshed. (Did I just make that lame joke? Slap me!)

Don’t stop there, though. Try running your app at 30 frames a second. If it still looks smooth enough, then cap it there. Your app is now napping for about half the time. Obviously this won’t make the battery last twice as long, but since your game is using the CPU and graphics half as much, this will make a big difference.

2) Don’t draw frames if nothing changed

Suppose we are running our game at 30 FPS. The logic will be updating at this rate, but if nothing is moving or animating then there’s no point compositing the scene again. Give the graphics chip a rest.

3) Use Variable Framerate Technology for Games

The first two suggestions were pretty obvious, but I’m really excited about this one, although its probably only suited to 2D games. Variable Framerate Technology for Games, or VFRG is a cool (IMHO) idea I just came up with.

The basic idea is to dynamically adjust your framerate based on how fast your objects are moving or animating. Some video compression schemes do a similar thing.

Here’s an example:

  • Firstly, work out how smooth you absolutely need your motion to be. Let’s say we are happy to move our objects in 4-pixel jumps.
  • At the top of your game loop, store the current time (accurate to at least milliseconds)
  • After you’ve done all your game logic, find the fastest moving object on screen. Suppose this object is travelling at a speed of 100 pixels per second. Divide this by 4 to get a target rate of 25 FPS.
  • Then find the fastest animating object on screen (assuming a flip-book style of animation). For this example, let’s assume that this object is animating at a speed less than 25FPS, so we won’t consider it. But if it was animating faster, we would increase the target rate accordingly.
  • Divide 1000 by the target rate, to get an update interval of 40 milliseconds in this case.
  • Draw your scene.
  • Using the time you stored earlier and the current time, work out how many milliseconds have passed. Subtract this from 40, and go to sleep for the result (assuming the result is non-negative!).
  • Rinse and repeat.

I’ve got this working with my game at the moment, in conjunction with an upper framerate cap of 30FPS. I have a little overlay display that shows me the number of frames drawn each second, and can see this drop from 30 down to as low as 10 depending on how fast things are moving.

The only area where this all comes unstuck is in responding to user input. For reasons of responsiveness, chances are you don’t want to detect changes in finger position at a rate of 10 times a second or less. You can compensate for this by putting a lower threshold on frame rate (e.g. 15FPS) and perhaps override VFRG and run at your upper rate limit whenever a finger is in contact with the screen.

Now I’m just going to fire up Photoshop and design a funky little green logo for VFRG to stick on my loading screen! I’m only half joking – if you’re smart you can use low battery consumption as a major selling point for your game.

Categories: iPhone, Useful

Status update – 8 weeks

May 5th, 2009 Comments off

It’s been eight weeks since I received my Mac Mini, which is an eternity in iPhone development time – so how far have I progressed since then?

I’ve been developing C++/MFC applications for Windows full-time for 11 years. Two months ago I knew nothing about OSX, Xcode, Objective C, Cocoa Touch and OpenGL ES – all of which I needed to master and which presented a considerable learning curve. I just had to trust that my career had given me the skills and experience to adapt to these technologies. I had also written a successful public domain game for the Amiga way back in 1992. This gave me enough confidence in my abilities to splurge the money on the hardware and start on this journey.

OSX wasn’t hard to adapt to, once Apple’s awful mouse driver was replaced. The inability to easily maximize windows to the entire screen is the worst thing for me. I always work full-screen on Windows and don’t see any benefit to having bits of  junk visible around the edges of the window I’m working in. It’s just distracting and a waste of space. If I need to see two windows at once, I put them on different monitors. Unfortunately I don’t have that luxury on the Mac Mini at the moment.

Xcode seems a bit temperamental and I haven’t fully mastered it yet. But I’m going to go out on a limb and say that Microsoft easily rules the roost when it comes to development tools.

Learning Objective C was kind of like those Magic Eye pictures. I’ve been writing C++ code for fifteen years, but Objective C looked bizarre with its square brackets everywhere. Then after a short while, and crossing my eyes at the screen, suddenly something flipped and it all made sense.

So far all my Cocoa code has been ripped out of demos. You don’t really need much if you’re writing a game.

As for OpenGL ES, I stole enough code from the internet to make a 2D layer on top of it, and now I don’t need to think about it ever again!

I am currently at the point where I have a nice 2D engine which is throwing lots of objects around the screen, colliding and rebounding nicely off walls and each other. The direction of the objects can be altered by swiping with a finger. I also have some nice art assets developed. This is the foundation for a lot of possible games but I don’t want to show my hand just yet.

As far as I can see, the major technical challenges are now out of the way and I can just get on with writing the actual game. Soon it will be time to take some long-service leave from my full-time job and attack this project with all my energy.

Categories: iPhone

How to fix OSX mouse acceleration

May 5th, 2009 Comments off

As a long-time Windows developer new to the Mac, it took all of five seconds before I realized something felt horribly wrong with the mouse on OSX. The pointer would consistently stop short of the spot I was aiming for. As my hand slowed down, the pointer slowed down even faster, making those final few pixels a chore to traverse.

Apparently Apple changed this between OS9 and OSX and there is no official way to configure it more to your liking. I find it really quite amazing that they could screw up the fundamental core of the whole Macintosh user experience and leave it completely busted for numerous revisions since.

Oh dear, this isn’t really setting the right tone. Apple-bashing on an iPhone developer’s blog, in only the second post? I can almost feel the mighty fist of Steve Jobs hovering over me, ready to smite my provisioning profile into tiny pieces and banish me back to the bowels of Windows from whence I came.

To be fair, I’m sure there are lots of people who are happy with the mouse acceleration in OSX. But they’re probably all using trackpads.

For those people who are less than happy, rejoice for help is at hand. And it comes from the most benign and benevolent of sources – Microsoft!

Just download the IntelliPoint driver and make your Mac usable. You don’t need to be using a Microsoft mouse. Thankyou thankyou thankyou Bill!

(See this article at TidBITS for a more detailed analysis and some less optimal solutions)

Categories: Useful