Part 6. Hammering microdrives, things spoilt in a flood and building the model editor.

If I had a Hammer..
I was searching in the loft today and came across some old photos taken by Andrew Braybrook.  One picture had me with a hammer threatening to destroy my two microdrives.  Hewson once put a copy of this in a press release and it was printed in many magazines.  My microdrives just did not work properly. I would record a copy of my "source" code and next day could not load it or the previous version. I hated having to retype all my previous work. Sometimes my wife used to type it in for me, if  I had it written down. More often it would be lots of little changes scattered throughout the program and hard to remember. I used to print of a disassembly now and then so I had a hard copy as my only true source code was hand written in pencil and corrected by rubbing bits out until the paper disintegrated. I would then pencil in fixes on the listing until it got really messy.  How much easier it nowadays working with proper source code.

Once Andrew Hewson decided that I needed a cooler image so went to the shops for some props which included a plastic toy robot and a copy of Playboy. He took pictures of me with these unlikely objects and sent them to magazines. I remember one of me reading Playboy was printed in a mag as later a reader wrote in calling me "porno perverted Steve Turner". The irony was I didn't even get to read the Playboy as Hewson took it.

Disaster!
We had a bit of a disaster in my spare room at home recently leading to water damage. The ceiling had collapsed  with a deluge of water.  When clearing the room last week I came across the folders of Paradroid and 3D Seiddab Attack , both badly  damaged by the water. I was upset because I thought I had given the Paradroid folder to Andrew. It had all the original ship maps carefully drawn out on squared paper. Among the papers were  Andrew Braybrook's original diary sheets he kept while writing Paradroid. He condensed these into Paradroid: Diary  Of a Game. Originally he sent the copy to Andrew Hewson who used to add bits such as  a broken ruler nearly hitting a non existent cat.  So Andrew B sent future instalments directly to Zzap64.


 Progress on the game.
Over the last couple of months I have been writing some utility screens to edit 3d objects. That exercised the little grey cells. I miss having someone working with me. It helps greatly to talk a problem through. It makes you think about it in a structured way. I sometimes find that trying to explain a problem to my wife will help me come up with a solution even though often she hasn't a clue what I am on about.  My new screens made excessive use of the system I had previously coded that was like a cut down Visual Basic. I wanted screens that contained subscreens that could flick between different data displays at the touch of a button. I came across a few bugs in the system; although I had tested the individual controls this was the first time they had been used for real screens. That is when you find it if you have foreseen all the things that you really need. I had not added a data validation system although I had included text input boxes. So to avoid having to write dozens of individual validation routines I added a systematic approach.  I added a datatype object that managed all operations dependent on the type. This included validation, formatting for printing and input character filtering.  I made use of the existing event system to create a validation event so that I could add any specific field validation on top of the standard validation.  I created a binding object to manage the association between form controls and the underlying set of data fields. Then with one call I could move all the data for an item to the screen or vice versa.

It took me a while to get round the building of the 3d models. I wanted to create models that used triangle strips and indexed vertices for speed in the game.  This format reduces the amount of data that the graphics chip has to handle. I wanted a to be able to see the model change as I changed data values. I created a 3d model format that was easy to edit and each cycle converted this to format I use in game that in turn gets loaded as triangle strips and vertex lists. Even on my old laptap the speed was fast enough to completely rebuild the model  each frame.

For the asteroids I wrote a fractalise routine that added points halfway between existing points of a base model and wiggle them about a bit.  I included a wiggle factor and a smoothing factor to reduce the wiggle on each fractalise iteration. The number of fractalise iterations could also be specified.  Adding extra points to an existing triangle strip was more complicated than I thought. Each point has an associated texture coordinate. When you wrap a texture around an object you always get a seam where the texture meets. The points along the seam have to be duplicated as two different texture locations occur at each seam point. Two adjacent strips share adjoining points.  When each new point was created is was important to get all this correct.  I was seeing triangles in my sleep for a while.


Having created random objects it was time to try designed objects. I drew loads of pictures of spaceships and parts trying to generalise them. What makes a spaceship look like a spaceship. I ended up with the following rules.

Left right symmetry was important.
Up Down symmetry sometimes occurred but could be different to identify the top of something.
Shapes generally had a front end a middle which might be long, and a back end.

With these rules in mind I designed a window to shape the cross sectional shape. I had optional horizontal and vertical symmetry and/or a rotational symmetry number. I also added a rotational reflection  so each rotational iteration was a reverse of the previous one.

I also designed a window to make a side view with a front middle and back set of points that could be moved. The mid section could be repeated.

Finally top down view allowed points allowed to top down shape to be adjusted. Left and right points were mirrored to reserve left right symmetry.

I used lines to connect the points so  a drawing of the overall shape could be seen. At first the lines and points could not be seen and I went through the usual debug session of figuring out why something was invisible. I completely forgot that each view s coordinates  had to be offset to the views display position. My brain expects Direct X views each to have an origin of 0,0 rather than use the display windows origin. I means if you move a view you have to move every coordinate to match. Whoever designed that. I can resize each view by dragging the window edge so that is a real pain. It took ages to get the lines working. They copied the points coordinates so should have been easy. I just could not see anything wrong and found it was a bug in my core plot system. It can dynamically fill plot buffers and flush them for drawing when required. I had forgotten that indexed vertices had to take into account the fact there were already vertices in the index buffer. The issue affected all sorts of plot types and I had missed this as my 3d models were in preloaded individual buffers so happened to work. Never assume anything is correct until proven when something goes wrong.


Coding Tip.
About 30 years ago I wrote a column called "So You Want To Be a Programmer", I think the articles are on the internet somewhere. With the growing interest in coding I thought I would include some tips in my blogs for budding coders.

The key to good coding is to make your source code clear with good succinct labels that make comments in most places redundant. I used to say to my programmers write code so that the cleaner can understand it. Then when you revisit a routine months or years later you stand a chance of understanding how a piece of code works. It just does not pay to write code that is tricky, too clever or too complex. The C++ language gives plenty of opportunity to cram so much functionality on a line that it is completely unintelligible. Real clever coders use their brains to analyse a problem and come up with the simplest solution.  Some things are just complex by nature anyway so it takes skill to make sure the complexity is not magnified by devious coding.