Documentation cleanup.
[vms-empire.git] / NEWS
1                         vms-empire news
2
3 See vms-empire.spec for more recent news.
4
5 1.4: Thu Aug  1 14:53:41 EDT 2002
6         Packaging tweaks.  RPM spec fixes.  READ.ME broken up into
7         READ.ME and NEWS.  Obsolete bug notes removed.  Option -f to
8         set savefile added.  I'd like to move the documentation to XML, 
9         but can't yet because db2man doesn't render tables.
10
11 1.3: Fri Apr 19 05:13:33 EDT 2002
12         Walt Stoneburner's cleanup patch addressing all compiler errors and 
13         warnings, both in debug and in production mode; works with GCC v3.0.3.
14
15 1.2: Fri Jul 28 01:10:00 EDT 2000
16         The victory-odds table in previous versions was seriously buggy.
17         I folded in corrections from Michael Self.  I also took changes
18         from James T. Jordan <kermyt@earthling.net>, who wrote some
19         speedups, added ANSI prototypes, and cleaned up code.
20
21 1.1: 1994/12/01 16:07:03 
22         I colorized and speed-tuned this and added a
23         save-interval option. 
24
25 The rest of this history is Chuck Simmons's original notes.  Because
26 there are so many other Empire games out there now (all descended from
27 this one!), I've reverted to the VMS Empire name.
28
29                                         -- Eric S. Raymond
30
31 History
32
33         Apparently, this game was originally written outside of Digital,
34         probably at a university.  The game was ported to DEC's VAX/VMS
35         from the TOPS-10/20 FORTRAN sources available around fall 1979.
36         Ed James got hold of the sources at Berkeley and converted
37         portions of the code to C, mostly to use curses for the screen
38         handling.  He published his modified sources on the net in
39         December 1986.  Because this game ran on VMS machines for so
40         long, a previous version is known as VMS Empire.
41
42         In early 1987 I reverse engineered the program and wrote a
43         version completely written in C.  In doing this, I used lots
44         of structures and defined constants, and I attempted to make
45         the code flexible and easy to modify.  The algorithms used
46         in this C version are completely new, the names of the commands
47         have been changed to be more mnemonic, and new commands have
48         been implemented.  Only the format of the display is the same.
49         I suspect that many of my changes are slower and less
50         intelligently implemented than the originals.  Also, I have
51         not implemented some of the original functionality.
52         However, my hope is that the commented C sources I have written
53         will prove far easier to modify and enhance than the original
54         FORTRAN sources.  If you make changes for the better, by
55         all means send Ed James and I a copy.
56
57         The basic game has been heavily modified.  I've changed the
58         types of objects built, modified the parameters on others,
59         and added lots of new kinds of movement functions.  Read
60         the man page for a complete description.
61
62         The file 'bugs' contains lots of ideas for enhancements,
63         and describes the bugs I haven't been able to find.
64
65 Final Notes
66
67         Unfortunately, I have a rather powerful mainframe at my
68         disposal which is somewhere between 10 and 40 times as
69         fast as a 68020 based computer.  This means I can afford
70         to use extremely inefficient algorithms.  I suspect that
71         running this program on a smaller machine, such as a Sun
72         workstation or Vax will not be overly rewarding.  In particular,
73         the computer will take a very long time to move its pieces,
74         and it may not be desirable to save the game after every move.
75         (You mean your system doesn't write out 1/2 megabyte files in a
76         few milliseconds?)  This second problem is easily fixed, but
77         I don't yet have any good ideas for fixing the first problem.
78
79         The size of a saved file can be easily tuned by reducing the
80         LIST_SIZE constant in empire.h.  The only current simple tweak
81         for making the computer move faster is to reduce the size
82         of a map.
83
84 Chuck Simmons
85 amdahl!chuck
86
87 Ed James
88 edjames@ic.berkeley.edu
89 ucbvax!edjames
90
91         The low-end PCs of 2002 are more powerful than Chuck's 1987 mainframe.
92         Performance tuning isn't the issue it once was. :-)
93
94         My changes enable color on machines with terminfo color support, for
95         a dramatic improvement in appearance and readability of the display.
96         Color support, if present, will be auto-detected at compilation time.
97
98         They also implement and document a `save-interval' option, addressing
99         one of the misfeatures noted in the bugs file.
100
101         I've also tweaked the sources so they compile clean under GCC -- they
102         assumed the older K&R model of forward reference, causing many warning
103         references.
104
105         Finally, I've sped up expand_perimeter by cutting down on the
106         number of array references it has to compute. This eliminates several
107         multiplies from the inner loop, and is a technique that could be
108         applied much more widely in the code.  If efficiency matters that much
109         to you, maybe you need to get outside more.
110
111 Eric S. Raymond
112 esr@thyrsus.com
113 (home page: //www.tuxedo.org/~esr/)