Tom's Plasma!                                 by Tom Dibble, Copyright 1994


                              *TPLAS MANUAL*



AUTHOR'S NOTE:

Well, you asked for it!  This is Tom's (that's me) Plasma.  It puts
a quick plasma fractal (*NOT* a sin/cos function!) up on screen,
then swims the fractal in a center window while cycling the colors. 
That's it.  But I think that deserves some explanation, don't you?


First off, what is plasma?

The plasma display implemented here falls into a class of images
called "Fractals".  A fractal can be zoomed in infinitely without
loss of detail.  Although I do not allow you to zoom in on this
particular fractal, the difference between 'fractal plasma' and
'sin/cos plasma' is readily apparent.  The only real commonalities
is that both generate a fully continuous array of values.  In
certain applications, the values in the array are used as
elevations or terrains of ground.  In this application, the values
are represented by color.

The main difference between these two types of plasma, aside from
the obvious visual difference, is that fractal plasma utilizes a
random value by its very definition, and therefore is different
every time it is generated.  Sin/cos plasma is a set function,
usually implemented with zero random nature, and therefore does not
change between viewings.


Okay, so what's this "swimming" thing?

For lack of a better name, the display technique I've used here I
will refer to as 'swimming'.  I originally came across swimming in 
a program called "JCL-Plasm" by Jeremy Longley.  He claims to have
copied the effect from Thomas Hagen.  Both implementations of
swimming involved using a sin/cos plasma rather than a fractal
plasma.

Swimming can best be described in a simple form of one pointer.  A
large plasma fractal is generated.  Next, a pointer is assigned. 
This pointer will define the top-left corner of the area of the
plasma fractal which is to be displayed.  In my implementation, 1/4
of the fractal is displayed at a time in the swimming window, which
means the display extends 160 pixels to the right and 100 pixels to
the bottom of the pointer.  Next, this pointer is moved about on
the large plasma fractal.  The exact pattern the pointer follows is
defined in the data file, and is a pro-generated sin/cos function.

Next, we make it twice as complex (and much, much more
interesting!) by adding a second pointer.  To display both pointers
in the same window, we simply add the pixel values together.  Roll-
arround is inevitable in such an arrangement, and if you look at
exactly how the adding is done you will see that roll-around on one
pixel will likely cause the pixel to its immediate left to be off
by one, but this is unnoticeable and ignoring it greatly increases
the speed we can go at.

The result is a window 1/4 the size of the screen which holds a
moving, bubbling plasma-looking mess.  It's hard to explain; you'll
just have to look for yourself!


Would you like to do any miscellaneous rambling?

Yes I would, thank you!

Everything in this little program has been around for a while, as
far as I can tell.  Certainly isn't cutting-edge!  The only really
new and original thought which went into this went into speeding up
the plasma generation section of the code (by upwards of ten
times!).  As I have said before, the plasma fractal is based on
random values.  Random values take a lot of time to calculate
because they involve several rather inefficient instructions
(namely, multiplies and divides) to be made by the CPU.  Since I
already had a data file for all of the movement pointers and color
palette data, I decided I might as well have 64 kilobytes of random
values in there as well, pre-computed to save time.

But wait! you say.  It's different every time, isn't it?!?  And the
answer is, yes, it is.  That is because the random number
'generator' (the code which reads the number from an array in
memory) uses a pointer which tells it which number is next in the
sequence.  At program start-up, this number is initialized to a sum
of the hour, minute, second, and hundredths of a second on the
system clock (which is also how a random number generator is
initialized, btw).  Thus, though the sequence is essentially the
same every time you run it, the number for each call to the random
number generator is different.

Secondly (and lastly!) this is my first true assembly program.  And
it shows.  I have been programming in 'C' for a good three years
now (as of this weekend, I believe!), but that is hardly the same
as programming in assembly, is it?  Furthermore, I'm not a
computer-science major here in college; I'm a Chemical Engineer. 
I have taken one class which had anything at all to do with
computers last year, and learned everything else I know from a few
books here and there and, most importantly, the UseNet.  Why am I
telling you this?  So that you know, as you laugh to yourself about
my coding style, that I'm certainly not doing this as a living!  I
coded this because I enjoyed it, and I needed something new and
interesting to put up on my screen.

With that in mind, I hereby give full permission to anyone reading
this note to use all code listed herein in any manner which he or
she sees fit, so long as I am mentioned in the credits and any code
directly derived from my own allows these same freedoms of use. 
That means, use it as you want, give me credit, and don't stop
anyone else from using it.

If you want to contact me about anything here, this is where I can
be reached until May, 1996 (or 1995, if I don't get into the MS
program!):

          tomster@wpi.wpi.edu

Or, via the good old post office, at

          Tom Dibble
          WPI box 2466
          Worcester, MA  01609

My mailbox is always open!

                                                                 Tom Dibble
                                                                    3-18-94


KEYBOARD COMMANDS:

          <Space>   Toggle the swim window on and off.
          <Enter>   Generate a new fractal.
          '1'-'3'   Variable smoothness.  '1' (rough) is default.
          <Esc>     Get the hell out of here!


DATA FILE:

The data file for this revision of the program (1.1) is revision 1.1.
An earlier data file (made by PLASDAT version 1.0) will not work
properly as the color section for that version was ten times as large
(for no real reason; I still only read 4 palettes).  Likewise, this
version of the data file will not work with an earlier version of the
program.  The result of using revision 1.0 with this data file would
be a "Random" array filled with -1 or 0:  whichever, an un-interesting
display.

The data file is somewhat large at >100k, but it holds information
vital to the program.  The first 40,000 bytes is movement data for
the two pointers.  This is an expansion of a sin/cos function.  The
next 3,072 bytes is the color palette.  Currently, the palette holds
four full palettes, or 1024 colors.  Each byte is a red, blue, or
green index from 0 to 63.  The last 64k is the array of random numbers
for the plasma generator.


REVISION HISTORY:

This is by no means a finished work.  I don't know how much more
I'll do with it before sending it to the great archive in the sky,
but, time permitting, I plan to do a bit more with it at least. 
Some delays in the code would be nice, so that it doesn't blur by
so bad on 486's and lord knows what it would do on a pentium! 
Geesh, just thinking about the speed-up with a decent video card or
VLB ...  Anyways, this is where it is now and where it's been, for
what it's worth.

March 19, 1994:  Revision 1.1

     Fixed all bugs which had caused anomalies in the fractal
     (involved overflow of byte values).  Shrunk the data file by
     about 28k by reducing the palette stored to that which we used
     (four full palettes, not 40).  Added lots of keyboard
     commands:  <Space> to toggle swim window on and off, <Enter>
     for a new fractal; '1', '2', and '3' for progressively
     smoother fractals ('1' is default).  <Esc> is now the only key
     which exits.  This is also the first version to be uploaded
     for public consumption (I had 1.0 all packaged and ready to
     go, then decided I'd better fix those bugs ...  and I suppose
     I got carried away ...  :->  ).  Source code, for what it's
     worth, included in package, along with data file generator
     source and executable.  Oh, I cleaned up the code a bit as
     well, using the ARG directive rather than obscure equates,
     adding a few helpful comments, etc.

March 3, 1994:  Revision 1.0

     The first working version!  Start it up, watch it go!  Hit any
     key and it's outta there!  Simple, but cool.
