Mental Procreation Part 1

Joyous News! Once again Andrew Braybrook's imagination is 'up the junction'... (pregnant pause)... Yes, there's another binary bun in the oven - and over the following months you will be able to witness, first hand, the agonies and ecstasies Andrew experiences... From conception, through gestation, to the labours of birth. In this heart-rending first instalment, Andrew ignores his maternal cravings for lumps of code and gets to grips with ante-natal depression...

Thursday 4th December, 1986

I've finally tidied up the loose ends on Uridium Plus, and the American version of AlleyKat and Uridium. This took a while because I've been installing the anti-cartridge system. Since most of these devices are used primarily for piracy I feel that it is necessary to spend this time, although I'd rather not have to. Such cartridges has no place in the grand scheme of things - if you want the disk version then buy the disk version. If your tape breaks, send it back for a replacement. If you wear it out, buy a new one. It's the same with records.

None of this would be necessary if these cartridges were individually numbered, like certain modems, and had to be in place to reload backups. I suppose manufacturers don't do this because people wouldn't spend $35-50 on a backup device that couldn't make that money back somehow. I wonder just how many people have spent that much on replacement originals. Anyway, I hope that I don't have to spend too long protecting my new game, as it's just an annoying waste of my time.

ST (Steve Turner - the boss) today ordered two PC compatibles for us to write the code on. This means we can write assembler on these big beasts with lots of speed and memory, then down-load the machine code via RS-232 to the C128. Delivery should be mid-January.

Meantime, I have been thinking about the new game design and have been drawing a new character set. I have so far decided on only a few elements which I wish to incorporate, any or all of which may be discarded at any time. This time I definitely don't want to scroll the screen. I know I said that before AlleyKat, but this time I think I've cracked it. I can still simulate scroll with a three-layered, any-direction moving star-field. I've already designed about twenty characters that bolt together to produce a new style of metallic spaceship, different from Uridium, inspired more by Atari-esque graphics as in the AlleyKat title screens.

I also designed a giant bolt-together character set, which used nearly all of the 256 characters just for the forty-odd standard letters and numbers. So, I wrote a BASIC program to scan the set to look for duplicates and compress the set to remove them. It took ages, but left me with 80 characters in the set - quite a saving.

I've started thinking about sprite usage - and since I like the use of no on-screen distracting text I don't need a raster splitting system to split the screen. The 'in' thing seems to be to use more than eight sprites on screen, so I'm thinking of running about 32 sprites simultaneously, without glitches or 'airborne trousers'. Stand on top of the first tombstone in G'n'G and wait for a couple of minutes for the latter effect! I think I can avoid embarrassments like that.

Friday 5th December, 1986

Got to grips with the thirty-two sprite system. It has to reassign sprites to new objects after it has finished displaying the old object. This requires some fancy raster splitting. Such problems as 'What if two sprites need assigning at the same time?', or 'What happens if more than eight sprites need displaying on the same line?', or 'What happens if I move an object while it's displaying it?', or 'What about different sprite colours and display modes?' all spring to mind.

Andrew

I've spent most of the day writing this on paper, refining it on paper, realising it won't work, redesigning it and mentally testing it. I think I've got a Mk 1 system that is adequate for testing the theory. Unfortunately I need quite a hefty system in the C128 just to test these three pages of code. Things like a character set, monitor, and text routines are all required right at the start. With the new large letters I need to rewrite my character and text handling routines. I also need a test bed to get the screen in the right place and mode, preserve the monitor's variables, fire up the interrupts, return to the monitor when required and display diagnostics. This is all before I get to even do any actual game processing! I'd better start thinking of a game name too, as it's very important to get the right name, create a good atmosphere and get things moving in the right direction. After all, it's very difficult designing a title screen when you don't know what to put on it!

Monday 8th December, 1986

Spent some of the morning trying to decipher the RS-232 section in the Programmers Reference Guide. All the decent baud rates are marked NI which we believe is Not Implemented. Thanks, Commodore. I'm not waiting four minutes for any program to arrive from twelve inches away at the PC, so we investigated the user baud rates... Not even Einstein came up with a formula as complex as the one on page 350!

It transpires that the rate in the calculation is in machine cycles per bit - very standard, I don't think. Why didn't it say so?

Keyed in my character set data for my new giant characters in a (hopefully) compressed form. I then updated my utility routine library. At this point I have to start deciding on the overall memory layout of the C64 - where do I put the code? Where does the screen go?

Having decided on a multiple sprite system, most sprite handling routines that I have used before are now redundant. As long as I can use my new system for all my sprite requirements I shall be alright

Tuesday 9th December, 1986

Read up a bit more on RS-232, including how to get it talking to PC compatibles. Now I'm even more confused. A 25-pin connector, ideal for parallel data transfers at high speed, and how many wires do they actually use? Three! Brilliant!

Keyed in enough code to get a test-bed running just enough to see the screen, colour it, write on it, and return to the monitor. Forgot to unblank the screen. Twice! The giant character set looks great, no mistakes, just ABMON printing two non-existent characters.

In this game I need to print a 'null' character, ie: nothing at all. This is important. In every game I've done so far I needed to do this, but never got around to it. It may seem a waste of time printing nothing, but it is in fact very useful. For example: imagine the line '3 ships left'. When there's only one ship left it looks stupid saying '1 ships left', and I hate '1 ship(s) left' as it's a lazy cop-out. So, you need to be able to eliminate the 's' on the end of 'ships'. You could blank it out with a space, but then it looks untidy because there are two spaces instead of one. So, you need to substitute a null character.

Following so far? Yes, I am very fussy, but I take great pride in my work - not a pixel out of place, nor a line of text uncentred.

Wednesday 10th December, 1986

Today's the day - take the plunge and key in the multiple sprite routine. I always write the complicated routines on paper first. This gives me time to think of all the things that might be wrong. Thus, a routine is fairly well debugged by the time I type it in. This does result in a very untidy-looking piece of paper though - keying-in time is a time for mental debugging.

I fired up the test-bed with no sprites to start with - let's not get too ambitious. The system is running OK, so any crashes now will be caused by the multi-sprite system. I set up some sprite positions in the table and switched on a sprite... It appeared. Wonders will never cease! Try two sprites... three, four. All working. Let's go for eight... Since this is the maximum allowed anyway, all is still working. Now let's try nine... The raster splitting system kicks in and reallocates the first sprite further down the screen. It works. Brilliant! How about ten, eleven... fifteen? Let's go mad - twenty-three. It works! All in all a very successful test indeed.

I settled on a maximum of 32 sprites - they make the screen look very busy, and more will take a long time to display and run. Tried a bit of destruction testing. How close can I get the sprites before things go wrong? And what will it do? A ninth sprite can get within three pixels of a row of eight - the worst case. Any closer and it disappears. It took me a while to figure out why, but I accept the reasoning now. Rule two of VIC says: 'I haven't started displaying something from the beginning, so I'm not going to display any of it'. This applies to sprites or characters and really makes partial vertical scrolling difficult (as used in Paradroid).

Thursday 11th December, 1986

Have the large character set in all its graphic glory (?), I started thinking along the lines of a Paradroid style of game - maybe as part of the new game. I decided that I would like to see Paradroid in this style, so I diverted my attention to dusting off the old Paradroid source files. This turned out to be a lengthy job as I started thinking of all sorts of 'What if...'s and did about eight half hour assemblies. At one point I had Paradroid running 50 game cycles per second (three times faster than normal), the same speed as Uridium. It took a while to familiarise myself with the memory layout, as it's rarely the same in two consecutive games.

"My disk drive 'machine-gunned' twice and ruined two consecutive assemblies right at the end. AB is not impressed."

Took Paradroid home to work on it. My disk drive 'machine-gunned' twice and ruined two consecutive assemblies right at the end. AB is not impressed. The red light flashes a bit on loading, but it still works. It's getting unreliable though. That's all I need...

Friday 12th December, 1986

Spent most of the day redrawing the Paradroid graphics in the new style. After correcting the colour table, which displayed the most grotesque green selection anyone has seen since the Dragon 32, it gives a new lease on life to the game. It's a pity that it's too late to use it in the Christmas double-pack, but may be just as well - I'll let my new game show the graphical advance. After all, the object of this exercise was only to evaluate the new graphics properly.

Saturday 13th December, 1986

Completed work on the new graphics as inserted into Paradroid. It looks very neat and proves that the new graphics work, although finding colour schemes that fit is more difficult. They represent a step forwards from the Paradroid/Uridium style but retain the shiny metallic look.

Monday 15th and Tuesday 16th December, 1986

Went to ZZAP! Towers for the News field Christmas Party. Watched certain notables consuming silly expensive drinks, and generally had a good time. Stavros Fasoulas and I decided that redefinable keys are a pain and tried to find the name of the only Commodore owner without a joystick - which should be easy as he'll be the only one still playing The Sentinel.

Wednesday 17th December, 1986

Decided to take the multiple sprite system on stage further to get it running more or less as it will in the final game. This requires strobing between two position tables, the interrupts picking up the sprite positions and displaying them from one table, while the main program works out their next position in the other table... Well it seems pretty basic to me. Fired it up to be greeted by a blank black screen. No return to monitor is possible. The code all seems intact but the interrupts aren't running anymore. I haven't a clue as to why not - it's not as if I've altered a lot in that department.

Thursday 18th December, 1986

Found an error in the sprite assignment system which meant it was trying to update a large-numbered sprite's position. This is more than eight anyway, so some important video chip registers were getting corrupted. This resulted in, amongst other things, a blank screen.

Tired to get it running moving sprites on the screen, but it seems that a routine that puts the objects in the correct sequence ready for sprite assignment isn't doing it's job properly - it's doing a Commando, ie: the display glitches every couple of seconds and objects disappear. Unlike Commando, however, this bug will be fixed!

Still putting together ideas about running the objects in various tables, I have an object table of 'n' elements, some of which will be given sprites because they are near or on the screen. These will go into one or two alternating (or strobing) tables. The active table of these two is then partially copied out into another table for displaying every 50th of a second. The active table then swaps places with it's passive sister table for the next 50th of a second. You probably won't be surprised to learn that co-ordinating all of this gives me quite a headache!

I also want to use Polar vectors for the ships, not X-Y vectors for the movement. I think it'll give them more realistic movements. I may use 'bradians', which involves doing nasty things to radians to get 256 degrees in a circle rather than 360. See Gary Liddon for further information on 'bradians'.

Friday 19th December, 1986

Updating all these objects seems to take up a large amount of processor time. It seems I've only got time to update about 22 simple moving objects every 50th of a second. I'll have to make the code more efficient to run any more than this.

I did manage to get different coloured squares floating quite merrily around the screen, and it does look very busy. Rearranged a few instructions to stop it from glitching.

Monday 22nd December, 1986

Got rid of the last screen glitch and refined the object handler. It can still only manage 24 objects comfortably. I may have to run the objects every 25th of a second. I'll have to experiment.

Scribbled notes on running polar vectors. These are not distant cousins of polar bears but a way of representing movements in terms of an angle and a velocity, rather than X speed and Y speed as I've always done before. The latter approach tends to give unnatural diagonal movements. I shall still use X and Y co-ordinates to log positions, but I will have a giant sine table to look up angular movement speeds. Calculating them would be far too slow. Steve Turner wished it to be noted that he doesn't hold out much hope for this. He only wants to say 'I told you so.' in a couple of months time!

Tuesday 23rd December, 1986

Winding down for Christmas. Had the Company Christmas lunch up at Chequers, and very nice it was too. Tried to get the C64 talking to the Spectrum via RS-232, but they weren't listening to each other.

Wednesday 24th December, 1986

Mickey Mouse award of the month goes to the inventor of RS-232: the standard that doesn't have a standard. Let's have an expensive 25-pin connector and only use eight of them. Let's use cables with only eight wires to make future expansion impossible.Let's use sockets on some devices and plugs on others so that people need a whole host of different leads. And to cap it all the Spectrum has it's own standard four-pin connection! Sparse documentation on the subject gives the impression that on-one really understands it anyway. Anyone know how to connect an Opus PC-II to a C64 via a parallel data link?

Monday 5th January, 1987

Over-slept due to being out of the habit of getting up much before mid-day. Had lengthy discussion with ST about how bad RS-242 is (still) then decided to abandon it. Looked up the specifications of the Centronics interface and compared these to the specifications of the C64 user port. Looks pretty similar to me - and it's parallel. A whole byte at once! Pretty amazing!

Everything we've read implies that it is possible to connect the two. Why has this idea been kept from us? Why does everyone rave over RS-232 when it just doesn't work?

Revised my sprite sorting ideas after discussions with Paul Hughes and Gary Liddon. I will get 32 sprites running with plenty of time to spare. I'll try a faster sort first, and if that doesn't speed it up enough I'll have to rethink the whole system.

Tuesday 6th January, 1987

Battled with the new sort routine some more. Got a couple of BSS errors - the ubiquitous 'Blank Screen and Stop'. Finally sussed out what was causing it, but not necessarily why! It makes a dog's dinner out of sorting the sprites, and causes them to flicker occasionally. Yeuck. It doesn't half fry the old grey matter when you have lists of pointers pointing to other pointers in the same list, and also to other tables. Reading what I've just written, it now dawns on me what I've been doing wrong. All that sorting by Y co-ordinates is undone by the final extractions routine that unsorts everything back into jumbled up sequence (!). Brilliant!

Wednesday 7th January, 1987

Stayed up 'til two o'clock in the morning battling with the sprite sorter. Finally got it to display 32 sprites on screen at once, providing the first one appears last on the screen. Very peculiar. Unfortunately it doesn't leave much raster time to do anything else, such as run the game - in about an inch of raster time on 14" portable!

Got a 'phone call with all the answers at about 11 o'clock this morning. "Why don't you try this..." were the pearls of wisdom. Eventually ascertained what was going on, and it doesn't involve a sort routine at all. No bubbles, no insert sorts, no Shell Metzner (who?), no McPherson Struts...no matter - my logical chain sort isn't quite working anyway!

Rearranged the program a lot and then rearranged it again after realising that the first method was very silly indeed. It was setting up a new table on top of an old table, which the interrupts were still trying to read! This is what causes what IBM call 'unpredictable results'. Personally, I find the results very predictable - it always goes wrong!

Now I've got my 32 sprites whizzing around the screen looking like an abstract asteroids game, I've got at least four inches of raster time to spare, and I've very happy. With a bit of optimisation I'll get some more time back and I can start on the moving background system.

Thursday 8th January, 1987

Went to Hewson's New Year launch in Picadilly and met some of the Press. Finished the day with a visit to a couple of the arcades in London to see what's new on the 'real' machines. There are some great games about with superb graphics like Slapfight, XX Mission, and Salamander. It really makes us weep to see what these machines can do. Saw the new hydraulic-seated driving game with probably the same video chip as Space Harrier. This produces a very convincing environment, mostly with giant sprites. The gap between arcade technology and home micro technology is widening.

Friday 9th January, 1987

Our new Opus PC compatibles have arrived! ST has one of them working and is trying out some of the software. They're quite large and have a rather loud fan inside for cooling purposes. There's also plenty of reading matter to plough through before we can get working on them. On the game front, I've optimised the sprite code a bit more and it's all running smoothly with no apparent hiccups.

Monday 12th January, 1987

Snowed in at home. Luckily I have my working disks at home so I can carry on - but without my notes. Ah well.

To speed things up even more I had a quiet think about sprites. My current system sets position, colour, sprite image and mode in either hi-res or multi-colour. I realised that any one sprite image will always be in the same mode, and usually the same colour. Thus, it is necessary for the object mover to worry about colour and mode - the display routine can just pick these up from a table. I can update this table if an object needs to change colour.

Tuesday 13th January, 1987

Still snowed in. I still haven't drawn any sprites that I need - I'm not even sure what I need! I want to stter clear of space-ships and robots as these have been used to death on the 64 over this last year.

Had a lengthy session on the sprite editor, just doodling. I know what I want but I can't really draw it. The editor doesn't quite reflect what my game needs, ie: a different colour for each sprite, which makes it difficult to check animation.

Wednesday 14th January, 1987

Been thinking about the background. Again, I know what I want, but I have to think of a different and plausible scenario. As this type of display hasn't been used before, to my knowledge, I don't even know if the game design will work! If I go ahead it could be two or three months before I know for sure either way! This requires more thought, and perhaps some discussion.

Thursday 15th January, 1987

Had the brilliant idea of using a bit-map screen to get more colour out of the machine - three independent colours per 4 x 8 pixel square. This is appealing, but it costs 9k in the 16k video bank. That leaves 7k for sprites, or 112 images. In character mode it would only use 3k, leaving 12k for sprites - or 208 images. Do I really need the extra colours? Looks like I'll have to live without them.

ST phoned in a jubilant mood in the evening to say that the Spectrum and C64 are now chatting to each other - both ways, in parallel and reliably! This bodes well for connecting the Opuses (Opae?) to the target machines. Bye bye RS-232...

Will Andrew and Steve ever get their 64 freely conversing with an Opus? Or are they both mute? Find out next month...

Series Links

Part 1 / Part 2 / Part 3 / Part 4 / Part 5 / Part 6 / Part 7 / Part 8 / Preview / Review