I’m waiting for some fun pieces of hardware to be delivered. I’ve ordered a1 gig CF card for my digital camera, a Max Media Launcher and a GBA Movie Player.

The CF card goes in my camera, the old CF card goes in the GBA Movie Player which goes into my Nintendo DS. The Max Media Launcher also goes into my DS. Code I write goes on my CF card and the Media Launcher makes my DS run it. Of course first I need to “update” the firmware in the GBAMP first so this works.

Nothing like a simple way to write software, is there? I like the way these separate pieces of hardware can be combined, slightly modified and end up with something that’ll make my DS run Linux.

As you may have realised from the mass of status messages, Shooty has been finished

For my next effort I think I’ll try a nice puzzle game. I discovered Ishido the other day and really like the way you have to match either shapes or colours.

I’m going to re-learn SDL I think, get something working on that and then attempt to port it to my Zodiac. Zodiac dev looks quite fun, but so far all the useful things involve CodeWarrior, nothing seems to work with GCC. This is a major pain in the arse. I’ll probably end up writing a PalmOS application that doesn’t use any of the fancy Tapwave extensions.

This sucks. I registered as a Tapwave developer, downloaded their top secret SDK and now it won’t work with my compiler

Lots of sound. Everything that happens causes some sort of sound to be made. So if you die, kill something, something tries to kill you, or you just bounce off something you’ll hear a suitable sound.

Apart from a few bugs with the particles code and the small problem that you can create bullets that don’t move, all is going well.

Finally, after a year of farting around with the code, learning new things and getting confused, I have something to release.

Now, because it’s a pain in the bum uploading files to my website, you can grab the code from Llamasoft’s Programming forum.

I am now officially entering “eye candy” mode. The game is complete. It just needs to look nice now. That’s where vectors, particles and some non-trig come in. I need to cook up a text-on-demand display routine that I can explode on the screen. I’ve got bags of ROM space left for the graphics, and I think there’s enough RAM for the scratch space I’ll need.

And when this game reaches a certain point, I’ll fork the code off and begin something new. The vectors stuff is going to get OpenGL bolted onto it and thrown around my PC’s screen. Not having to think in fixed-point maths will be a nice luxury

www.yakyak.org/download.php?id=5378

Just got the Robotron-style effect working in Shooty. Runs at a nice speed too I discovered that if I turn off the screen-erasing every frame the explosion looks rather cool. Once I work out how to clear the screen pixel-by-pixel, erasing only the ones I draw, the effect will have several different modes - vertical Robotron style, horizontal Robotron style, Defender ‘explode into an expanding shape’ style, and whatever you get when not bothering to remove pixels in the above. If I can control the erasing properly the sprite should ’smear’ across the screen then dissolve from the middle outwards.

Once I’ve got the game running at a playable speed (it goes wild when I turn on compiler optimisations!) and a few weirdo bits have been fixed, I’ll release a test version to the World

The baddie AI is complete, I have a system to create new levels, and there are some sound effects in there somewhere. The game is almost complete. All I’m doing now is adding flashy effects and checking there’s no gaping holes in the code. The mess that was the player’s control code has been rewritten, as has all the baddie AI.

The sprite library I’ve been writing at the same time is working very nicely. Since it just keeps track of what sprites exist and where they are, it doesn’t add much overhead to the running code.

Once the game is playable and there aren’t too many bugs left, I’ll start something new. Something tile-based I think. I can then repair Shooty and add extra polish as time goes on.

Hmm… discovered an interesting bug in Shooty - it contains more than 32 16×16 sprites. Due to various things inside the GBA, if you want to use 256 colour, 16×16 sprites then you can only have the graphics for 32 different sprites in VRAM at once. I have 47 which makes the GBA go a little strange and dump random cack on its display.

After boggling my mind with sprite multiplexing systems, I decided to see if there was an easier method. After stripping out blank sprites, and chopping some that I can do without there were still too many. However… a few of the sprites are only 8×8, meaning they were taking up a whole 16×16 sprite space. If I combined four 8×8 sprites they fit in the same space as one 16×16 sprite (obviously).

And now my sprite library has been suitably modified and can cope with either 8×8 sprites, 16×16 sprites, or a mixture of either. It’s all very tidy and understandable too.

I can now return to the re-writing of the game’s main loop which is also kicking a few random bugs in the teeth as I go along.

Today was the first day of my Powerboat Instructor course. The second day is tomorrow, then there’s a month gap (during which I do my ML assessment) before the next two days. I need to remember how to read a synoptic weather chart since part of my ML is to produce a 12 hour forecast from one.

Oh, and I’m recompiling KDE in an attempt at stopping something X-related from locking up at daft times. It seems to happen when XMMS loads, however I’ve reinstalled XMMS, swapped soundcards incase it was the driver, and disabled any weird XMMS plugins I might have collected.

Writing software is a strange thing. It’s both constructive and destructive - constructive since you’re making something, and destructive because occasionally you decide the way you’ve done something isn’t quite right and just can’t be fudged any more. The destructive part sounds a bit of a waste of time, but it’s actually quite important.

The level management code in Shooty is a right mess that I just stuck together to get something on the screen to shoot at. It let me work out various things such as baddie AI, control systems, sound and sprites. Now that I’ve actually had The Vision (i.e I know what the game is going to be now, it’s nolonger a pointless ’shoot the moving things’), the stuff I’ve written so far needs a slight tweak. Had I not spent this time playing with sprites, vectors and the other things I have cooked up I’d not have refined my sprite library, nor come up with The Vision.

So, off now to draw a few more sprites, delete some code and reshuffle other parts.

It’s amazing what you can do if you put your mind to it. This place is aparrently undergoing major restructuring and management changes. We, the trainees of this place had our little say, jiggled the place up a bit with what we said and caused a bit of a fuss. This place has all the fun politics of a big company at times.

I also managed to build a fire out of soggy cardboard, wet and rotten wood and a firelighter. If you turn a cardboard box over, light the firelighter inside it, then put some wood on the top it’ll light. The gale ripping across the field helped draw the fire nicely and after feeding it with more cardboard it was blazing hot enough to melt glass. Quite bizarre watching a fire burn in a torrential downpour, it just shouldn’t work. I also spent a fun 20 minutes ripping chairs apart and putting them in the skip.

I’ve finished coding most of the guts of Shooty. It’s got title screens, menus, and a complete game structure involving lives. The ship has a working control system. I originally had the ship just shooting upwards from the bottom, but that felt too restricted. I tried a four-way control system, but not being able to shoot diagonally got irritating, plus the gameplay in Sinistar on the GBA is good with its 8-way controls. I couldn’t get a convincing 8-way rotating control system like Sinistar working though, so it’s now got a Robotron-style 8-way control. You can lock the firing direction by holding down the right-hand flipper button for the situations where you need to run away while killing things.

I’m trying to make it less like Robotron though, but if you take a bottom-up shooter and let the ship move around in 8 directions it becomes hard to not make it similar.

Drawing the sprites isn’t that difficult either. Despite my lack of artistic ability, making abstract coloured shapes to shoot at is easy. I have five baddie types and their behaviours designed (you’ll learn to hate type 3 baddies…) which should provide enough hassle for the player. A small particle system is wired up so you get pretty explosions when things die. The explosions don’t kill the framerate either which is nice.

Can’t wait until I’ve finished the game and I’m designing levels and tweaking gameplay.

The text-printing routines need changing too, they’re crap and have a few nasty hard-wired limitations. The code could probably do with a bit of a going over to find silly things and remove junk code. I’m sure I can squeeze some more frames out of the game by reshuffling code - but before we optimise, we code the game and get it working no matter how slow it is.

An in-game level designer might be an idea, it’d let me take my GBA places and create levels without my computer. I guess the players might find it fun too.

Once I’ve finished Shooty I’ll begin something else. I’m quite into the whole retro gaming at the moment, plus coding versions of old games is a good way to learn how to write games.

SPA Re-Assessment on Wednesday. Not gonna bugger it up this time!

Shooty has made one more step towards becoming complete. I’ve been working on the flow of the game, making it do useful things like rotate between the title screens and hiscore table, and return you to them again once you finish your game. It’s now possible to complete the game (all two levels of it), enter your score into the hiscore table, and then return to the title screen ready for another go. You don’t need to turn the GBA off and on again any more

All I need to do is create a little info screen for between levels and a ‘Game Over’ screen. After that, the layout of the game is complete and I can concentrate on making baddies and level designs. I should also probably give some thought to the actual gameplay too. I need to decide how the player’s lives are handled.

All things being well, I should be able to rip the innards of the game out and replace them with something new afterwards.

Shooty now has a high score table. It sorts the scores into the correct order, stores them in the GBA’s SRAM and lets you enter your initials.

Next I think I’ll make a few levels and baddie types, then see if I can get the baddies shooting back and the player dieing. I’m also not quite sure the game is being reset properly at Game-Over. Drawing a more pretty title screen might be an idea too, having ‘GAME TITLE SCREEN Press START’ isn’t that interesting to look at ;-). The sprites are kind of crap too.

My cousin’s written some music for it. Tomorrow I’ll download and have a listen.