MandelMountains V2.1 by Mathias Ortmann


NOTE: This documentation covers only MandelMountains up to V2.1.
Changes in V2.108b have not been included yet.

Unfortunately, the 'real' turbo version of MandelMountains V2.0 (which
was intended to support 68020/30 and 68881/82 machines) was bugged and
didn't work properly (never try to develop software for processors you
don't actually have!). - Is the working turbo version of MandelMountains
really doomed to non-existence, only because the author has no chance (no
money) to get his hands on an accelerator board?

Well, now there IS a turbo version, and it WORKS: MandelMountains V2.1
is TWO TO THREE TIMES FASTER than MandelMountains V2.0 - without ANY
additional hardware!

Hard to believe, but true.

How was this quantum leap in performance possible?

Most of the speedup is based on using fixed point instead of floating point
arithmetic.  The genius behind the new, tremendously fast routines is Doug
Houck, author of the programs FracGen (shareware), Doug's Math Aquarium
(commercial) and MathVISION (commercial), who offered me a technology
trade:  His fixed point arithmetic Mandelbrot set calculation routines in
exchange for my tips on shaded rendering.
Everybody will profit from this: The MathVISION users get even smoother
pictures, and the MandelMountains users much faster calculation speed.

No sooner had I experienced the speed of integer/fixed point arithmetic,
than I rewrote most of the rendering algorithm in assembler, using double
precision floating point format only where necessary, otherwise FFP and, if
possible, integer arithmetic.  Note the increased drawing speed!


A problem in MandelMountains V1.1/V2.0 was the incompatibility of the image
files with some (not all) of the commercial graphics software (e.g.
Butcher, ShowPrint II and older versions of DPaint), which crashed when
trying to load compressed MandelMountains images.

I checked my IFF/ILBM compression algorithm and found that it was not
fully standard - some strange bug caused trashed BODY chunks.
After having replaced it with the original algorithm published by EA/C-A,
the problem was solved.
Another advantage: The files produced by the new algorithm are some
kilobytes shorter than the old ones, so it's a good idea to load and
re-save all previously generated images! 
To be absolutely sure, I implemented the option to save an image without
the MMD1 chunk, so the image files can be loaded into software having
problems with alien IFF chunks.
Be careful when saving without MMD1 chunk: The resulting file cannot be
loaded into MandelMountains any more!


The third change in MandelMountains V2.1: the workbench window will not be
cleared during rendering, so the parameters remain visible.  The menu will
stay active, too, although only a few menu options will be available.
Probably the most useful feature is that the task priority is now
changeable during computation.


Doug Houck also gave me a valuable comment on the lacking response from the
USA on MandelMountains V1.1:
"America is a big enough country that we seldom have to deal with airmail and
other currencies, which we see as an inconvenience.  Especially if we have
to go the post office to get a customs sticker, or to the bank to get an
international money order, it's too much of a threshhold to get over.
On the other hand, in the European Community, you are much more used to
dealing with other languages/currencies/airmail, and it's no big bother to
send a couple measly dollars/francs/Deutschmarks via airmail to a starving
Shareware author."

So here are some hints how to send disks/cash:
To send a single disk, a legal size envelope will be enough, for more disks
preferably use a padded envelope. In the latter case, you'll need a customs
sticker which you get at your post office. Mark the contents as Public
Domain disk, value $1 - and it will work just fine.
To send cash, you can simply put on two first-class stamps (2 * 25 = 50
cents), an airmail envelope is desirable but not necessary.


At this point, I have to thank everybody who supported me with shareware
contributions, suggestions and criticism.  I have finally achieved an
international echo - from Germany, Switzerland, Denmark, Great Britain, the
USA, and even from Australia!
If the support continues in this way, MandelMountains V3.0 will be reality
in a not too far  on the Workbench screen.

The cx/cy values are used only when working in Julia set mode.  They are the
real/imaginary part of the fixed parameter c in the term z = zē+c.
See below for a detailed description of how to generate images of Julia sets.

In the next two lines, there are the xmin/xmax/ymin/ymax values.  They
determine the rectangular part of the Mandelbrot set that is to be shown in
the image (xmin/xmax represent the range of the real part, ymin/ymax of the
imaginary part of c [in Julia set mode: z] in the term z = zē+c).

The Depth value limits the number of iterations.  If then the value of z
has not exceeded a certain maximum, the point will be drawn in black.
Increasing this value will result in a more detailed rendering of the
border between color and black, but it will also increase computation time
if there are larger areas of black.  Normally, a Depth of 400 to 2000 is
sufficient.

Linear/Nonlinear/Super-Nonlinear Transformation: If your mountainsides
look extremely steep, you should switch to Nonlinear Transformation.
For extreme cases, there is the Super-Nonlinear transformation, which is
especially useful for magnifications of the western side of the Seahorse
Valley.

ColorMin: If you wish to have the surface of the plateaus colored (and
you surely will!), you set ColorMin to the number of iterations from which on
a pixel is to be drawn in color.  Increasing this value will make the colored
areas smaller.  The range of ColorMin is normally from 20 to 300 (set it to 0
if you wish no coloring).

ColorDiv: This value determines the "step rate" for the surface colors.
For example: You have a ColorMin of 100 and a ColorDiv of 50.  The number
of iterations for a point is 300.  The color of the point is now
(300-100)/50, i.e. 4.  Usually ColorDiv is around 50 to 150.  It is not
very critical, but if you choose it far too low, the colored areas on
your surface will look rather fragmented.  If you choose it too high, they
will all have more or less the same color.

HZoom: This very important value is the decimal logarithm of the factor
all heights are multiplied with.  If you choose this value too low, the
whole surface will be flat like a sheet of paper; if you choose it too
high, you will not see more than some vertical walls.  This value is
probably the most critical and must be chosen carefully.  It depends very
much on the magnification factor (increase it after each magnification) and
can range from 2 (initial picture) to 30 (blow-ups of details in the
Seahorse Valley, for example).
Remember that for nonlinear and super-nonlinear transformation, HZoom
must be considerably higher than for linear transformation.

HSmooth: Sometimes it may occur that the border of a plateau looks rather
fragmented.  In this case, simply increase the HSmooth value.  It can range
from 0 up to more than 200, depending on the HZoom value you are using, but
is not very critical.  Set it to 50 for normal images.


It must be said that you will have to experiment a little to get perfect
results, but soon you'll get a feeling for these things (look at the sample
pictures and their parameters).

The 'Parameters' menu of MandelMountains contains the submenu 'Suggest'
which allows you to precalculate two of the above parameters. See below
for a further description of this feature.


5. The Menus

Project Menu:

Choosing the Load Image or Save Image option will bring up a file requester
(thanks Justin!) that allows you to choose a file name for the image to
load/save.  Images are compressed before saving.
In MandelMou