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