NOTE: You require X-windows to run this game.

     Here is the source to X-Asteroids, version 2.  The compiled code is 230K
on my system, so don't ask for it unless you absolutely can't get it to
compile.  Besides, it probably wouldn't run on anything at all different
than our SPARCstations.  They run X11R4, but I believe it works on R3.

     Thanks to David Elliot, Ken Whaley, and Christophe Moret for
finding 2 bugs in the program.  The first version didn't run on color clients.
     There are 2 known bugs:
     1. After the game is over, if you leave the window
alone, the enemy spaceship will eventually destroy all the asteroids, and
a new level will start with your (free) spaceship in the center.  From then
on you can play the game indefinitely, since when you die, you will have -1
ships, and the program stops when you have 0 ships.  I consider this a
feature, and have no intention of removing it.
     2. While the game is paused (with a 'p'), you can input commands to
change direction and thrust, and they will be executed.  So this is a way
of cheating.  This could be corrected, but why bother?  If you don't like
it, don't do it.
     Also, David Elliot (dce@sonyusa.sony.com) says that he had to put
an XSync(disp) after the XDrawLines call or he would get protocol errors.

     On anything slower than a SPARCstation 1 - say, a Sun 3/60 - it
will really drag.  The code is not optimized because the XWindows
calls take the vast majority of the time.  I tried, for instance,
reading sines and cosines from a table instead of calculating them -
it made no noticeable difference in speed.  Similarly, the collision
detection could be optimized only to check objects nearby - but why
bother.  Same goes for using registers, pointers to frequently-referenced
array elements, etc.  It MIGHT make a significant difference in runtime
if you replace the vector drawing with bitmaps.
     The vast majority of time seems to be used in erasing the pixmap
each round, & there isn't much to do about that.  My tests have indicated
that blanking individual asteroids rather than the whole screen would
take comparable time, unless you had a complicated routine to optimize
blanking.
     This is only the 2nd program I have written in C, so I may have written
poor code.  If you have any suggestions for better coding, please tell me.
(Unless you're just going to complain about my global variables and goto's
and quota Dijkstra at me, in which case you can direct your comments
to anal-retentive@ivory.tower.EDU where they will be better appreciated.)

Changes that would have been made if I were being paid to do this:

     New asteroids shapes that actually look like asteroids would be nice.
You could also specify a different graphics context for the first line of
each shape, so it could be invisible.  (No spokes on the asteroids.)
     Changing the collision-detection routine to actually check for line
intersections rather than bounding-circle intersection would be nice.
If you do this, only check for line intersections on objects that are
sufficiently close to the ship.
     Enough people have mentioned that they have SPARCstations that I
might add sound effects to it.  The SPARCs have a sound chip, but
anything I did with it would be totally incompatible with anything else.
     If you modify this program, please send me a copy.
     Please send any comments, suggestions, bug reports, small unmarked
bills, etc., to

Phil Goetz
goetz@cs.buffalo.EDU

If I could go back in time and change 20 lines in the Bible,
I could alter Western civilization beyond recognition.
