packages icon
XGrav by DWF, dave@case50.ncsl.nist.gov
Version 1.0.1, 1/20/95

This program is a hack of XSwarm 2.3 by Jeff Butterworth.  I know nothing
about X programming, so I modified a program that was pretty close to what I
wanted.

Instead of a swarm of bees, this program now shows the gravitational
interaction between a number of "stars."  The trails are left on purpose
since I think it's more interesting that way.

Insofar as I have any claim to this program (and I haven't much since it's
a hack of somebody else's) the GNU General Public License would apply.  My
contributions here are free, but they come with absolutely no warranty and
nobody can get a patent on them.

Command Line Options
--------------------

         -h|q|?            display this message
         -r                use root window
         -g geometry       window geometry
         -d host:display   X server to connect to
         -t timeout        screen saved after 'timeout' seconds
         -D delay          non-blocking delay between updates (milliseconds)
         -b stars          number of stars
         -c star_clr       star color
         -C bg_color       background color

         Press d in the window to add a gravity well.
         Press e in the window to erase trails.
         Press q in the window to quit.

Helpful Hints
-------------

1.  The default delay is 0.  Setting a nonzero delay slows it down a lot.
    To slow it down a little, add stars.

2.  You get nine stars by default.  The area over which the stars are
    distributed when you start up gets bigger the more stars you ask for.
    Too many stars too close together results in everything falling into
    a black hole, which is not so entertaining.  The default window size
    is always 512x512, so you might want to specify a bigger window if you
    have a lot of stars.

3.  In screensaver or root window mode, the program automatically starts
    over every 2 minutes; otherwise it runs until you stop it.  The
    keypress commands (d, e, q) only work in normal window mode.

4.  The d command adds a stationary gravity well.  Since its position is
    fixed it is easier to see elliptical orbits when they happen.  The d
    is for destroy, since most of the stars won't orbit but will fall
    right in.  Press d several times in a row to see some interesting
    trajectories.

5.  The e command is for erasing the old trails in case the screen gets
    cluttered and you can't see what is happening.

Known Bugs
----------

The pointer interferes with the screensaver.

Big enough collapsars will become stationary like gravity wells.

Collisions sometimes don't look right.

Root window mode may not work on SGIs.

History
-------

Updated README 1/20/95.


Version 1.0 patch 1, 1/17/95.  Don't include getopt.h on Suns -- it ain't
there.  Show patchlevel in title bar.  Reduced the amount of energy absorbed
in a collision from 50% to 25%.  Removed gcc-specific -Wall from Imakefile.


Version 1.0, 1/15/95.  This is actually the fifth time I have implemented an
n-body program.  The first implementation was in BASIC on a VIC-20.  It didn't
work very well.  I thought there was something I was missing in the algorithm.
In retrospect, the algorithm was correct; what I did wrong was set the
gravitational constant too high because I wanted to be able to see things
moving on the screen.  The VIC-20 could not do enough iterations per second to
get acceptable accuracy in real time.  The smaller the gravitational constant,
the greater the accuracy but the slower the motion.

The second implementation was a parallel version in Occam on a Transputer
hypercube.  That one was a project for a parallel programming class.  It worked
pretty well, but it was a short victory since it was about the least portable
code I've ever written.  This led immediately to the third implementation,
which was a rewrite of the VIC-20 BASIC on a Commodore 128 to behave more like
the Occam version.  It worked, but it was too slow.

The fourth implementation happened when I got my 386, under Turbo C++.  None of
Borland's spiffy graphics drivers did what I needed, so I just POKEd the pixels
into display memory like I did on the Commodore.  I later changed that program
slightly to compile under GCC (DJGPP).  The syntax was different, but I was
still using direct graphics.

Now I have finally gotten stupid enough to blow a weekend getting it to run
under X.  This is the fifth implementation.  The sixth one will probably be in
3-D.