Part 7. Summertime blues

Apologies for lack of piccies,  tried on both laptops but page just locks up when I add them!

Summertime 25 years ago.
Back in the day summertime was perhaps the busiest time of the year in the games industry. The market was very seasonal with the big shows preceding the winter sales campaigns. So all the publishers wanted show ready games at the end of summer. That meant lots of late nights working in the summer heat to meet deadlines. I can remember one year a publisher forgot to pay our monthly advance as they were all busy preparing for a show. That meant I couldn't pay the wages. We lived pretty much hand to mouth at Graftgold relying on publishers regular payments. In the early days I used to take my invoices to my bank and they would just lend me the money for a week or so. Later on as the country went into depression banks changed and you could not get any kind of loan without putting up collateral.

We would turn the stereo up with some rousing rock and program on into the night. I enjoyed it as you could get on without phone calls. That is until we worked for  Japanese company. They used to call in the early hours of the morning with their lists of bugs or improvement requests and expect a new version the following day. The girls that worked there were very polite and took Andrew and I out to a Japanese restaurant in London.

Deepest Blue Progress
It seems ages since the last blog. I have been making steady progress but the distraction of hot summer days and tweeting has taken its toll. I found Andrew Braybrook's original daily diary he kept while developing Paradroid. At the end of each day he would jot down what he had done and any amusing things that happened in the office. He condensed them at the end of the month for the articles published in Zzap64. His notes put me right back to those days and the banter that went on between us. There was quite a rivalry between us and that helped push us to our limits. Andrew used to call me Mr Boss Man Sir and used to use a lot of phrases from Reggie Perrin such as " I didn't get where I am today by ... " where ... was the thing I wanted him to do. It was all very good humoured and we had a lot of fun working together. Seeing the funny side of things helped when the machines crashed or the power was cut.

I reckon they owe me about £10,000 plus expenses!
At least we did not have Adware in those days. My laptop got infected and removing it with ZoneAlarm also destroyed my internet connection. Without that I was helpless. I tried for a while downloading fixes on my wife's tablet but in the end bought a new laptop. I had to get a registry hacker to delete corrupted entries in the root registry. Then I found I could not put the correct entries back in the registry. It took many times of rebooting , registry editing and deleting till I managed to get the laptop going.  People writing these Adware programs that hack your registry should be hunted down and made to pay for all the damage. I reckon they owe me about £10,000 plus expenses!

Now I am working alone I have no one to complain to when my brilliant idea nearly works but not quite. I keep thinking I've finished my ship part editor and I discover a gotcha. I saved out some part models and tried to install them into my space dock screen that allows you to choose parts and fit them together. That is when I realised I had forgotten that I needed data to describe the type of joins that each part has. To fit parts you need the locations of the joins and the types of the joins. So back to the editor.  Adding joins was harder than I thought. I had an editor that allowed all sorts of wiggly shapes for the parts but joins need to be flat and regular. Parts were defined using points but joins are between edges ie pairs of points. So I needed to be able to add a restriction between pairs of points to make an edge a certain size and orientation, while all the other points could be wiggled about. It was far easier eating an ice lolly on the sun lounger than solving that but I got there in the end. I decided to put some data in the old fashioned way by typing in the source code. Sometimes you cant beat a text editor with a GUI screen for entering data. I wish Microsoft would learn that. 

About halfway through these changes my laptop decided to add to the fun by switching off the screen when the lid was properly open. So I was programming with the lid 6 inches open sitting with the laptop at an angle so I could see the screen. I decided it was time to move everything to a laptop. I had been delaying this as I knew this would mean pain getting direct X working on a new operating system. I installed a newer version of Visual C and set it up to compile for XP.  Its best to change things 1 at a time, later I will probably upgrade to a later toolset and abandon XP. I was going to use my XP laptop to test 2 player peer to peer networking so need it to work on XP for a bit.  I managed to network the machines and port all the code and DirectX. It took a while to read all the Microsoft stuff so I could compile with the Direct X 9 is was using. Then disaster, I had the old one Id seen before where it was trying to pull in both the old and new DX libraries. I tried altering the order of includes to no avail. Then suddenly I  fell in. I noticed differences between some of the names between the two versions. Somehow in the past I has managed to do a repeat change on one of the old DX header files. That's why I had been having issues with direct X samples for years. I fixed the header and lo and behold I got a clean compilation.

Spurred on by this I pressed the button and the program promptly crashed. It was not creating the DirectX object, that is about the first hurdle. It gave an error code that basically said "invalid call" that did not impress me. It has loads of data going into the call and a clue would have been helpful. I fired up a demo program and that got past that call. So laboriously I checked each setting to find the offending one. Finally I found the setting it didn't like, no idea why, but the program ran with all the graphics working.

The new Visual C game with a version controller untastefully named Git. I missed version control as it allows you to easily compare previous versions and see what changes you have made. That is invaluable for finding errors. They usually have something to do with the code you have changed.
Putting the whole of the code under source control was pretty easy. I just had to figure out how I could have several solutions all sharing common projects. The easiest method was to copy the solutions to the directory level above the solution directory tree. I was impressed when it compiled without me having to retype all the relative include and library paths. Time for a back up. I copied the complete source to an old hard drive, all that remains of my very first laptop.

Now I was on a roll. I tested out the saving of the join data which needed a bit of adjustment and noticed some errors with the xml saving routines. I fixed these and added auto indenting to make it more easily read. I tried it in the visual C editor but it doesn't like my XML as I leave out unnecessary
quotes for data values for speed. XML is so unwieldy, why for example do you have to say what has ended, you can only end the current tag level.  Just when I think I am out of the water I notice some strange wiggles in low poly models. After hours of checking the routines I realise I have made a basic design error. Using tri strips wrapped round the models has a handedness that makes models unsymmetrical. This is really noticeable with shapes that  are   stretched laterally at the back or front.
I realised I would have to change the handedness of the tri strips as I passed 180 degrees around the model so left and right sides could be identical. That was easier said than done. Each three points in a tri strip has to be in the correct order for the triangle to be visible.  I tried drawing it out many times until I hit on the answer. I wanted a continuous strip for speed so had to introduce a dummy vertex and tweek the order of the vertices halfway through each strip. It took me many attempts and a few crashes until I got it right.

There is one more thing to do. I want to create a sort of lego set for building massive structures. The models for these need the joining sides to not have textured polygons as they will always be hidden. I need to figure how to do this within the format of my tri strips that wrap round the models. My brain just cant work this one out at them moment   I can remember whenever Andrew B was stuck he would design a character set or a new sprite so I decided to update the blog.  That's it up to date so from now on the blog will show monthly progress (or lack of it). I can't wait to get back to the actual game I've been thinking about flights of ships in formations and big fleets, also of hud displays and the way I want to do the ancillary computer displays. There is so much to do I'm glad there is no deadline. I am at the point where the publisher would not understand the work done behind the scenes and start to get very nervous. They used to think in terms of seeing an equal amount of the game for an equal period of work. It just does not work like that.

Andrew came round for my wife, Julie's birthday. We went on Twitter for a while.



Programming tip. How to go faster.
I often get asked how to make something go faster. The best way by far is to design it for speed rather than try to optimise the code.  Doing less is faster, the bits you can leave out completely are the fastest of all!  The mistake many developers make nowadays is to think that cpu's are so fast you do not have to worry about the time the code takes to execute. Wrong. A programmers capacity to use extra cpu time far outweighs any increase in speed over the years. That is why computers take longer to do things than they did years ago. My spanking new editor freezes for a few seconds every now and then as it tries to be really clever behind the scenes. I had a Spectrum editor that was faster. My Spectrum booted up quicker than my laptop which should be a million times faster. I've spent many years speeding up other peoples programs. Here are some things to look out for.
1.Chart out calls and ensure routines are called only once when they are needed by structuring code.
2.Avoid recursion, it is unnecessary and can  be replaced by a loop.
3. Avoid multiple memory allocations when a block can be used.
4. When writing to sockets do one large write the size of the network packet.
5. Avoid multithreading where possible it quickly gets complex if threads interact.
6. Understand the difference between blocking and non blocking calls.
7. Measure code timing with a fine timer , milliseconds is far too coarse.
8. If you have to optimise concentrate effort on chokepoints and the innermost routines that are executed many times.
9. For systems design it like a production line so each component works simultaneously rather than sequentially.
10. Design data to be compact but easily digested.