Life changing magazines #3

So, I got this I think around 1985, second hand again. This was very cool though, it showed how to make your own turbo loader! Now I still didn't really understand it at this point, but I was able (with the aid of an amazing tape deck) to make a screen grab load at an amazing 6,000 baud! This is microdrive speed; from a NORMAL tapedeck! It just blasted in! I was also able to load data in via a slightly odd pattern so the screen would come in backwards, and even from both directions at once! Normal spectrum turbos were 3,000Baud (with the original ROM routine at 1,500), so I had great fun fiddling with these routines.

I've still to track down the No.1 magazine. I do still have it, but I've no idea where!

Life changing magazines #2

Yes I know... I'm starting at #2, I need to track down the No.1 magazine. So this one was published when I was just 13, and it had the key equations for doing very basic 3D and perspective. I used these equations for years before real full matrices were possible, but it still holds a special place in my heart. And yes... theres a chunk missing from it. I got it 2nd hand, and someone had sent off for something ripping a big bit out of the article. Fortunately, it wasn't important as I didn't really care about the program, just the method and equations.

ZZap64!

I've just received my original Oli Frey ZZap64 artwork! And I'm pleased as punch! It's from issue 9 of ZZap64 and it's a beauty! It's actually draw at the original size (or very close) to that of the magazine, which I'm astounded at! Normally artists will draw x2 or larger so they can get the detail in, but he hasn't! How the hell did he do that! The detail is amazing on it. I've also discovered I have that magazine, so I'll now get them framed together and it'll take pride of place in my workroom.

I can't wait to see what other ones he'll put up for sale, who would have thought all those years ago I could own an original! Very cool....

You can go buy your very own original at the ZZap superstore: CLICK HERE!

(must now stop using exclamation marks to end every sentence...!)

KISS - Keep it simple, stupid.

I'm a big fan of simple code, probably because anything more complex confuses me and I'll never understand it. This is a hard lesson which I learnt when I was about 15 or 16. I had written a very clever platform routine in assembly on the spectrum. It would draw a Manic Miner level using likes and some king of direction control. However, it was so clever, that after I had written it, debugged it and it was fully working - I had NO idea how it worked. Not a clue. Now, I'll cut myself a little slack here... I was only 15 or so, and had hadn't been doing assembler that long really. Still, I had written it, so I should have understood it! Since then, I've followed the KISS philosophy. Keep it Simple, Stupid. Although the original was apparently Keep it simple and stupid, I prefer the newer interpretation, as you really don't have to be clever to be an engineer these days (particularly a software engineer), and we love to complicate things; so I prefer the insult. If you haven't kept it simple, then you're stupid.

I see this everyday at work, coders who think the latest shiny blog posting about some cool new method is the absolute BEST way to code, and anyone that doesn't is mad! MAD I TELL YA! Well, thats obviously rubbish. If you follow every posting by some new publicity hound, then you're codes going to be terrible, plain and simple. The only real rules for coding is that its got to be clean, readable, fast (enough), maintainable and extendable.

Outside of these simple guidelines, nothing else matters, and it's simple a personal choice. You can throw other things into this mix, like testable, abstracted etc. but these can cloud the code to the extent that its none of the things it should be. I've see code thats been abstracted so much, it's beither readable, fast, maintainable OR extendable. A little abstraction is a good thing, but only when you need it. If you're writing a bit of code for windows, and it's never gonna be moved onto any other platform, then why abstract windows calls? If your going to add value to them (but having them do more, or make the API easier), then thats fine. But never add layers for the sake of them. You should never end up with an API that just passes things through directly unless theres a damn good reason (moving platform it a good reason, as you're wanting to hide the underlying OS calls).

However, desire for coders (especially a novice/junior) to complicate things is pretty high, as is the desire to make a perfect API. Take it from me, thats an impossible dream. You might think it's great, but others will always want something different. The idea is to make an API as good as you can right now, and adapt as time goes on. In the world of professional development, it's all about getting products out the door, not going back over API's trying to make them absolutely perfect. They have to perform the job, and do so with an API that was as good as you could make at the time, otherwise, you'll simply never finish and go bust.

In the end, there's 2 types of coders.... Those that want to get things done and out the door (and this doesn't automatically mean bad code!), and those that want to polish things and write docs, and make things pretty, but ultimately cost you dearly.

Oh...and if you've never seen the second kind, then your one of them!

Designing a good API

So I've been doing some work porting some code to another platform (which I'll speak about later), and it's showing a severe lack of API design. Now I design APIs for a living I thought I'd quickly go over what I think makes a good API, not just from a users point ov view, but internally as well.

Simple and Fast. And we're done. Thanks for reading.

Okay... I'll go into a litte more detail. Now, API's are usually there to give a coder simple access to a more complex system. Take DirectX. The underlying hardware and systems are pretty complex these days, what with interrups, DMA chains dynamic memory management and all the rest of it, yet the API is (reasonably) simple. So... here goes.

Simple. An API must be simple, in fact as simple as you can get away with. This isn't to say you should make it basic, no. You should make it do everything a coder will normally have to do, but don't over complicate it by using 1,000,000 calls for each function. Take DirectX texture creation... Now, whenever I do a graphics engine I have a single CreateTexture() function where as DirectX has several. Textures, Surfaces, DepthBuffers and Cube Maps, the list goes on. Now why? Theres really no reason for that kind of split. You could just as easily use flags and paramaters to allow the various types of selection. This means the coder only has a single function to learn, and if you follow this kind of rule for the whole API, then the entire system becomes much smaller. After all, would you rather a 1,000 call API where you have to set the width and height of a texture indavidually, or 10 functions that can do everything! The smaller the API, the more control you can keep over it. If you give access to every single function and variable, then it becomes a nightmare to change or upgrade.

So, keep an API simple. It's less to maintain, and the programmers that use it will thank you for it.

Speed. This is obvious. It has to be fast. If your management code gets in the way, then the API will become too expensive for coders to use properly, and they'll end up writing support functions themselves. This is really bad. You want the programer to have confidence in the API, not only that it'll do what you say it'll do, but that it won't slow him down. Streamline as much as possible, remove as many if's and but's as you can inside performance critical areas.

Now, a quick word about abstraction. It's important to abstract certain types of API so that it's clean and portable. Now theres a few of reasons for that. First you expect the API to change under you. If your using some open source interface, you never know when the latest buzz word is gonna take hold and your whole API is gonna change, so a simple layer of abstraction will protect you. Next, it will allow you to add value to an underlying API. Take DirectX texture management, if you add a simple layer to your API, you could then now keep track of all your textures, and it'll allow your to manage things like device resets (when you resize the window etc.) as since you own all the texture pointers you can free/reallocate things like render targets automatically. Lastly... Portability. Now most hobby projects don't care about this, but you never know when your project might take off and someone else might want to port it for you to a Mac, or a ZX81...or something.

The program I'm currently working on was hard coded for windows, using not only MFC, but DirectX calls and enums directly. So, being someone that designs APIs, I know all about abstraction. Being someone who's worked on lots of multi-platform games, I know all about how to make an API platform independent. So, thats what I'm doing. All calls to DirectX and being put through a layer of abstraction, each ENUM is being changed to be platform agnostic. This means the API can translate (very quickly) to whatever rendering API I want, without the main application knowing, or caring. The classic case is DirectX and OpenGL. Doing this would allow this program to run on the Mac, without the main program changing. I'd only have to port the (now pretty small) API, and not the whole program.

If you've done your job correctly, you'll have to port a handful of API's. Sound, Graphics, Networking and simples file systems and memory management. All games can be based on these simple API's, and then be made to run on other platforms (reasonably) easily.

Theres obviously lots of ideas for each API. Designing graphics APIs is an art in itself. I've used the same API for the last 10 years. The underlying graphics systems have been PS2, XBox 1, DirectX 8&9 and I know it would work just as well on a PS1, XBox360 (never seen a Ps3 SDK), and DX10/11. A well designed API will work on any platform and be a pleasure to use.

So there you go... Keep an API simple - don't get sucked into the latest fad. Keep if as fast as you possibly can. And abstract to reasonably protect yourself from underlying systems and to allow simple porting.

The good, the bad, the ugly.

I've currently been looking at another code base at work and it's brought to light something I've known for a while, but which is now front and center. Not all programmers are good programmers. It's something which is pretty obvious, but what isn't obvious is the split. You would like to think that it's a pretty linear grade with even numbers of coders at each level, but in fact it's pretty biased towards the lower end and the numbers drop off quickly the higher you go.

Now the games industry is pretty hard to get into in the first place, so truly bad coders in our industry are exceptionally rare. Thats not to say we don't get them (and I think we have a couple in our company to be sure!), but most of our problems are due to the lack of training. We have a heap of juniors on our project and they just haven't been mentored correctly. Now for the most part they're all pretty good (or they wouldn't be there), but without proper mentoring they'll just do it their own way, and not the way they should. Training, and experience is everything, and while it's far easier to churn out decent looking games due to the sheer power of modern hardware, thats not to say that the underlying code couldn't, no shouldn't be far better.

This is much more important than you'd think. In the past you'd write a game and as soon as your finished, you'd hardly ever look at the code base again. That just doesn't happen these days. For starters, engines and tool sets take time to write, so you have to look after them and use them as often as possible. Second, sequals are very common and the turn around on them is usaully very tight, so having a solid codebase to start from is important which means you can't just fudge your game and forget about it. Companies are made on their I.P. and your codebase is a vital part. This means you have to not only value your staff, but make sure you train them as best you can, and I think the games industry as a whole fails in this.

Time marches on...

Wow... what can I say... WOW! As of the 1st of August I've been in the games industry for 20 years. 20 YEARS!! Who would have thought it. My mum said it was a waste of time and I would never amount to anything (okay, she was still right but..), and back then it was such a bedroom industry that you almost knew everyone that ever coded a game. These days, I've never heard of any of them!

*sigh* happy days. We has some great times at DMA, the early days being by far the best - it was just so much fun back then! Thats not to say some of the later days weren't good too, but hardware is just so boring these days - powerful, but boring. Just about anyone and his dog can make a reasonable game now, and that takes away much of the art that you needed to do really cool things.

I did a little test at work recently and was able to draw 1,000,000 lemmings faster than we could draw 100 on the Amiga. 1,000,000!!! That covers a 1280x1024 screen 195 times over!! or to put it another way, imagine a SNES with 3,900 parallax playfields, and STILL have enough grunt to draw 1,600 sprites! Amazing power. But what do we do with it? CPU's are now so powerful, it's like having over 500 SNES per CPU - and I have 4 cores on my machine!

So much has changed, and a little of the fun has gone. Now and then you get some of it back, a little bit of fun optimisation still brings a tear to eye as you remember the fun you used to have pouring over a few lines of assembler while trying to get a single cycle off. I sit and watch all these new boys, and shudder at the waste in their coding, memory, cpu power, disk space, network bandwidth... all of it. They don't seem to spend as much time thinking about these things as we old timers do, and the sad thing is, they probably don't have to. Sure a little more care would work wonders, but CPU's are actually made to help average coders. Thats a sad fact of life, the world is full of average or less than average coders, so all the clever folk at Intel, AMD, ARM all work away to make things run faster for them. but this leaves the few of us left struggling to find the fun we lost.

Still, it's not all bad. Some new hardware is always around the corner, and your mobile phone is now more powerful than even the old consoles. Look at the iPhone. Really nice bit of kit, and fun to code for. Languages have changed too, and I've (almost) given up assembler for the likes of C# as it's just faster to work in. I've had some hard leassons to learn here though, giving up memory management is still a sore point but it does make life simpler for most tasks, but I really miss knowing where every byte of my program has gone.

It's sad I guess. I'm a man stuck in the past. On the one hand, I'm trying to hold on to the fun I had in the very first days of coding, while on the other, I try to use all this new power as best I can, and teach these new boys thing or two while I'm at it. It's now all about bridging my experiance, learning from the past to bring forward old ideas and use them in new contexts.


So will I be here in another 20 years? Who knows... I suspect I'll still be coding in some shape or form. It still has the same lure as it did when I first sat down in front of a ZX81 and black and white portable TV as a 13 year all those moons ago. But what will change in the next 20 years? or even the next 10? More CPU cores I guess, bigger badder machines, easier to program and just perhaps, a little more fun.

Lets hope...



Anyway, heres some of my career highlights I've enjoyed...

• 1989 - Ballistix is released - My first game!
  
• 1990 - Blood Money on the C64 is released.
  
• 1991 - Lemmings
  
• 1994 - Lemmings 2 SNES
  
• 1994 - Uniracers
  
• 1995 - Writing various prototypes and trying out several game ideas.
  
• 1996 - Minus4, my first emulator!
  
• 1997 - GTA, particually the 3Dfx version.
  
• 1999 - GTA 2
  
• 1999 - I left DMA and moved to Visual Sciences at Head of Reasearch and Development.
  
• 1999 - XeO3, a small on going project begins...(still not finished!)
  
• 2000 - Internal debugger for the PS1 based on an Action replay, along with some fun on the PS2.
  
• 2000 - F1 2000 on the PS1
  
• 2001 - F1 2001 on the XBOX
  
• 2001 - I left Visual Sciences and moved to Simian Industries as Technical Manager.
  
• 2005 - Moved to Realtime Worlds after Simian went poop to prototype some ideas.
  
• 2005 - Various tech demos for an undisclosed project.
  
• 2006 - Russ joined me at RTW and my project team doubled in size.
  
• 2006 - Actually started to use C# in anger.
  
• 2006 - Huge scale tech demo. Great fun.
  
• 2008 - Rewrite and an even bigger scale demo - pretty cool.
  

Delphi conversion

So, I'm doing a little Delphi conversion just now and while looking through the code I came over a little bit which didn't quite make sense. Rounding floating point numbers into integers. Now my default has always been to truncate for rounding. Not only is it faster (by far!) but it's easy to predict, and everyone understands it. Now, Delphi's rounding...wow... it's nuts!

Dephi seem to have gone out of their way to complicate things, and I can't figure out why. Anyway, after doing a quick search heres the Delphi rules...

The Round function rounds a floating point Number to an Integer value.
The rounding uses Bankers rules, where an exact half value causes a rounding to an even number:

12.4 rounds to 12
12.5 rounds to 12 // Round down to even
12.6 rounds to 13

13.4 rounds to 13
13.5 rounds to 14 // Round up to even
13.6 rounds to 14

Now...why o WHY would you do that.... Round .5 to EVEN! What! Nuts I tellz ya...

Editor woes

You know its amazing how fast you can do an editor if your not trying to be fancy. Take RetroEdit. It's actually trying too hard to be the jack of all trades, and as a result, its currently the jack of none. This isn't to say it won't eventually work and do its job, but currently because its trying to hard, its progressing slowly.

Now, take a look at a little map editor I'm currently knocking up for my little iPhone Golf game. I'm not trying to make it a generic editor, and I dont want to reuse it later (not that I couldn't hack it into something else later mind). But this means Im free to throw code in at a great rate of knots and as a result, within a day (almost) I've just about finished the basic editor. It's got a tile window, brush support (grabing multiple tiles at once), and I'll add a quick UNDO function in there for when Im being stupid.

It's amazing how quick you can do these things when your being specific, and I do wonder sometimes if the tools I try and do at home are being too ambitious and as a result might never get finished... hay-ho...

iPhone fun...

Yeah, I know... long time again. I've started doing some iPhone coding to see if I can actually finish a (proper) game at home. Doing games programming at work, then games programming at home is hard going. Doing the same thing all day, then coming back home and doing it all again is a little soul destroying. However, I'd like to try and give it another go, and who knows.... perhaps make a little cash on the side.

So, XeO3 will (yet again) take a back seat for a while so I can see if I can make a real go of this stuff.

On the plus side, I've been doing some OpenGL at work, and it's putting me in good stead for doing some at home! I now know a reasonable amount about it so should be able to use the iPhone's OpenGL ES reasonably easily..

Well, here goes nothing....