fdraw/docs/demos.md

168 lines
7.0 KiB
Markdown

fdraw Demo README
=================
The fdraw distribution comes with a handful of demonstration programs.
Most of them are written in Applesoft BASIC, and use the amperfdraw
interface. This is a somewhat poor way to demonstrate animation
performance, as Applesoft adds a tremendous amount of overhead, but it
is the only way to show what you *can* do with Applesoft.
The easiest way to run them is with the "DEMO" program, which scans the
DEMOS directory for BASIC programs and presents a list. You can also
just run them directly.
* INTRO : Sort of a "hello, world" for fdraw. Mix of single- and
double-buffered animation.
* CIRCULAR : Draws lots of circles.
* RECTSPLAT : Draws lots of rectangles.
* CUBIC : Draws a spinning wireframe 3D cube. (The 3D coordinates are
pre-computed -- fdraw doesn't do matrix transforms.)
* TUNNEL : Animates circles to simulate driving through a tunnel.
* LINEAR : Draws lots of lines. The wipes show speed differences for
horizontal and vertical special cases, while the circular spinner
shows HPLOT is not as fast as &HPLOT which is not as fast as &PLOT for
a set of lines at a variety of angles.
* LINE.DIFF : Draws several lines with the ROM routines and fdraw
side-by-side to illustrate the difference in line style.
* CLEARLY : Clears the screen 32 times, 4 sets in each of the 8 colors.
The first round is done with the Applesoft ROM routine ("CALL 62454"),
the second round uses the fdraw &CLEAR function.
* HRFAN : A simple line-art demo, using "xdraw" DrawLine with lines in
different colors. Not a great demo, as the Applesoft code driving it
is rather slow, but it looks pretty good if you bump up the emulation
speed or switch to IIgs "fast" mode. (This deserves a conversion to
assembly language.)
* BRIAN.THEME.ORI : The Brian's Theme demo from the DOS 3.3 System
Master. Unmodified except for integration with the demo menu
system, and with the bug on line 31112 fixed.
* BRIAN.THEME.NEW : The Brian's Theme demo with '&' placed in front of
the various draw calls. There isn't a huge difference in speed, as
there's a lot of overhead from Applesoft, but its interesting to note
the change in the appearance of the lines.
* WIGGLE : Sample program that shows direct use of rasterization tables.
When the demos are launched from the menu, they will assume that fdraw
is already loaded and won't try to load it again. If you run the demo
program directly, it will try to load FDRAW.FAST and AMPERFDRAW from the
parent directory before doing any drawing.
## Extras ##
The EXTRAS directory has some additional software that isn't "officially"
part of fdraw, but may be of use.
NOTE: some of these assume fdraw and amperfdraw are already loaded, and
will hang if not. Run DEMO and hit <esc> before running these.
* ARRAY.EXAMPLE : The &PLOT example from the documentation.
* XDRAW.ANIM : A demonstration of line animation using "xdraw" mode and
a simple shape that is drawn twice by a single &PLOT call. One copy
is offset by 2 pixels, so each &PLOT call erases the previous copy and
draws a new copy 2 pixels to the right. The animation is shown twice,
once with "erase all, draw all", and once with the erase and draw calls
interleaved for every line.
* LINEFONT : Program for creating draw-array tables for text phrases. Used
to create data files for the "intro" demo. See the "LINEFONT Details"
section for more information.
* DAVIEWER: Views the contents of .DA files created by LINEFONT.
* BENCHCLEAR : Calls the "clear" function 256 times from a small
assembly-language program. Handy for benchmarks, but slightly silly
since it's relatively easy to calculate the exact cycle cost.
## LINEFONT Details ##
NOTE: this program is an unfinished rough cut ("pre alpha"), used for
preparing data for demos.
The program includes a font definition, routines for displaying
characters, and code for generating and exporting pre-rendered strings.
Character vertices are expressed as floating-point values. The baseline
is at zero, the peak ascent is at 1.0, the lowest descent is -1.0. The
leftmost pixel is at zero, the maximum value for the rightmost pixel is 1.0.
Characters don't have to fill out the entire cell -- proportionally-spaced
fonts are supported -- but they are expected to start at the left edge.
So a capital 'M' might look like this:
0.0,0.0 -> 0.0,1.0 -> 0.5,0.7 -> 1.0,1.0 -> 1.0,0.0
There is currently no "user interface", unless the "user" can program in
Applesoft BASIC. To generate strings, add a series of statements that set
variables and call 20000 to add rendered strings to the set. The relevant
variables are:
* S$ - string to add
* DW - desired width, in pixels, of a cell 1.0 units wide
* DH - desired height, in pixels of a cell 2.0 units high (ascent + descent)
* IS% - inter-character spacing, in pixels
* SW% - width of the space character (usually same as DW)
* MO% - monospace flag; if nonzero, all chars are treated as 1.0 units wide
Remove the REM from the start of line 1010 to enable the character viewer.
At present only a couple of lower-case letters are defined.
#### LINEFONT Output ####
The LINEFONT program outputs a binary blob that can be passed to
the &PLOT array-draw function. The file structure is:
+0 byte - number of array sets in the list.
+1 2 bytes * N - table of offsets to individual array sets. One of
these per array set. The value is the offset from the start of the
file.
(2N+1) array set #1:
+0 byte - number of vertices (0-127)
+1 byte - number of index pairs (0-127)
+2 2 bytes * V - vertices (values are signed X/Y)
+X 2 bytes * I - index pairs (values are 0-127)
To display phrase #3, you would get the 16-bit value from the offset
table with `PEEK(start + 1 + 3 * 2) + PEEK(start + 2 + 3 * 2) * 256`.
You get the number of vertices from `PEEK(start + offset)`, and the number
of index pairs from `PEEK(start + offset + 1)`. Finally, call the array-draw
function with:
VA = start + offset + 2
IA = VA + num_vertices * 2
&PLOT va, ia, num_index_pairs
The 0,0 point in the blob is in the center of the phrase horizontally
(which allows a maximum width of 255 pixels), and at the font baseline
vertically (so most of the font will appear above the zero point, but
descenders will extend below).
#### Future Enhancements ####
Right now the font definition is embedded in the program. This takes up
a lot of space -- before too long the BASIC program is going to intrude
on the hi-res page -- and is unnecessarily restrictive. The font should be
defined by a separate program, and BSAVEd into a line-font file that
LINEFONT can load.
Generating strings should be menu-driven and interactive, rather than
requiring manual changes to the code to fiddle with sizes and spacing.
DAVIEWER should be folded into the generation program (though it's kind
of handy as a simple example of how to unpack and access content).