                   -=-
                 DEM2TGA
Convert USGS .DEM data to .TGA image format.
        Sean O'Malley, April 1999
       E-mail: ffrog@geocities.com
                   -=-

   This program is based on two programs: DEM2POV.C, "modified by
W.D. Kirby" (I assume he's the author), and DEM2TGA.C by Jon Larimer.
This was converted from the original C to Pascal so it would be more
accessible and compatible to DOS users.  An important note about
DEM2TGA is that, if you're using DEM2TGA without an actual geographic-
based DEM viewer to compare the DEM2TGA images to, the TGA it produces
will NOT be aligned with real north facing up.  Instead, north will
be facing to the right.  If you need it to be geographically correct,
use an image editor to rotate the image 90 degrees counterclockwise
(to the left).

   Usage:

   DEM2TGA dem_file tga_file [-P]

dem_file is required.  It should be the name of a USGS Digital
Elevation Model file.  If no extension is specified, DEM2TGA will
assume it is DEM.

tga_file is required.  It is the name of the TGA to produce.  If no
extension is specified, DEM2TGA will assume it is TGA.

-P is optional.  If specified, it will produce a POV (raytracer)
   heightfield image which will look rather odd if seen in an image
   viewing program.  If unspecified, the program defaults to producing
   a generic (and green!) higher-is-brighter TGA image suitable for
   viewing.

The TGA
-------
  I wrote this program to use the maximum data available from the DEM
file.  Whereas the original DEM2TGA used a maximum of 256 colors, there
would have been "data loss" if the elevation range went over that
amount.  (So if a mountain went from 1 to 1000 meters, it would in
effect compress everything down by about a quarter, or throw away about
3/4 of the height data between any two levels.)

  This program, when used with -P, can use up to 65536 different
levels, which should cover just about every DEM out there!  In its
default mode, it will use 256 colors and act much like the old DEM2TGA,
but will still produce a large, 24-bit TGA file.  (Yes, it is green
instead of shades of grey.  You can get a non-green version of the image
by loading it in an image editor, converting it to greyscale, and, if
necessary, making it 33% brighter.)

  One problem with DEM2TGA (and the programs it's based upon) is that
the file it produces won't be aligned with the north pointing up.  To
fix, the image needs to be rotated 90 degrees counter-clockwise.

  When using the DEM2TGA-produced images as a heightfield on a rendering
engine, remember that the height data is in no way scaled to the actual
area covered by the image (that would be practically impossible).  If it
were, the images would be extremely flat: while DEMs might cover hundreds
of square miles, the maximum height might be only several thousand
meters.  (It is possible to make a true-scale heightfield if you can
find the width in meters of the area covered by the DEM and scale it to
the maximum height reached by the DEM in meters, just difficult.)

The Program
-----------
  The program is a DOS-ized welding of the original C DEM2POV and
DEM2TGA.  Most of the TGA- and DEM-specific code was adapted from
DEM2POV while the routine for grabbing data from the DEM was adapted
from DEM2TGA.  It includes some assembler for simpler routines and a
whole lot of DOS-specific code to make it run faster.

  The original C programs, when compiled with GCC, were comparatively
fast.  So I added the weird file buffering routines to the program,
which solved the problem of speed for the Pascal program.  (The file
read/write procedures are pretty slow to be calling every byte!)

  The original, non-buffered version took so long I never even let it
finish. The buffered version with "diskbufferk" set to 20 (kb) takes
about 7/10 of a second per megabyte of DEM data on a 300mhz machine,
which is approximately equivalent to the speed of the GCC-compiled C
versions.  (Reducing the buffer to 10kb means about 1 second/megabyte
on the same machine.  Further reduction is pretty bad!)

  So, there isn't that much of a loss in the C->Pascal conversion.
(Did I mention that the GCC-compiled executables are over 100kb?
The Pascal executable is about 11kb.)

The Author
----------
The author (or converter) wrote this mainly for raytracing purposes.
If you wish to contact me, send me nasty e-mail, send me money, send
me compliments, send me yummy things to eat, etc., my contact
information is:

         Name: Sean O'Malley
       E-mail: ffrog@geocities.com
  Alternative: frog@star2.opsys.com
  (Try the GeoCities address first; if it bounces, use the second.)

     Web page: http://www.geocities.com/~ffrog/

This was written in April, 1999.

 - Sean
    O_o
   (   )
  ( | | )
  ' " " `
