• 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.

• 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 dafont.com 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.

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! 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

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.

Croak Links

Having only recently discovered the extent of Croak’s presence on the net, my head is still spinning somewhat (and is appreciably larger too).

Croak 2 gameplay

• Here’s a description and some reviews of Croak! over at Lemon Amiga.
• Here’s Croak! listed at the Hall of Light. Here’s the listing for Croak 2.
• Here’s Croak 2 at Aminet.
• I’m flattered that somebody called Syndicate has actually created a clone of Croak! using Flash. It’s not exactly the same, but you can play it online right now (it’s everywhere). The graphics and sounds are mine, but for some reason the turtles are from Frogger and the frog has shrunk. The title screen music demonstrates quite effectively why the original Croak! didn’t have any.
• See this thread where bippym has managed to fix the speed and invisible frog issues when running on a real Amiga, using something called WHDLOAD.

Croak in the Media

Firstly I would like to express my extreme gratitude to all those over at the Amiga Magazine Rack. Until a week ago I knew that Croak! had been featured in six magazines. I had no idea that the count was almost double that!

Amiga Format 35 - can you spot Croak?

• Croak! first appeared in June 1992 in Amiga Format, Issue 35 (page 8) after I personally submitted it to them. It was included on the coverdisk and you can see it on the front cover too. They paid me something like forty pounds for the right to publish it (after I sent them a friendly reminder). From there, the ball really started rolling…
• It was next picked up in September 1992 by The One Amiga, Issue 48 (page 9). Croak! is on coverdisk two and you can see a bit of it on the front cover. They said: “Yes, it’s Frogger!  And not just any old Frogger.  We reckon it’s the best Amiga version of the classic arcade game yet.”
• The same month it was reviewed in Amiga Power, Issue 17 (page 83). “Croak is a polished version of the game. The controls are very positive so that you can wait quite happily until the very last second to make a jump if needs be. It also shifts at a fair old rate which is essential to make playing this type of game worthwhile.” … “As Frogger clones go this is first rate, but do we really need another one?”
• The October 1994 editions of Amiga Format and The One Amiga both mentioned Croak in their reviews of the Golden Oldies 2 PD compilation, the latter describing it as a “superb Frogger clone”.
• In January 1994 it was gushingly reviewed by Australian Commodore and Amiga Review, Vol 11 No 1. “Apart from the fact that it’s flawlessly programmed, the best thing about Croak is the simultaneous two-player mode, that transforms the game into a vicious contest for homes and bonuses.” Their effusive praise might have something to do with the fact they were trying to flog it on a disk for five bucks.
• In April 1994 Croak! appeared on a coverdisk attached to Amiga User International Vol 8 No 3 (page 10). “Amphibian fun for everyone!”
• In June 1994 it was included on the coverdisk of a French magazine Amiga Dream Issue 8. There are no scans available but it was on page 7.
• Croak! was reviewed again in August 1994 by the The One, Issue 71 (page 105). The reviewer was obviously a different person this time around: “Sadly, this isn’t so much conversion as perversion, as Croak does little to duplicate the original Frogger other than capture its playability. The sounds are new and the dinky tunes that enhanced the original have gone. All that said, this still remains one of the more fun copies of an ageless classic.”
• In October 1994, Amiga CD32 Gamer, Issue 5 (page 6) said “Everyone loves a good Frogger clone!”. They included Croak! on their CD. A shame that it runs at twice normal speed on a CD32!
• Croak 2 got its day in the sun in April 1997 when it was included on a coverdisk (The Great AUI Games Disk No. 1) attached to Amiga User International Vol 11 No 4 (page 10). On this occasion I was sent a note of congratulations and a copy of the magazine!
• And finally, Croak 2 was included on the coverdisk for Amiga Format, Issue 127 (page 82). The article’s author might have licked one-too-many cane toads though, because he mentions snakes, alligators and otters, none of which are in the game!

Leaving the 20th century behind, I was delighted to find Croak! on YouTube. The emulator is obviously running way too fast, but who cares!

Croak Trivia

(As if most of the above wasn’t trivial!)

Victory!

• When Croak! starts, the subliminal message “Kate Bush is God - she really is!” can sometimes be seen briefly at the top of the screen. I have since come to accept that this statement probably isn’t wholly true.
• To croak, of course, is to die. Add an exclamation point and it becomes a command. Quite a violent title, really. When you die, you leave a persistent blood stain on the road that later frogs can slip on. There are no less than ten different blood splatter images.
• Croak was written in C on a 2MB Amiga 1000 with Phoenix replacement motherboard and 52MB Quantum Fireball hard disk.
• The chicken and crow impersonations were made by me with a microphone and a digitizer. I can’t remember where I stole the croaking sound from.
• The blood in Croak 2 is smearable. With a little effort, you can cover the whole road in blood. For a family game, I probably should have made the blood green.
• There is a chicken on the other side of the road because a snake would be too wide to fit into a single sprite. It also makes a lot of sense to have a chicken on the other side of the road.
• The original game runs flat-out which is why it is too fast on Amigas with a clock speed greater than 7.14MHz. It doesn’t use double-buffering, so it flickers a fair bit.
• Croak 2 works out how far to move each row of cars or logs based on how much time has passed since the last move, so it runs at the same speed on all Amigas and smoother on faster ones. Flicker is almost eliminated by waiting until the raster beam has moved beyond each row before moving it.

The Butterfly Effect

These are the effects of the various butterflies in Croak 2. Persistent effects last until the next butterfly is caught or disappears off the bottom of the screen.

• White gives you an extra frog
• Pink awards 500 points
• Red slows you down
• Green speeds you up
• Purple kills you
• Cyan freezes the traffic
• Magenta slows the traffic and river
• Yellow speeds up the traffic and river

Yacht

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:

You need to load the BASIC part first, then the machine language above it. They are both on the same tape.

1. Reset the machine and set memory size to 28000.
2. CLOAD the BASIC component.
3. Load the machine language component with SYSTEM (Enter) Y (Enter)
4. Hit BREAK (Esc) at the second *?
5. RUN

Are you seriously reading this…?

There are so many other games I could have featured from those days. Bricky Drop, Captain Bunny and Dancing Selly to name a few.  For now, they are merely names whispered through the intertubes. Maybe one day I’ll cave to the inevitable popular demand and show you them…

Stompy

“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…

1. Insert cassette containing the Editor/Assembler program. Wait a couple of minutes for it to load, nursing the volume control to keep the meter in the yellow zone. If it loaded without a checksum error then run it.
2. Insert cassette containing your source code. Wait a couple of minutes for it to load. All the time keep praying that your code will actually load, and isn’t gone forever.
3. Make your changes in the editor.
4. Save your source code to tape (another couple of minutes). Don’t use the same tape, you idiot. Multiple copies, multiple copies…
5. Assemble your code.
6. Save the assembled machine language to tape (another couple of minutes). Wait.. that’s not the tape you just saved the code on is it? Arghhhh!
7. Reset the computer.
8. Load your machine code from tape (another couple of minutes)
9. Run your program and try to work out from the quick flash of garbage on the screen what went wrong.
10. Reset the computer.
11. Insert cassete containing the Editor/Assembler program…

Needless to say, you want to minimize the number of build cycles. That’s why I wrote the code for the entire game in a notebook first. It is a matter of some pride to me that it almost worked first time.

Ahhh, the Dick Smith System-80 Blue Label edition. Lower-case characters! Inbuilt cassette with volume control! Woodgrain side panels! This was the greatest of all TRS-80 Model 1 clones. You youngsters today have no idea. I’m actually starting to get a little teary. How I loved that machine. No kidding, I’m actually sitting here starting to cry.

Splatter

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.

Back then, whitespace and comments ate precious memory, so you didn’t use them. Statements were combined on the same line for speed, and lines at the start of the program ran faster. Your screen showed 16 lines of 64 characters, and you only had a line editor because a full-screen editor wouldn’t have fitted into your ROM.

People actually bought magazines containing source code like this, and typed it in themselves! This was a great way to learn programming, because if you typed a single character wrong, you had to work out where it was.

Somewhat embarassingly, this code reveals that Hyperwares used to be called SellySoft. It’s generally a bad idea to name a company after something your mother calls you, even an imaginary company.

1 ' SPLATTER - BY SELWYN STEVENS
10 CLEAR:CLS:PRINT@(6,19),"SELLYSOFT INC PRESENTS..."
20 DATA28,28,28,28,28,28,28,28,28,28,28,28,28,28,28,28,28,28,28,
60,76,76,44,28,52,91,90,89,91,64,60,86,51,71,81,44,44,84,72,56,8
0,60,30,75,91,91,59,29,30,31,29,30,31,29,64,60,72,56,44,52,28,39
,59,75,35,28,28,60,72,56,44,28,52,39,59,75,35,64
30 FORA=0TO2:FORD=1TO3:FORB=1TO6:READC:M$(A)=M$(A)+CHR$(100+C):N
EXT:IFD<3M$(A)=M$(A)+CHR$(26)+STRING$(6,24):NEXTD,A:ELSENEXTD,A
35 B$(0)=LEFT$(M$(0),26)
37 C$(1)="KEEP SPLATTING, YOU ARE LOOKING GOOD!":C$(2)="LOOK OUT
, THIS GUY IS HOT!!":C$(3)="BRILLIANT!!! (JUST HANG IN THERE)"
40 FORA=1TO2:FORD=1TO2:FORB=1TO6:READC:B$(A)=B$(A)+CHR$(100+C):N
EXT:IFD=1B$(A)=B$(A)+CHR$(26)+STRING$(6,24):NEXTD,A:ELSENEXTD,A
42 FORB=16446TO16474:READD:POKEB,D:NEXT:POKE16526,62:POKE16527,6
4:DATA205,127,10,62,1,14,0,237,91,61,64,69,47,230,3,179,211,255,
13,40,4,16,246,24,242,37,32,241,201
45 GOTO1100
50 IFNK>20THENGOSUB2000
52 FORA=258TO390STEP64:PRINT@A,STRING$(60,191):NEXT:PRINT@(15,2)
,STRING$(60,191);
60 BP=864:BX=6
70 FORA=1TO2:PRINT@P,M$(1);:PRINT@BP,B$(A);:Z=PEEK(14400):IFZ=32
ANDP>66THENPRINT@P,M$(0);:P=P-6:ELSEIFZ=64ANDP<118THENPRINT@P,M$
(0);:P=P+6:ELSEIFZ=1ORINKEY$=" "THEN200
80 Z=RND(10):IFZ=1ANDBX>1ORZ=7ANDBX>1PRINT@BP,B$(0);:BP=BP-6:BX=
BX-1:ELSEIFZ=2ANDBX<10ORZ=8ANDBX<10PRINT@BP,B$(0);:BP=BP+6:BX=BX
+1:ELSEIFZ=3ANDBP<832THENPRINT@BP,B$(0);:BP=BP+64:ELSEIFZ=5ORZ=6
PRINT@BP,B$(0);:BP=BP-64:IFBP<192THEN300
90 IFPEEK(P+15552)<>191THENFORD=PTO830STEP64:PRINT@BP,B$(1);:Q=U
SR(880+INT(D/20)):PRINT@D,M$(2);:PRINT@BP,B$(2);:PRINT@D,M$(0);:
NEXT:GOTO500:ELSENEXTA:GOTO70
200 PRINT@P,M$(2);:FORD=1TO10:Q=USR(900+RND(20)):NEXT:PRINT@P,M$
(1);:IFPEEK(P+15680)=191Y=P+320:GOTO210:ELSEIFPEEK(P+15616)=191Y
=P+256:GOTO210:ELSEFORD=PTO830STEP64:Q=USR(880+INT(D/20)):PRINT@
BP,B$(1);:PRINT@D,M$(2);:PRINT@D+192,STRING$(6,191);
205 PRINT@BP,B$(2);:PRINT@D,M$(0);:NEXT:GOTO500
210 FORD=YTO959STEP64:PRINT@D,STRING$(6,191);:IFPEEK(BP+15360)=1
91THEN600:ELSEQ=USR(1100+INT(D/20)):PRINT@D," ";:NEXTD:GOTO70
300 PRINT@BP-64,"HOORAY";:FORA=1TO20:PRINT@BP,B$(1);:FORB=1TO30:
NEXT:PRINT@BP,B$(2);:FORB=1TO30:NEXT:NEXT:GOTO1000
500 PRINT@D,"SHPLAT";:PRINT@D+64,STRING$(2,176)STRING$(2,188)STR
ING$(2,176);:PRINT@D+128,STRING$(6,191);:FORJ=1TO25STEP2:Q=USR(9
40+J):NEXT:GOTO1000
600 PRINT@D,STRING$(6,191);:PRINT@D+64,"CRUNCH";:NK=NK+1:PRINT@(
0,60),NK;:FORE=1TO5:Q=USR(985-RND(20)):NEXT:PRINT@D,B$(0);:IFNK=
KNTHENKA=KA+1:KN=KN+KA:PRINT@(0,60),NK;:GOTO50:ELSE60
1000 PRINT@(8,19),"YOU LOSE. YOUR SCORE:"NK;:Q=USR(150):Q=USR(20
0)
1005 IFNK>HSTHENHS=NK
1100 CLS:T$="<<< SPLATTER - HIGH SCORE:"+STR$(HS)+" - HIT 'S' TO
 START ":FORA=504TO451STEP-2:Q=USR(990):FORB=1TO2:PRINT@A,B$(B)L
EFT$(T$,504-A);:PRINT@A-6," ";:PRINT@A+6," ";:FORC=1TO4:IFINKEY$
<>"S"THENNEXTC,B,A:FORA=1TO5000:IFINKEY$<>"S"THENNEXT:GOTO1100
1110 P=66:NK=0:KN=4:KA=4:NC=0:CLS:GOTO50
2000 IFNK>48THEN2010:ELSENC=NC+1:CLS:PRINT@(7,32)-LEN(C$(NC))/2,
C$(NC);:PRINT@(8,20),"YOU ONLY NEED"49-NK"MORE!!";:FORA=1TO50:FO
RB=1TO2:X=USR(950):PRINT@(7,5),B$(B);:PRINT@(7,52),B$(B);:FORC=1
TO10:NEXTC,B,A:CLS:RETURN
2010 Y$="":U$="*CHAMPION* ":FORA=1TO6:Y$=Y$+U$:NEXTA:CLS:PRINT@(
7,17),"C O N G R A T U L A T I O N S !";:PRINT@(8,13),"YOU ARE T
HE GREATEST SPLATTERER EVER!!!";
2020 FORV=1TO50:FORA=1TO13STEP3:PRINT@(5,0),MID$(Y$,A,64);:PRINT
@(10,0),MID$(Y$,A,64);:FORB=1TO2:PRINT@(6,1),M$(B);:PRINT@(6,57),
M$(B);:X=USR(800+RND(200)):NEXTB,A,V:GOTO1005

Protector

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.

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.

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.

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)