### xasteroids-4.0 README file

         Here is the source to Xasteroids, version 4.  Changes include better
    collision detection, shields, & explosions.  Many thanks to Peter
    Phillips.  If anyone wants the shorter & simpler version 3.1, write me.

         This program runs under UNIX in the X-Windows or OpenWindows
    environment.  It could probably be modified for other operating systems
    without difficulty.  I compile it under quasi-BSD with this command:

    cc -I/util/X11/include -L/util/X11/lib ast.c -lX11 -lm -o ast.out -O

    That is, include files /util/X11/include, use the library in /util/X11/lib,
    source file ast.c, use the X11 library and the math library, object file
    will be ast.out, and Optimize.

         Cut the stuff below into ast.docs and ast.c.  Then compile ast.c.
    I know it is bad practice to put everything in one file, but I wanted to
    make it easy to compile.

         If you like the game, please send $5 to

    	Phil Goetz
    	4023 Huckleberry Row
    	Ellicott City, MD 21043

         Even if you don't register, please send a note to my e-mail address
    so I know how many people use Xasteroids.  Then I may be motivated to
    update it again, or write new programs...
    Send any comments, suggestions, bug reports, modifications, etc., to

    	goetz@cs.buffalo.EDU

         Lots of people have complained that Xasteroids wouldn't run fast
    enough on their display.  I had different ideas on how to affect the speed,
    and implemented all of them.  So Version 3 came with more speed controls
    than most people like to think about:

         1 2: Scale of movement (default 1):  Increasing this causes each object to
    move further every turn.
    Advantage:	Can be changed in smaller amounts than moves/frame.
    Disadvantage:	Increasing it too much can cause bullets to fly through
    asteroids without hitting them.  Looks jerky.

         v b: Moves per frame (default 1):  Increasing this causes the main loop to
    execute more times before updating the display.
    Advantages:	Avoids the problem of bullets flying through asteroids.
    Disadvantages:	Increases only by integer amounts.

         , .: Delay:	Used when your client runs too fast to play comfortably.

         n m: Object size:	If your client is too slow, decrease the size and resize
    the window to a smaller size.  Then type 'x' to use XFillRectangle erase.

         x: XFillRectangle erase:  Use XFillRectangle to erase the entire pixmap
    each turn.  Faster on small windows.

         u: Undraw erase:  Erase each object line-by-line.  Faster on big windows.

         Playing with scale of movement, object size, and window size can give you
    very different games.

         There are 3 known bugs, which apply to all versions:
    1. The window does not accept keyboard input.  I think this only happens
    under some versions of OpenWindows.  Works under mine.
    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.
    3. Once, the game lost count of numasts and refused to give me a new asteroid
    field.  Only once.  I have no idea why.  One other person has also reported
    this.
         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, or on any color screen,
    it will really drag.  There should be a way to set color screens to use
    a bitmap of depth 1, but I don't know how.  Please tell me if you do.
         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.  It runs a LOT slower on
    color displays.
         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.
         If you modify this program, please send me a copy.  Modifications
    I would like to see include:  sound (esp. for Sparcstations), drawing
    the asteroids to pixmaps so they can be put on the screen quicker
    (though not much quicker - the X calls seem to take most of the time),
    an options screen to set parameters such as speed, whether bullets
    can be fired before your current ones are dead, whether to start in the
    center of the screen between levels), a permanent high score file
    to be displayed sometimes between games, and jagged fractal asteroids
    (not just removal of the lines to the center; I like those).