3.1 Drawing Method
The "passes option" (<X> options screen or "passes=" parameter) selects
one of the single-pass, dual-pass, triple-pass, solid-guessing
(default), solid-guessing after pass n, boundary tracing, tesseral,
synchronous orbits, or orbits modes.
This option applies to most fractal types.
Single-pass mode ("1") draws the screen pixel by pixel.
Dual-pass ("2") generates a half-resolution screen first as a preview
using 2x2-pixel boxes, and then generates the rest of the dots with a
second pass. Dual-pass uses no more time than single-pass.
Triple-pass ("3") generates the coarse first pass of the solidguessing
mode (see "g" below), then switches to either "1" (with low resolution
video modes) or "2" (with higher resolution video modes). The advantage
of '3' vs '2' is that when using high resolution modes, the first pass
has a much lower resolution (about 160x120) and is therefore much
quicker than the first pass of the passes=2 mode. However, with the '2'
mode, the first pass does not represent wasted time. The '3' mode wastes
the effort of generating the coarse first screen.
The single, dual, and triple pass modes all result in identical images.
These modes are for those who desire the highest possible accuracy. Most
people will want to use the guessing mode, described next.
Solid-guessing ("g") is the default. It performs from two to four
visible passes - more in higher resolution video modes. Its first
visible pass is actually two passes - one pixel per 4x4, 8x8, or 16x16
pixel box is generated, and the guessing logic is applied to fill in the
blocks at the next level (2x2, 4x4, or 8x8). Subsequent passes fill in
the display at the next finer resolution, skipping blocks which are
surrounded by the same color. Solid-guessing can guess wrong, but it
sure guesses quickly!
Solid-guessing stop after pass n ("g1" through "g6") are a variation on
the guessing mode in which the algorithm stops after the nth pass. This
facility is for exploring in low resolution when you'd rather see a low
resolution image with large blocky pixels filling the whole screen than
a small low resolution image such as you get with the <v> (View Windows)
command. Note that on the <x> screen you can't directly type g1 or g2.
Press g repeatedly until you get the option you want, or else use the
left or right cursor keys.
Boundary Tracing ("b"), which only works accurately with fractal types
(such as the Mandelbrot set, but not the Newton type) that do not
contain "islands" of colors, finds a color boundary, traces it around
the screen, and then "blits" in the color over the enclosed area.
Tesseral ("t") is a sort of "super-solid-guessing" option that
successively divides the image into subsections and colors in rectangles
that have a boundary of a solid color. It's actually slower than the
solid-guessing algorithm, but it looks neat, so we left it in. This mode
is also subject to errors when islands of color appear inside the
rectangles.
Diffusion Scan ("d") is a drawing type based on dithering techniques. It
scans the image spreading the points evenly and to each point it paints
a square of the appropriate size so that the image will be incrementally
enhanced. This method calculates ALL the points in the image being a
good substitute for Single/Dual/Triple pass and presents a quick
visualization even in the slowest fractals. With "fillcolor=0" (below)
the squares are not painted and the points are spread over the image
until all have being calculated (sort of a "Fade In").
The "fillcolor=" option in the <X> screen or on the command line sets a
fixed color to be used by the Boundary Tracing and Tesseral calculations
for filling in defined regions. The effect of this is to show off the
boundaries of the areas delimited by these two methods.
Orbits ("o") draws an image by plotting the orbits of the escape time
fractals. This technique uses the same coordinates to draw an image as
the other passes options, sets "passes=1" and no symmetry, and then
plots the orbits for each pixel. Zooming into a "passes=o" image is in
fact zooming into the "passes=1" image, and the resulting image may not
be what is expected. To find interesting places to investigate, press
<O> after an image has completed and watch the behaviour of the orbits
as the cursor is moved around the screen. See Orbits Window (p. 34).
The "outside=summ" option causes Orbits to increment a pixel's color
number every time an orbit touchs it; the resulting display is a 2-d
histogram. If "outside=" is some other value, then the "inside=" color
determines the color of the plotted orbits. If "inside=0", then the
color number is incremented at the start of each pixel of the passes=1
image.
The "orbitdelay=" option controls how many orbits are computed before
the orbits are displayed on the screen. This allows the orbits to
settle down. The "orbitinterval=" option causes Orbits to plot every
nth orbit point. A non-zero value of the "periodicity=" option causes
Orbits to not plot orbits that have reached the bailout conditions or
where an orbit goes off the visible area of the image. A zero value of
periodicity will plot all orbits except as modified by orbitdelay and
orbitinterval.
Synchronous orbits ("s") is an experimental mode using the "fractal
witchcraft" algorithm based on the Almondbread implementation by Michael
Ganss. This algorithm optimizes deep zooms by calculating parallel
orbits starting at different points, and subdividing when the orbits
break formation. Michael's implementation had to be extensively
modified to work with Fractint's DOS medium memory model environment.
Synchronous orbits (also known as SOI) has some limitations. SOI is
loosely coupled with fractint and most options don't work with it. Only
types mandel and julia are implemented. SOI is only useful for very deep
zooms, but only up to the limit of double precision. Within this narrow
magnification range, SOI can result in tremndous speedups. If you invoke
fractint with "debug=3444" on the command line, a long double (rather
than double) version will be used, which allows zooming about 1000 times
deeper. SOI really needs to be ported to fractint's arbitary precision.
This will likely happen only after Fractint is moved to a better
programming environment.