Play and Learn 2/19941.ZIP/19941/EDUCICAL/LIFE050/README.050

Text File | 1994-02-04 | 13.1 KB | 232 lines

Notes on TurboLife version 0.50 (12/25/86) (PLEASE READ THESE!):

To contact me
=============
  Direct all problem reports, suggestions, complaints, cash donations etc. to
Bela Lubkin via USnail, Ma Bell, CompuServe or local BBS.  My various addresses
and numbers are:

USnail:
  Bela Lubkin
  406 Murray Ave.
  Aptos, CA  95003

Ma Bell:
  [phone] (voice)

CompuServe:
  73047,1112 (EasyPlex)

Local BBS (Santa Cruz, CA):
  "Filbo" on Pyrzqxgl, [phone] (Zend mail)

PLEASE CONTACT ME IF YOU FIND A BUG OR WANT TO SUGGEST A FEATURE!!!!  Apathy
sucks!!!

What has changed since version 0.39
===================================
  Most importantly, I converted the innermost loop of the generation routine
from Turbo Pascal to assembly language.  The first step was a straightforward
port to assembly language, making use of registers as much as possible.  This
resulted in a 3-to-1 speedup.  Next, I modified the algorithm in certain ways,
and "bummed" the code as much as possible.  This brought the speedup to about
4-to-1.  Finally, I ran into a program called FASTLIFE on a local BBS.  It had
radically different performance characteristics: it was much faster for densely
packed action, but much slower for sparse areas.  I spoke to the author, Dan
McMullen, and got some extremely useful ideas.  I had been dealing with a bit
at a time, in registers; I now deal with a byte at a time, as much as possible.
This brings the total speedup to 5.5-to-1 for the simplest figures, and an
amazing 16-to-1 for densely packed action.  My benchmark suite, which has a
great deal of variety in its tests, shows an overall speedup of 6.45 times.
Mileage may vary <grin>.  My heartfelt thanks to Dan!

  Other changes include:
    o Directory window: when saving or loading a file, if you give a wildcard
      filename such as *.LIF, a directory window pops up and you can select the
      desired file interactively.  The directory window is fully aware of the
      DOS 2.0 directory structure, and will let you walk about different
      directories.
    o Overwrite protection: you are asked before TurboLife will overwrite an
      existing file.
    o The Undo command will undo one Go, single step or Load command.  If Undo
      does not appear on your main menu, you don't have enough memory for it;
      you will need up to 32K more than you need to be able to run TurboLife at
      all, depending on your video board.  Total memory needs range from about
      105K on a CGA (Undo disabled) to about 220K on a VEGA Deluxe in 640x480
      resolution (Undo enabled).
    o Mutations: when mutations are enabled, a single, randomly chosen pixel
      may be changed in any particular generation.  How often this occurs is
      settable, anywhere from every generation to once per thousand
      generations.
    o Support for more graphics hardware:
        EGA with mono or ECD monitor (640x350)
        Olivetti M24/AT&T 6300/Xerox 6030 (640x400)
        Toshiba T3100 (640x400)                                (-experimental-)
        Video-7 VEGA Deluxe/QuadRAM QuadEGA Prosync (640x480)  (-experimental-)
      Any reports on the Toshiba T3100 and the VEGA/QuadRAM cards will be
      appreciated.
    o On graphics hardware with several resolutions available, you can choose
      which resolution to use.  This may be useful for looking at saved figures
      which make use of wrap effects.  FACTORY.LIF is an example of such a
      figure: it is interesting on any board, but particularly amazing at a
      resolution of 640x200.
    o When a file is loaded which was saved on lower resolution graphics
      hardware, a check is made to see whether any features of the saved figure
      were meant to wrap around the edges of the screen.  If the first and last
      lines of the saved image are found to be identical, the additional lines
      of the screen are filled with copies of that same line.  The same is done
      for the first and last columns of the saved figure.  This means that, for
      instance, "great circle" images saved on the CGA can be loaded on an EGA,
      at 640x350 resolution, without losing their continuity.
    o More stringent checking is done when files are loaded to ensure that only
      valid files are loaded.  (In particular, using the wrong function to load
      a .RUL or .LIF file will no longer appear to work while actually
      failing).
    o The rule "a dead pixel with no neighbors springs to life" may now be
      declared.
    o When changing rules, the entire screen is considered under the new rules,
      not just the points that had been active under the old rules.
    o File load/save status messages now stay on screen for 5 seconds or until
      a key is pressed.  These delays now work properly on the Tandy 2000.
    o Save files are now 1/2 as large as before.
    o WordStar key sequences are supported everywhere that keypad keys work;
      keypad keys do not require NumLock to be turned off, except the "5" key,
      used in the Rule editor.  Why IBM chose to make that key generate no data
      is beyond me...
    o Many bugs have been fixed.
    o Probably more that I forget.  It's been a year!

"Flicker between the graphics and text areas"
=============================================
  If you see a rapidly flickering point just to the right of the playing field
(to the left of the menu and other text), good!  You're supposed to.  While the
generation algorithm is thinking about a single line of the screen, it turns on
a point at the right of that line to show its progress.  This was put in the
program when it was more than 20 times as slow as it is now, and I was using an
8088 machine with 640x400 resolution, to boot.  While waiting up to a minute
for a generation to complete, it was good to have some indication that the
program hadn't crashed yet.  I've left the indicator in because it acts as sort
of a "heartbeat meter", giving you an at-a-glance idea of how fast the program
is moving at the time.  You can gain some insight into how the program works by
observing the indicator while playing with complicated figures.  For instance,
draw a line all the way across the screen horizontally.  Turn wrap on, Go, and
watch the indicator.

What's in the distribution ARC file
===================================
  The distribution ARC file contains this file (README.050), LIFE050.COM, and
DEMOS.ARC (a nested ARC file).  DEMOS.ARC expands to about 175K, so be
prepared.  Inside DEMOS.ARC are a number of rule sets and figures; unless
otherwise noted, all rule sets and figures, and their names, are my own.

The rule sets are as follows:
  LIFE.RUL - standard Life rules (John Horton Conway)
  3-4LIFE.RUL - 3-4 Life, as defined in "The Recursive Universe" (TRU)
  FREDKIN.RUL - Fredkin's Game (TRU).  Anything you enter is duplicated
  CRYSTALS.RUL - Homebrewed set of rules that make pretty crystals
  A.RUL - Slightly modified normal Life, has some interesting patterns
  FIRE.RUL - interesting rules that generate fire-like patterns -- try a
             vertical or horizontal bar, for instance
  LACE.RUL - makes lace-like patterns
  DOWN.RUL - inspired by Graeme McRae.  Any figure simply moves down the screen
  DOWNGROW.RUL - modified DOWN.RUL, sends interesting streamers down the screen
  OOZE1.RUL through OOZE4.RUL - four variations on a theme: rules that... ooze!

The figures are as follows:
  3WAY.LIF - An engineered 3 way collision
  R5OMINO.LIF - The famous R Pentomino (TRU).  1103 generations to completion
  OSCILLAE.LIF - An assortment of oscillators from TRU.  Left to right, they
                 are: Toad, Beacon, Clock, Pulsar, Figure 8, Pentadecathlon,
                 Barber Pole, Flip-flop, Galaxy, Tumbler, Clock II, stabilized
                 Shuttle, B Heptomino Shuttle, Glider, Lightweight,
                 Middleweight and Heavyweight spaceships
  FLOTILLA.LIF - An overweight spaceship with flotilla escort (TRU)
  ACORN.LIF - Another long messy figure, this one goes for 5206 generations
              before stabilizing (TRU)
  GLIDRGUN.LIF - A glider gun (TRU).  Includes an Eater (TRU) to consume the
                 gun's output
  MAKEGGUN.LIF - "Thirteen gliders collide to form a glider gun" (TRU)
  NEWGUN.LIF - "New gun", a different flavor of glider gun.  (TRU)
  MACHNGUN.LIF - A "machine gun" made out of multiple concatenated glider guns
  FACTORY.LIF - A glider factory made out of cooperating glider guns
  PUFTRAIN.LIF - Puffer train.  Given enough screen space, this eventually
                 stabilizes (becomes periodic), generating an ever-
                 lengthening tail of debris.  Stabilization occurs at
                 generation 5533, but there is not enough screen space on
                 any TurboLife-supported video board to see more than a hint
                 of the stabilization.  (2800 pixels horizontal would be
                 necessary to carry it out to full stabilization).  (TRU)
  OSCILLAE.3-4 - A bunch of oscillators from 3-4 Life (load the 3-4 Life rules
                 first -- these won't do much under normal Life rules).  Around
                 the outside, clockwise, ignoring duplicates, are: Ward
                 Christensen's object (I'll let him name it!), Broken T (TRU),
                 Bleeper (TRU), Frog, T (TRU), and Y.  On the next row in are:
                 3-4 Spaceship (TRU), 3-4 Clock (TRU), Shaker, Broken 3-4
                 Clock.  In the center are a Bullfrog and a Twombler
  YOW.CRY - an interesting initial pattern for the rule set "Crystals".  It is
            saved with mutations enabled, set at a low rate; you may also want
            to run it with mutations disabled entirely
  T-BARS.3-4 - a very interesting scenario for 3-4 Life
  MOREBARS.3-4 - similar to T-BARS.3-4
  CREATION.OOZ - let there be ooze!

Adding support for additional video boards
==========================================
  I am continually on the lookout for more video boards to add support for.
If you have a video board which does something beyond the standard IBM
640x200 mode, give me information on it and I'll try to support it.  Each
added board costs me something like 100 bytes of code, so I am not even going
to start worrying about it yet.

  What I need to know: I access the video memory of the board directly.  The
memory layout must be similar to the CGA's in that each scan line must
consist of contiguous bytes, each byte containing 8 pixels, the high bit being
the leftmost displayed bit.  Therefore, in order to plot, all I need to know
is the formula for the address of a scan line, given its vertical coordinate.
Thus for the CGA, BaseAddress(Y)=2000h*(Y AND 1) + 80*(Y DIV 2).  Other than
that, I must have the following information: the resolution; how to turn this
mode on; how to turn it off; how to generate text, if not through standard
BIOS writes; and most importantly, how to detect that a machine has this
capability.  I may end up forced to add a manual install-for-video-board
routine to the program, but I will not if I can possibly help it.  Additional
information that would be useful: how to modify the foreground and background
colors, if applicable.  Note that in all cases I'm interested in the highest
possible resolution of the card, and that in fact my code cannot support
multicolor modes like the CGA's 320x200; it can support multiplane setups
like EGA mono, but only by ignoring all but one plane.  Thus it may be
necessary to diddle palette registers to make a single plane look good.

Sigma SR400!
============
  IN PARTICULAR, I am all ready to support the Sigma SR400 board, with 640x400
resolution, but I do not know how to detect this board at runtime.  The
detection method must be unambiguous.  If you have an SR400, or have any
information on it, please let me know!

Thanks
======
  I want to thank John Conway for inventing Life; Piers Anthony and Martin
Gardner for making me aware of it; Dan McMullen for helping me refine my
generation algorithms; Kim Kokkonnen, Neil J. Rubenking, Doug Hogarth, Dave
Hoagland, Don Watkins, Joan Friedman, Grame McRae, Joe Kyle and many others for
helping me test the latest versions; and most especially the dozens of people
who have made comments and suggestions about the program even when I wasn't
actively soliciting responses.

  Believe me, I >like< getting suggestions and even bug reports.  Easy
suggestions may get implemented right away; bug reports will be dealt with as
quickly as possible.  Even if I don't take you up on your suggestion, I
appreciate knowing that you're out there and have enjoyed using my program.

  By the way, one suggestion that I am not going to take up is that of using
color as another dimension of the program.  I may eventually support the
ability to set the foreground and background colors of the playing screen, for
esthetics; I will not support color as an active part of the game.  It slows
things down, and the uses I've seen for color in Life games have seemed
contrived at best.

  Any input appreciated.

  -  Bela Lubkin
     December 25, 1986