HLA is a DOS program for making "height field" images.
Height field images can used in many ray tracing programs
as a way to define surfaces. Each point on a patch of the
x,z plane is associated with a corresponding pixel in the
image. The height at that point is given by the color of 
the image at that point.

Installing--
HLA.ZIP should all be unzipped into the same directory.  It is
probably best (easier in the long run) to create a directory named
HLA. Copy the HLA.ZIP file to the HLA directory and change to
to the HLA directory. Unzip the HLA.ZIP file in the HLA
directory. If using PKUNZIP, use the -d option:
        pkunzip -d HLA.ZIP


Some things you need to know to start HLA:
       1) In order to run HLA from DOS, the file CWSDPMI.exe
        must be in your PATH or in the directory HLA is being
        run from.

       2) The file HLA.HLP should either be
        in the directory HLA is being run from, or its
        location set with environment variable HLAHLP.

        Both of the preceding notes can be ignored if you unzip
        the entire package HLA.ZIP into the same directory,
        and start HLA.EXE using that same directory as the working
        directory.

       3) HLA requires: 386/486/Pentium, 640x480 256 color graphics,
        mouse.


HLA is a GUI shell for John Beale's famous HF-Lab. That is,
most of the functions of HF-Lab are part of HLA (including all
of the height field creation, filtering, and hf manipulation).
The main differences are in the interface especially in the 3d
viewing.

At least for now, the documentation for HLA is inexcusably incomplete.
Try to use the help functions in HLA. Please look at the HF-Lab.txt
file, which is the README file from HF-Lab by John Beale. 


I believe that all HF-Lab height field manipulation commands
are implemented almost identically in HLA. I say 'believe'
because I never did get HF-Lab to work quite right (which
was the original reason I started on this project) so I am
not sure what it was supposed to do in all cases. But most
of John Beale's original code is in HLA somewhere, though some
became redundant or irrelevant with the HLA interface.

If you are already used to HF-Lab you will notice at least two
limitations of HLA compared to HF-Lab.
1) HLA does not support running numerous scripts launched from a
batch file (a la 'demo.bat' included with HF-Lab). For example,
running demo.bat (with "hl" replaced with "hla") will run the
first script but then you will have to quit HLA manually in order
to continue the batch file.
On the other hand, HLA will run 'nested' scripts (i.e. scripts
called from within scripts), so you could write a script
that just says, for example,
     run script1.scr
     run script2.scr
     run script3.scr
2) For some reason I couldn't get the 320x200 full screen video
mode to work correctly so that is missing from HLA.


Creating new height fields:
HF-Lab commands are typed into the 'HL Command' box.
If you hit F1 or click on the question mark ('?') button,
you can get some information on the various commands.
Hit <ENTER> or click on the 'Do' button and whatever is on the
command line will be interpreted as in HF-Lab. As far as creating
and manipulating height field data the only differences with
HF-Lab are the addition of a few commands.

The FOR control statement
The control statement
       for <a> <b> <step> {list of commands to be repeated}
will do repetitions of everything inside the brackets
{ ... } as the index goes from a to b in steps of step size.
(leaving out <step> causes the step size to be 1). Another way to
get the repetition effect is with
       do <b> {list of commands}
which simply does b repetions of whatever is in the brackets.

The repetition index (where exactly between a and b
the process is) can be accessed three ways:
    %i in a command will be replaced by the integer value of the
       index on each repetition.

    %r in a command will be replaced by the index's floating point
       value. For example:
            for 2.6 3 .1{ gforge 200 %r;dump}
       would have the same effect as writing and executing:
            gforge 200 2.6; dump
            gforge 200 2.7; dump
            gforge 200 2.8; dump
            gforge 200 2.9; dump
            gforge 200 3.0; dump

    %n will be replaced with the 'count' value. This the number
       of the repetition (regardless of the index value). Also
       you can force prepended 0's onto the 'n' number.
            for 2.6 3.5 .1{ gforge 200 %r; dump blab%3n.gif}

       will have the effect of
            gforge 200 2.6; dump blab000.gif
            gforge 200 2.7; dump blab001.gif
            gforge 200 2.8; dump blab002.gif
             ...
            gforge 200 3.4; dump blab009.gif
            gforge 200 3.5; dump blab010.gif
       (note that this only works with %n, not %i or %r)

%i, %r, and %n are from the indices of the --outer-most-- 'do' or 'for'.
The corresponding indices for a loop nested once inside the outer most
loop are %j, %s, and %o, respectively. Further nested loop indices
are %k, %t, and %p, and then %l, %u, and %q.
While further nesting (beyond four) is OK, they have no accesible
indices.

MACROS
One more enhancement is the ability to define 'macros' for often
used sequences of commands. The syntax is:
     setmacro <macro_name> {<macro_definition>}
An example:
     setmacro y {zero 200;yslope;norm -1 1}
So you can just type 'y':
     y
and a height field which slopes from -1 to 1 along the
y axis will be created.
With y already defined, you could then define 'x':
     setmacro x {y;rotate}
which will create a 'y' as above and then rotate it so that
it slopes along the x axis.

Currently, macros do not accept parameters, and do-for indices
(e.g. '%i') written into a macro do not get interpreted.
