From 49ea3d41233840c9ff5c8f3f89112f65a3035ad8 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Mon, 27 Sep 2004 15:21:43 +0000 Subject: [PATCH] Initial revision --- NEWS | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 NEWS diff --git a/NEWS b/NEWS new file mode 100644 index 0000000..cc936b1 --- /dev/null +++ b/NEWS @@ -0,0 +1,111 @@ + vms-empire news + +1.4: Thu Aug 1 14:53:41 EDT 2002 + Packaging tweaks. RPM spec fixes. READ.ME broken up into + READ.ME and NEWS. Obsolete bug notes removed. Option -f to + set savefile added. I'd like to move the documentation to XML, + but can't yet because db2man doesn't render tables. + +1.3: Fri Apr 19 05:13:33 EDT 2002 + Walt Stoneburner's cleanup patch addressing all compiler errors and + warnings, both in debug and in production mode; works with GCC v3.0.3. + +1.2: Fri Jul 28 01:10:00 EDT 2000 + The victory-odds table in previous versions was seriously buggy. + I folded in corrections from Michael Self. I also took changes + from James T. Jordan , who wrote some + speedups, added ANSI prototypes, and cleaned up code. + +1.1: 1994/12/01 16:07:03 + I colorized and speed-tuned this and added a + save-interval option. + +The rest of this history is Chuck Simmons's original notes. Because +there are so many other Empire games out there now (all descended from +this one!), I've reverted to the VMS Empire name. + + -- Eric S. Raymond + +History + + Apparently, this game was originally written outside of Digital, + probably at a university. The game was ported to DEC's VAX/VMS + from the TOPS-10/20 FORTRAN sources available around fall 1979. + Ed James got hold of the sources at Berkeley and converted + portions of the code to C, mostly to use curses for the screen + handling. He published his modified sources on the net in + December 1986. Because this game ran on VMS machines for so + long, a previous version is known as VMS Empire. + + In early 1987 I reverse engineered the program and wrote a + version completely written in C. In doing this, I used lots + of structures and defined constants, and I attempted to make + the code flexible and easy to modify. The algorithms used + in this C version are completely new, the names of the commands + have been changed to be more mnemonic, and new commands have + been implemented. Only the format of the display is the same. + I suspect that many of my changes are slower and less + intelligently implemented than the originals. Also, I have + not implemented some of the original functionality. + However, my hope is that the commented C sources I have written + will prove far easier to modify and enhance than the original + FORTRAN sources. If you make changes for the better, by + all means send Ed James and I a copy. + + The basic game has been heavily modified. I've changed the + types of objects built, modified the parameters on others, + and added lots of new kinds of movement functions. Read + the man page for a complete description. + + The file 'bugs' contains lots of ideas for enhancements, + and describes the bugs I haven't been able to find. + +Final Notes + + Unfortunately, I have a rather powerful mainframe at my + disposal which is somewhere between 10 and 40 times as + fast as a 68020 based computer. This means I can afford + to use extremely inefficient algorithms. I suspect that + running this program on a smaller machine, such as a Sun + workstation or Vax will not be overly rewarding. In particular, + the computer will take a very long time to move its pieces, + and it may not be desirable to save the game after every move. + (You mean your system doesn't write out 1/2 megabyte files in a + few milliseconds?) This second problem is easily fixed, but + I don't yet have any good ideas for fixing the first problem. + + The size of a saved file can be easily tuned by reducing the + LIST_SIZE constant in empire.h. The only current simple tweak + for making the computer move faster is to reduce the size + of a map. + +Chuck Simmons +amdahl!chuck + +Ed James +edjames@ic.berkeley.edu +ucbvax!edjames + + The low-end PCs of 2002 are more powerful than Chuck's 1987 mainframe. + Performance tuning isn't the issue it once was. :-) + + My changes enable color on machines with terminfo color support, for + a dramatic improvement in appearance and readability of the display. + Color support, if present, will be auto-detected at compilation time. + + They also implement and document a `save-interval' option, addressing + one of the misfeatures noted in the bugs file. + + I've also tweaked the sources so they compile clean under GCC -- they + assumed the older K&R model of forward reference, causing many warning + references. + + Finally, I've sped up expand_perimeter by cutting down on the + number of array references it has to compute. This eliminates several + multiplies from the inner loop, and is a technique that could be + applied much more widely in the code. If efficiency matters that much + to you, maybe you need to get outside more. + +Eric S. Raymond +esr@thyrsus.com +(home page: //www.tuxedo.org/~esr/) -- 2.43.0