Part 12. The light Dawns

Graftgold Memories.

At first Andrew and I worked in my dining room. Then we worked in a little office at the back of my new house. We each had a PC with 2 floppy drives. Hard drives were yet to be a regular feature on a PC. We set up a RAM drive on each machine to contain all the software we used. That speeded up compiles. We saved all the source on floppy disks keeping a number of generations. It was so much faster than the slow C64 floppy drive Andrew used to used. We shared a dot matrix printer, mostly used to print out code listings. We debugged from listings by dry running quite a lot , a hangover from our commercial background.

Me reading a listing of Lunattack in my dining room before we had proper desks.

An essential piece of kit was the hex calculator we each had. I found mine in pieces the other day and managed to stick it back together. Occasionally I want to convert  a number while debugging and cant find where they have hidden the hex/decimal option so find this useful. We originally used a lot of squared paper writing our code on paper before keying it in. However that soon stopped once we had better text editors and it  was quicker to just type your code straight in.

Deepest Blue Progress.

Sometimes you have to go backwards to go forwards. It was one of those times. Last month I had already wrecked the display trying to add lighting. I decided In an attempt to sort this out to revise the graphic system. I decided to get rid of using the DirectX Effect processing as it was deprecated in later DX versions and I already had an Effect object that managed an optional vertex and pixel. The result of changing this and the texture format and lighting changes last month lead to chaos. Now I had no lighting, no background and the sprites and 3d objects kept disappearing randomly. When the 3d objects appeared they looked inside out. I normally would only change one thing at a time rather than a big bang approach. Now I had to pay the price.

So where do you start when just about everything seems to be going wrong. Debugging can be a process of elimination. Cut stuff out until the bit that's left worked then you know what system is causing the problem. That's fine in theory but with DX you need so much there to see a result. I went back to the graphic editor program to make things simpler. No model appeared in the display until I changed the effect. Then the model showed when I turned the effect back to the initial setting. That was a huge clue. Something I did when I changed the effect was doing something to mend the broken display. I traced the code executed on pressing the button. It hardly did anything but change the effect number. So what happened when the effect number changed. I stared at the code for ages and suddenly fell in. I had moved the code to set up the vertex structure to the wrong place. It was only set up when the effect changes. However if the effect had no shaders it may be used for several vertex formats. Eureka! One small change and the models and sprites were back.

However models that were built by the program were inside out. I knew that suggested vertex ordering problems. Start at the wrong place in a strip and the triangles are all the wrong way round.

Sure enough I found a mistake in the vertex indexing. As I put multiple strips in a buffer I put dummy triangles at the start and finish.  You can just step past a dummy triangle but not when its the start of a strip , or you start with the triangle that's meant to be anti clockwise.

Ok two done, still no lighting. It is time to bite the bullet and get it cracked. I read all the articles on the WWW I can find , check my code again. I just could not see any difference.  I knew I was missing something. Not even background lighting was working. I thought I would try changing the values in the material I was using. That was when I found it. The values were crazy not the ones I had set up. I found that In my data I had got the Material format wrong. In the non DX graphic code I had my own Material structure with standard Microsoft DX RGB values. For speed as it mimicked the DX structure I had just done a memory copy. That was dangerous and wrong and would never pass Andrew's code QC! The Material structure has RGB values specified as floats. I was effectively copying garbage into the material. Excitedly I moved the fields across properly and for the first time saw some light.

Test Ship In The Ship Editor With Lighting

"Rather than invert the inverted matrix I just used the starting matrix"

Now to get the background working again. This was drawn be a vertex and pixel shader pair in a DXEffect. I extracted the shaders  and set up my custom effect. I got a background but it was madly distorted giving all sorts of crazy warp effects as I moved around. Debugging shaders is hell, I cant trace them on my set up. I suspected it was something to do with the transform matrix sent to the vertex shader. I was days sorting this out. It turned out that that a DX effect matrix is in DX format but if you send a matrix as four sets of Float4 variables to a Vertex shader the matrix has to be inverted by changing rows into columns. The funny thing is this is the format I use in my own code and just to add complication the matrix for the background had to be an inverted worldview anyway. Rather than invert the inverted matrix I just used the starting matrix and bingo, one sky sorted.

Time to do something to the game now I could see it. The HUD needed target and display for custom sets of guns. I decided on grouping these into forward fixed guns and  top,bottom ,left, right and aft turrets. I added code to automatically group the guns. Maybe I'll let the user make up his own   gun banks. For small ships you probably only want a couple of groups. I will mull that one over.

I reused the radar graphics just to get the code working. I will have a graphic session soon and get some finished quality graphics in. My drawing software is on my other laptop and I need to get the look pinned down first.

The guns were running out of power so gave up firing. I realised my test ships had no reactors so this was not surprising. I needed to code the energy display for the ship console. I wanted the player to be able to adjust energy for larger ships, "Divert all power to the shields" or to overdrive things "the engines wont take it captain".But for small ships where the player is having to dogfight it has to be automatic. I opted to have a display for each group of components.

Reactors.

Batteries

Shields

Weapons

Engines

Systems

Repair.

For most the panel will show the requested power level and the achieved power level, The reactor will automatically go into overdrive to attempt to meet the needs. A temperature gauge will show when things are getting desperate. Overheat and damage will be caused.

I had brain freeze on the first couple of attempts to code this. I kept coming up with flaws so switched off. Sometimes you just need to think things through a bit more and pin down what you are going to code.  Many pages of sketches later I was ready to code.  I coded up the power bars using two sprites one for the bar present one for the bar background. By changing the height of each and the start/end position of the join I could quickly draw each with four triangles.

For the temperature I thought I would go lo tech and have a nice meter display with a needle that moved over to a red danger area. All I needed was a background and a rotating sprite for the needle.

I also needed buttons to raise/lower the power and to toggle auto mode and a repair button. I used standard form button control for the buttons hooking up the pressed event. It is great when you have a system and can install things rapidly.  All the positions for these were input in my xml form design system. I just need some test graphics to see if the coding is working.

There still seems so much to do. On the Spectrum we stopped when the memory was full. How do you decide when to stop on a PC?
To Do List.
Space station models.

I would like to let the player customise the bases adding defences etc. I could reuse the ship builder. It would be nice to see the bases being built in space.
Asteroids.
I need to code interactions . I want the payer to be able to split them,  collect them, tow them, throw them at bases etc.
Fleets.
I've got basic formations but need more AI for controlling fleets.
Multiplayer.
I've coded a comms. system but it needs upgrading to use non guaranteed packets so its fast across the internet. Then it needs installing.
Graphics.
Nearly all need to be revised. I fancy trying some computer generated textures.
Effects
Need loads of these for weapons, explosions, shields, warp tunnels.
Sound.
I want to record my own theme music. I love the way a game comes to life with sound effects.
Play Testing
First by me them by others
Then there is all the non dev stuff such as Publicity, publishing, marketing setting up servers website pages etc.  It is a lot to think about as the coding matures. And I am already itching to start on my next game.

Programming Tip

Nowadays floating point numbers are used for just about all calculations.  In the days of 8 bit and 16 bit computers integers we used for everything. Some of the properties can be very useful even today to provide an edge on speed space or utility.

Circular numbers.
An integer uses either 8, 16 32 or 64 bits to hold a number in binary representation.  If you add 1 to the maximum that an integer holds it goes back to zero. This property can be useful. Angles used to be a doddle. You could use a 16 bit integer to represent 0 to almost 360 degrees. You could just add angles together and the result would automatically overflow to the required answer without having to add extra coding to cater for angles over 360 degrees.

Fractional Numbers
To deal with non integral numbers using integers is easy by just deciding how many bits to use for the fractional part.    For example you could use a 16 bit integer to hold an 8.8 bit number. The top 8 bits represent the integer part, the bottom the fractional part. You can add and subtract numbers of matching precision but have to take care when multiplying or dividing. If you Multiply a 8.8 by a 8.8 precision number  you get a 16.16 precision number that has to be right rotated 8 times to get a result in 8 bit precision. We used to comment each line with the precision after the line was executed as it was all too easy to lose track of the number of precision bits in a calculation. You can multiply numbers with different precisions as long as you remembered the result has the precision of the sum of the precision of the operands.

Look up Tables
For complex functions it is easy to use an integer as an index into a table of results. This is an extremely effective way to model all sorts of outputs rather than write a complicated calculation.
It is most suitable where the result does not have to be a smooth curve that would require too many entries, say working the chances of a AI decision.  I used to like updating data tables at runtime while the program is running, an option sadly lacking in Visual C debugging. I controlled things like the movement patterns of meanies in this way to get complex movements with little code.