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).
