1XSTAR(6) Games Manual XSTAR(6)
2
3
4
6 XStar Version 2.2 - X11 animated n-body solver
7
9 xstar [-hrRMv] [-b stars] [-g geometry] [-d host:display] [-t timeout]
10 [-D delay] [-B buf_factor] [-c star_color] [-C bg_color] [-a float] [-m
11 [taylor3|rk4|gpemce8|ab7|am7]] [-l float] [-T num_pts]
12
13
15 XStar is an X11 client that ``solves'' the n-body problem, and displays
16 the results on the screen. It starts by putting a bunch of stars on
17 the screen, and then it lets the inter-body gravitational forces move
18 the stars around. The result is a lot of neat wandering paths, as the
19 stars interact and collide. Try using the display mode options (-c,
20 -C, -R, or -M) to make things more colorful.
21
23 XStar has the following options:
24
25 -h Display the usage message and exit.
26
27 -b stars
28 Select the number of stars to initially have in the star system.
29 The default is 15 stars, the minimum is 2 and the maximum is
30 249.
31
32 -r Use root window.
33
34 -g [=][<width>x<height>][{+-}<xoffset>{+-}<yoffset>]
35 Selects the initial window size and location. If the -r option
36 is also selected, then the offset is used to move the "center of
37 the star system" around. That is, you can use the -g option to
38 move the interesting stuff to a free spot of your screen.
39
40 -d host:display
41 As in -d spacsun:0.0 or -d unix:0.0.
42
43 -t timeout
44 Use XStar as your screen saver with the given no-activity time‐
45 out value (in seconds).
46
47 -D delay
48 Periodically wait for 'delay' milliseconds to keep from using
49 100% of the CPU. The default is 0 ms. This doesn't always work
50 incredibly well to reduce the CPU usage because most Unix sched‐
51 ulers notice that XStar is not using as much CPU as it could and
52 they increases XStar's priority. On the other hand, it does
53 make the display rate vary less as collisions decrease the num‐
54 ber of stars.
55
56 -c star_color
57 Select the color of the stars. The default is White. Turns of
58 the implicit -R option.
59
60 -C bg_color
61 Select the color of the background. The default is Black.
62 Turns of the implicit -R option.
63
64 -R Rotate the star colors through the Rainbow. This is the default
65 unless the -c or -C options are used. Very pretty, but uses up
66 48 color slots. This causes each star track to change colors as
67 time passes, but at any given time, all stars have the same
68 color. Also available with the 'r' runtime command.
69
70 -M Assign multiple star colors. Also uses up 48 color slots. At
71 any given time, each star has a unique color (unless there are
72 too many stars to do this). This makes it much easier to see
73 where a star has been. Also available with the 'm' runtime com‐
74 mand.
75
76 -a value
77 Adjusts the accuracy of the position calculations by a factor of
78 ``value''. The larger the value, the more accurately XStar sim‐
79 ulates the real world but the slower it runs. The value can be
80 any floating point number greater than zero. The default value
81 is 1.0. Any value greater than zero is valid, with values below
82 1 decreasing the accuracy and values above one increasing it.
83
84 -m taylor3|rk4|gpemce8|ab7|am7
85 Selects the method to use for updating the star locations and
86 velocities. The default method is ab7.
87
88 taylor3
89 Use a taylor series expansion to get an order 2 method,
90 but then uses previous acceleration values to extend it
91 to a 3rd order method. This method is the fastest method
92 and for accuracies below .8 (-a .8), it is also the most
93 accurate.
94
95 rk4 Use the Runge-Kutta method of 4th order. It is over 4
96 times as slow as taylor3, but it is not 4 times as accu‐
97 rate. It is used internally to initialize the taylor3,
98 am7 and ab7 methods.
99
100 gpemce8
101 Use an 8th order Gragg's polynomial extrapolation method
102 with modifications for conservation of energy to make it
103 a discrete mechanics method. This is by far the most
104 accurate method, and when it's accuracy breaks down, the
105 resulting star system preserves the constants of motion,
106 that is, it conserves the energy of the system, the cen‐
107 ter of gravity, the linear and angular momentum, etc. It
108 is also by far the slowest method and probably not useful
109 except on a very fast machine or when you are using it as
110 a benchmark to compare other methods.
111
112 ab7 Use a 7th order Adam-Bashford method. This is the
113 default and for accuracies in the range of .8 to 4, it is
114 the most efficient method. It is slightly slower than
115 the taylor3 method, especially when there are only a few
116 stars.
117
118 am7 Use a 7th order Adam-Moulton predictor-corrector method.
119 It is about twice as expensive as ab7, and not a whole
120 lot more accurate.
121
122 -l float
123 The minimum distance between stars before they collide. The
124 default is one pixel. This value should be increased when
125 decreasing the accuracy. You can also decrease the collision
126 distance to be less than one pixel if you greatly increase the
127 accuracy, but results can be confusing since entire loops could
128 be contained within a single pixel. If this value is set too
129 small for the current accuracy, then the star system will star
130 displaying strange behaviors.
131
132 -T num_pts
133 The number of points to display as star trails. The default is
134 16384 points, the minimum is 512 and the maximum is 24575. If
135 you use a value less than the minimum, then no points will be
136 remembered. Instead, the star trails will not erase themselves
137 and the screen will be periodically cleared. Using the -T 0
138 option will greatly reduce the memory requirements of XStar.
139
140 -B buf_factor
141 This changes the amount of buffering to be done with the X
142 server. The default is 1.0, but any number greater than zero
143 can be used to increase or decrease the buffering. If the stars
144 appear to move in a jerky fashion, then you should decrease the
145 buffering to a value between 0 and 1. If there is too much
146 server/network load being generated by XStar, then increase the
147 buffering factor.
148
149 -v Display verbose internal debugging information. Several -v
150 options will make XStar more verbose.
151
153 When XStar is running, it will accept a few commands from the keyboard.
154 They are:
155
156 d Add an immobile collapsar/gravity well.
157
158 e Erase the star trails.
159
160 n Reinitialize the star system with a new set of stars.
161
162 + Add a star to the current star system. All future star systems
163 will also have an additional star.
164
165 - Delete a star from the current star system. XStar will try to
166 delete the "least interesting" star. Often the deleted star
167 will be off the screen. All future star systems will also have
168 one less star.
169
170 m Toggle to ``multiple color mode'', where each star has its own
171 color.
172
173 r Toggle to ``Rainbow mode'', where the stars will change color
174 with time.
175
176 p Pause the updating of the screen. Actually, XStar will continue
177 to update the screen, but there will be a 3 second delay between
178 updates. This is useful if XStar is using up too much CPU and
179 you want to stop it for a short period of time.
180
181 Press p again to return to full speed.
182
183 q Quit running XStar.
184
186 If you find the system running too quickly, you can do any of the fol‐
187 lowing things:
188
189 1) Use the -D option to add a delay between updates. This also
190 keeps XStar from using 100% of the CPU.
191
192 2) Use the -a option to increase the accuracy of the system.
193
194 3) Use the -b option to add additional stars. Doubling the number
195 of stars will make XStar run about 4 times as slow.
196
197 4) If you have increased the accuracy, you can then also slightly
198 decrease the collision distance with the -l option. Don't over
199 do it though, or you will start seeing strange things happen.
200
201 5) Use the -m option to select a more accurate, but less efficient
202 method such as rk4 or gpemce8.
203
204
205
206 If you find the system running too slowly, you can do any of the fol‐
207 lowing things:
208
209 1) Use the -b option to decrease the number of stars.
210
211 2) Use the -a option to decrease the accuracy of the system. You
212 probably will want to change the collision distance a little bit
213 also by using the -l option.
214
215 3) Use the -m option to select a less accurate, but faster method
216 namely taylor3. If you decrease the accuracy below .8, taylor3
217 will be more accurate than ab7.
218
219 4) Buy a faster computer, get a better optimizer for your compiler,
220 or implement a faster method of calculating the star locations.
221
222
223
224 If you find the that XStar is using too much memory, you can do any of
225 the following:
226
227 1) Use the -T 0 option to eliminate the star trails. (Saves about
228 200k.)
229
230 2) Do not use rainbow mode or multi-color mode. (Saves a little
231 bit)
232
233 3) Recompile XStar to use a smaller value for HASH_TABLE_BITS.
234
236 XStar's author is Wayne Schlitt, wayne@midwestcs.com
237
238 All comments, bug reports, bug fixes, enhancements, etc are welcome.
239 Send them to me at wayne@midwestcs.com.
240
241 This program started out as a heavily modified version of XGrav, which
242 was written by David Flater (dave@case50.ncsl.nist.gov) and posted to
243 alt.sources on 1/21/95. I liked the program enough that I was really
244 interested in it, but I didn't like it enough to leave it alone. The
245 idea was Dave's, but I think that very little of his code is left.
246 There is probably more code left from XSwarm, which Dave used to imple‐
247 ment the X port of his n-body problem solving code. Xswarm's author is
248 Jeff Butterworth (butterwo@cs.unc.edu).
249
250 Like XGrav, any claim to this program that I have (which isn't much) is
251 under the GNU General Public License. Have fun with it.
252
253 Documentation converted to ``man'' format by Jeff Mogul
254 (mogul@wrl.dec.com), who also added the -m option.
255
256
257
2584th Berkeley Distribution December 21, 1996 XSTAR(6)