home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / games / volume13 / xasteroids2 / part01 / README < prev   
Text File  |  1992-04-10  |  5KB  |  100 lines
  1.      Here is the source to Xasteroids, version 4.  Changes include better
  2. collision detection, shields, & explosions.  Many thanks to Peter
  3. Phillips.  If anyone wants the shorter & simpler version 3.1, write me.
  4.  
  5.      This program runs under UNIX in the X-Windows or OpenWindows
  6. environment.  It could probably be modified for other operating systems
  7. without difficulty.  I compile it under quasi-BSD with this command:
  8.  
  9. cc -I/util/X11/include -L/util/X11/lib ast.c -lX11 -lm -o ast.out -O
  10.  
  11. That is, include files /util/X11/include, use the library in /util/X11/lib,
  12. source file ast.c, use the X11 library and the math library, object file
  13. will be ast.out, and Optimize.
  14.  
  15.      Cut the stuff below into ast.docs and ast.c.  Then compile ast.c.
  16. I know it is bad practice to put everything in one file, but I wanted to
  17. make it easy to compile.
  18.  
  19.      If you like the game, please send $5 to
  20.  
  21.     Phil Goetz
  22.     4023 Huckleberry Row
  23.     Ellicott City, MD 21043
  24.  
  25.      Even if you don't register, please send a note to my e-mail address
  26. so I know how many people use Xasteroids.  Then I may be motivated to
  27. update it again, or write new programs...
  28. Send any comments, suggestions, bug reports, modifications, etc., to
  29.  
  30.     goetz@cs.buffalo.EDU
  31.  
  32.      Lots of people have complained that Xasteroids wouldn't run fast
  33. enough on their display.  I had different ideas on how to affect the speed,
  34. and implemented all of them.  So Version 3 came with more speed controls
  35. than most people like to think about:
  36.  
  37.      1 2: Scale of movement (default 1):  Increasing this causes each object to
  38. move further every turn.
  39. Advantage:    Can be changed in smaller amounts than moves/frame.
  40. Disadvantage:    Increasing it too much can cause bullets to fly through
  41. asteroids without hitting them.  Looks jerky.
  42.  
  43.      v b: Moves per frame (default 1):  Increasing this causes the main loop to
  44. execute more times before updating the display.
  45. Advantages:    Avoids the problem of bullets flying through asteroids.
  46. Disadvantages:    Increases only by integer amounts.
  47.  
  48.      , .: Delay:    Used when your client runs too fast to play comfortably.
  49.  
  50.      n m: Object size:    If your client is too slow, decrease the size and resize
  51. the window to a smaller size.  Then type 'x' to use XFillRectangle erase.
  52.  
  53.      x: XFillRectangle erase:  Use XFillRectangle to erase the entire pixmap
  54. each turn.  Faster on small windows.
  55.  
  56.      u: Undraw erase:  Erase each object line-by-line.  Faster on big windows.
  57.  
  58.      Playing with scale of movement, object size, and window size can give you
  59. very different games.
  60.  
  61.      There are 3 known bugs, which apply to all versions:
  62. 1. The window does not accept keyboard input.  I think this only happens
  63. under some versions of OpenWindows.  Works under mine.
  64. 2. While the game is paused (with a 'p'), you can
  65. input commands to change direction and thrust, and they will be executed.
  66. So this is a way of cheating.  This could be corrected, but why bother?
  67. If you don't like it, don't do it.
  68. 3. Once, the game lost count of numasts and refused to give me a new asteroid
  69. field.  Only once.  I have no idea why.  One other person has also reported
  70. this.
  71.      Also, David Elliot (dce@sonyusa.sony.com) says that he had to put
  72. an XSync(disp) after the XDrawLines call or he would get protocol errors.
  73.  
  74.      On anything slower than a SPARCstation 1, or on any color screen,
  75. it will really drag.  There should be a way to set color screens to use
  76. a bitmap of depth 1, but I don't know how.  Please tell me if you do.
  77.      The code is not optimized because the XWindows
  78. calls take the vast majority of the time.  I tried, for instance,
  79. reading sines and cosines from a table instead of calculating them -
  80. it made no noticeable difference in speed.  Similarly, the collision
  81. detection could be optimized only to check objects nearby - but why
  82. bother.  Same goes for using registers, pointers to frequently-referenced
  83. array elements, etc.  It MIGHT make a significant difference in runtime
  84. if you replace the vector drawing with bitmaps.  It runs a LOT slower on
  85. color displays.
  86.      The vast majority of time seems to be used in erasing the pixmap
  87. each round, & there isn't much to do about that.  My tests have indicated
  88. that blanking individual asteroids rather than the whole screen would
  89. take comparable time, unless you had a complicated routine to optimize
  90. blanking.
  91.      If you modify this program, please send me a copy.  Modifications
  92. I would like to see include:  sound (esp. for Sparcstations), drawing
  93. the asteroids to pixmaps so they can be put on the screen quicker
  94. (though not much quicker - the X calls seem to take most of the time),
  95. an options screen to set parameters such as speed, whether bullets
  96. can be fired before your current ones are dead, whether to start in the
  97. center of the screen between levels), a permanent high score file
  98. to be displayed sometimes between games, and jagged fractal asteroids
  99. (not just removal of the lines to the center; I like those).
  100.