ECE 291  :  Final Project

<h2>War's Rage</h2>
<plaintext>


Team Members:

	Nicholas Guerrero
	Justin Palmer
	Michael Vachanastienkul

Summary:

	This program wil be a simulation for a space-flight battle scenario.  Ships will be represented
as a combination of parrallepipeds, to make implentation and creation of the ships as simple as possible.
The game will be in a true 3d environment, which means that there will be a virtually infinite number
of views with which you will be able to view other enemy ships.  There will be stars in the background,
and they too will behave in a "true" sense (rotating right will not simply mean shifting stars to the right -
in reality, stars near the top and bottom will experience a curving effect).

	The game will be networkable, with several players being able to play at once (how many players
will depend on how fast the game can run).  To make the game easier to write (and easier to debug), we
aren't going to worry about computer generated enemy ships (artificial intelligence can really be a pain!).

	The only things that you will really see at any time are:
  a)  stars
  b)  enemy ships
  c)  weapon fire (enemy and your own)
  d)  the occasional flicker of shields (enemy and your own)

	There are several different types of weapons available, although we might not get a chance to get to all of them.  But, they include, but are not limited to:
  a)  laser fire
  b)  ion charges
  c)  flares
  d)  mines

Implementation:

The "essence" of the game is based on two major things:

  a)  each ship will have a center position
  b)  each ship will consist of three perpendicular vectors

The center position is how we know where the ship is.  It will consist of a total of 6 words.  Three of the words are for the x, y, and z major coordinates, and the other three words will consist of the x, y, and z minor coordinates.  This is somewhat equivalent to the major coordinates being whole numbers and the
minor coordinates being decimal points.  This gives the game smoother motion and a larger playing field.

The three perpendicular vectors are a bit more complicated.  Each vector must be perpendicular to the other two.  The vectors will be in the general shape of the index finger, middle finger, and thumb of the right hand, much like in physics when dealing with "the right hand rule" (index finger points forward, middle finger points left, and thumb points up).  The three vector will be representative of three things:  the forward vector (index finger), the left vector (middle finger), and the up vector (thumb).

	The number of forward vectors, left vectors, and up vectors that are needed to reach a point on the map will determine how it and where it is drawn (how many vectors of each you need can easily be calculated using a variety of mathematical equations.  The one we will be using is the equation for a point to a plane).

	Rotating the ship will cause your vectors to rotate around the center point, and moving forward or
backward (left right up down) will cause your ships center position to change.

	One final note about the game.  Since the game is to take place in space, and since there is NO friction in space, inertia will play a rather interesting role in the game, since there is nothing there to
auto-slow you down.  But more importantly, rotating will result in a lot of affects that most people would
not expect (it will no doubt feel a little unintuitive at first and be a bit difficult to control when rotating
along more than one axis).

	To this end, there will be 6 word sized values, 3 for translational velocity, and 3 for rotational velocity.  All values related to position and rotation are signed numbers.


Procedures:

CreateStars:
Nicholas Guerrero
	This procedure will fill the star segment with x, y, and z values.  It will also tack on a brightness
factor for each star, so that it will give a more realistive affect and have many stars of various brightness.
There is also the possibility of adding on a twinkle factor, which will allow the stars to twinkle on and off at semi-random intervals (it could actually result in a decrease in processing time, since there will be fewer stars to draw at any given time).  The possibility also exists that we will have some stars which will be of
some slight shades of red and blue (to make it just "oh the wee bit more" realistic - there are red and blue
stars, right???).  A fairly straightforward and simply procedure.  It is called only once in the beginning of
the game.

DispStars:
Nicholas Guerrero
	This is the procedure that displays the stars.  It is called once every  time through the program cycle.  It's purpose is to read in the "coordinates" of each star, along with color, and call the DispStar routine, which actually puts the star to the screen.  If twinkling ever gets implemented, it will also check
to see if calling the DispStar routine is even necessary.

DispStar:
Nicholas Guerrero
	It uses the method described above in the implementation of the writeup to figure out how many
of the forward vector, left vector, and up vector you need to display a star.  First, it calculates the forward vector.  If it is negative, then the star is behind you, and you simple quit.  If it is positive, then you need to calculate the up and left vectors.  (# of left vectors) / (# of up forward vectors)  will tell you how far to the
left (or right) to draw the star, and  (# of up vectors) / (# of forward vectors)  will tell you how far up to draw the star.

DoChar:
Nicholas Guerrero
	This procedure has been rewritten once already.  Basically, it's job is to, based on certain flags that
are set, to set the approprate translation and rotation variables.  That's it.  It checks which flags are set (these flags are set in the KeyBoardHandler routine), and then increments or decrements the corresponding velocity and rotation vectors.

InstallKey:
Justin Palmer
	This installs our KeyBoardHandler routine.  Fairly basic.

DeInstallKey:
Justin Palmer
	This deinstalls our KeyBoardHandler to the original.  Fairly basic as well.  Necessary for normal operation of the computer once the game has been terminated.

MyKeys:
Justin Palmer
	This is our KeyBoardHandler.  Fairly basic in a not so basic way.  Uses a jump table based on the key that was pressed (or released).  The jump table can be modified in the SetKeys routine, which will allow you to change which key does what (it will simply change what offset the jump table points to).  Other than that, there is nothing particularly special about this procedure.

	The jump table is where the flags are set which determine what DoChar does.

SetKeys:
Justin Palmer
	This procedure allows you to change which keys do what (no two people are alike, and just about
everyone wants different keys to do different things).  This is a nicety option, and thus will be implemented
last, time permitting.  Basically it will set the value on the jump table array to the offset of the label which
points to the function you want to enable.

SquareRoot:
Nicholas Guerrero
	Takes the square root of a unsigned, double word sized value, and returns the value in ax.  The values of the double word sized value is stored in tempa and tempb.  Since we don't need a highly precise value for the square root, we aren't going to use the Fsqrt command.  The method we use involves the semi-basic guess and check method, although there is in reality no guessing involved.

WaitReTrace:
John Lockwood
	This procedure was defined in mp4 and simply copied.  It waits till the little electron beam which displays the screen to finish making a pass of the screen before changing information sent to the screen.  It reduces flicker and the such.  Nothing very special.

DrawBlack:
Nicholas Guerrero
	Does what you might guess.  Shoves a bunch of black pixels to the buffer and essentially draws a black screen, although stars and ships and such will overwrite these black pixels, so you won't really ever see a black screen.

DispScreen:
Nicholas Guerrero
	Moves the information from the segments (or segment if we stick with VGA) from the buffers to the Video Memory.  Nothing very complicated at all here.  Is useful when combined with the WaitRetrace procedure in reducing flicker and "odd" pcitures from being displayed.

CalculateCP:
Nicholas Guerrero
	Calculates the center position of the ship based on the translational veclocity values.  Changes the inner coordinates first, and then changes the outer coordinates if the inner coordinates over flow.

CalculateCV:
Nicholas Guerrero
	Calculates the component vectors of the ship.  The component vectors are the forward vector, left vector, and the up vector.  Each vector has three coordinates (an x, a y, and a z), and has the same magnitude (currently 32000).  This procedure has already been rewritten 3 times, but I think that it's finally
stable now.  Previously, the universe would periodically collapse on itself.  But after a complete rewrite, the universe has been saved!  The method in which the procedure calculates the component vectors is difficult to show on paper, and is even harder to explain plain writing.  But basically, it uses properties of the cross product, magnitudes, distance from a line, and some scaling.

CheckLengthCV:
Nicholas Guerrero
	This procedure checks to make sure that the component vectors are all of the same magnitude.  Some simple scaling is all that is done.  This procedure is currently called only once every 200 times through the main program loop, since it is once a check and, in theory, should never really be used at all.
It's primary purpose is to prevent any major long term damage due to any slight errors in my code.

CheckPerpCV:
Nicholas Guerrero
	This procedure makes sure that the three component vectors are indeed perpendicular.  They ought to be, and like the prevoius procedure, is only called once every 200 times through the main loop.
It's there simply to prevent massive degredation of the component vectors.

DrawPoly:
Nicholas Guerrero
	Draws a polygon to the screen.  The procedure has not yet been written, but will probably call other routines to make it as simple as possible.  It should call a routine which calculates the points that
will lie on the lines between points of the polygon.  It will store these points in two different arrays, a left and a right array.  This procedure will then call a clipping routine, which will modify some of the values of the array so that they are all on the screen (no point in trying to draw points which aren't on the screen).
Finally, the DrawPoly procedure will call a routine which connects the dots between the two arrays.
If time allows, we will also add a call which outlines the polygon so that you can more easily distinguish between adjacent polygons.

DrawCircle:
Nicholas Guerrero
	Draws a circle to the  screen.  Hopefully, we will be able to read in the current pixel from the screen, and then modify the color slightly so that it appears to be a transparent green or red or blue.  If the gods are not smiling upon us, we might be forced to simply do a slightly wrse version of the same thing.
We might end up simply plotting every other pixel of the filled in circle, which will sort of give it a see through colored affect.

DrawStatic:
Justin Palmer
	Draw the static elements to the screen.  Really, the only static element is the control panel, which will be on the right side of the screen.  This is where you will read off important information, like shiled strength, damage taken, and stuff like that.  Not a very complicated procedure to write.  The hard part will be figuring out what to draw where.  This should only be called once.

NetPost, NetInit, SendPacket, Post, and NetRelease:
John Lockwood
	This five procedures were copied from John Lockwood's NetEx program.  They allow networking to be done fairly easily.  The only one I will be using differently then his program will be SendPacket, which I will be using to send center position and component vectors over.  Nothing has been changed from the actual code, however.

PowerControl:
Justin Palmer
	This is not actually a procedure.  It is code that will need to be implemented into the jumptable, but it is code that is large enough and self contained enough so that it should get it's own section.  It allows you to divert energy from various categories to other areas.  This way, you can have more energy in shields than in engines, or more in weapons than shields and engines, or just about anything.  It also allows for specializing between weapons, shields, and engines.  Example, maneuvering thrusters may get more power than main thrust, or forward shields will get more power than aft shields.  There is also the option to lock a particular area, so that if I lock shields, and then increase weapon power, it will only take from engines, and not shields.

SoundInit:
Michael Vachanastienkul
	Not too sure, but I think that we are going to need to initialize the sound card in order to play sound.  That is what this procedure will do, initialize the sound card.  All of the sound procedures will need further research in order to be more specific as to how to do what.

BackGroundSound:
Michael Vachanastienkul
	Play sound in the background.  Once again, more research is needed to know more specifically how it works and what it needs.  This is just to play some cool sounding background music to listen to as you kill all of your friends.

SpecialEffects:
Michael Vachanastienkul
	Play the special effects that should be incurred when you fire a weapons or get hit.  Fortunately, sound doesn't travel too well in space, so we only need to worry about what hits us or what we send out.

DispRadar:
Nicholas Guerrero
	Display the background for the radar.  Not complicated at all, but it will need to be called every time, even though it never changes, since it is always need to be on top of everything else.  Basically, it just draws two, green, semi-twisted oval shaped circles at the bottom of the screen.

DispEnemiesOnRadar:
Nicholas Guerrero
	I couldn't think of a better procedure title, but basically it does just that, displays the enemies on your radar screen.  It will involve the component vectors once again.  Shouldn't be too hard.

DispLaserFire:
Justin Palmer
	This procedure involves converting the weapon fire into a polygon, so that it can be drawn simply by calling the DrawPoly routine.  Since laser fire moves at the speed of light, laser fire can essentially be assumed to either be there, or not there, so we don't need to draw laser beams moving through space.

DamageDeal:
Nicholas Guerrero
	Every hit you take without shields up, you will get a random chance for where the damage is dealt.  Damage can be dealt to shields, engines, weapons, or the hull, and who knows, maybe life support (there will then be a "dead" ship floating around in space...).

SortShips:
Nicholas Guerrero
	Sort the ships in the order from farthest to closest to you, so that you know which ship to draw first and which to draw last.  This procedure will also sort weapon fire.  It uses some component vectors, some point to line distance equations, and a sorting algorithm (probably bubble sort for simplicities sake).

DispPlanet:
Justin Palmer
	If time permits, and ONLY if time permits, we'll have maybe a couple of moons or a planet for us to fly around / drive in to.  Kind of difficult.  It wouldn't be too difficult if the planet was just one color, but that would be fairly unrealistic and kind of dull.  How exactly it will work will depend really on what is easiest and what time allows.

Intro:
Michael Vachanastienkul
	Show the intro.  We might not have an intro.  We would rather have a really fun, working game then a marginally operational game with a nifty intro.  It just seems right to put it in here anyway.

Setup:
Justin Palmer
	Allow you to customize your ship.  May or may not actually have this.  In a game that was going to be sold, this would be a necessity, but since this is just for demonstration, we can forgo the actual niceties of the game and just try and get a really fun playing game.