iCE: Old timers will remember JED and his fantastic
ansimations. Back in the day it was rumored that he only drew the
static screens, and that you put in the time and effort to turn them
into the animations that we all love. Is there any truth to
this?
radman: Absolutely. Before joining ACiD, JED was already a
talented still screen ANSI artist with a lot of enthusiasm and
appreciation for ANSImation. I personally indoctrinated him on
the fundamental and technical aspects of ANSImation. He absorbed
that knowledge and went on to create several of the most ground
breaking and greatest achieving ANSIs made to date.
My presence existed silently in even some of his more
complex animations released later on in his career. I'd often help
dissect, splice, resave, optimize or adjust the timing of an
animation before it's inclusion in the Acquisition Update. My
involvement wasn't limited to JED or animated ANSIs for that
matter.
Each ANSI X3.64-1979 terminal emulator, be it a dial-up
communications program, device driver, or ANSI art viewer interprets
the way ANSI control sequences should be displayed in a slightly
different manner. Even the slightest of differences can destroy the
intended result of your animation completely. The general rule of
thumb was to make your artwork compatible with the lowest common
denominator of your viewing audience.
My signature in any ACiD ANSI was easy to spot, both
visually while watching it display live on a BBS, or later while
reviewing the codes in a plain text editor...
Early on we determined our lowest common denominator to be
the user of the comm program because they had the least amount of
real estate available on the screen. After all, ANSI was meant to be
displayed while connected to a BBS, not from DOS in a specific
text-mode.
With this in mind, we chose a conservative area of 79
columns wide by 23 lines tall as the framework of our animations.
This was derived by taking for granted the following things: Our
viewer was using an IBM-PC compatible computer running some flavor
of DOS in a textmode of *atleast* 80x25 using a comm program. By
default, virtually all comm programs took up the bottom row as a
status bar (detailing connection speed, terminal mode,
online/offline, etc) and some, such as TeleMate, also consumed the
top row for use as a menu bar. This explains 80x23.
One more problem. If you were to compose a full screen
animation at 80x23, as soon as you place a character on the 80th
column of the 23rd line, a new line would begin, thus scrolling up
the entire screen one row, cutting off the top line of the ANSI.
Drawing on 80th column is just practice, be it ANSImation,
scrolling ANSI, or even plain ASCII. Because each ANSI editor saves
ANSIs utilizing the 80th column differently, the only
semi-reliable saving method is one which uses exact cursor
positioning (such as "Clear Screen" which use codes that look like
"<esc>[#;#H".) The catch is that if you're drawing to
specific points on the screen, you can't scroll. That would require
relative cursor positioning which brings you right back to square
one.
The 80th column problem affects ASCII art similarly. When
saving an ASCII utilizing the 80th column, the ANSI editor makes
the assumption that a wrap has taken place and does not insert a
carriage-return and line-feed to the end of the line. This causes
problems for both command line and windowed users. DOS users who
attempt to view the ASCII later with an actual text processor (such
as Q-Edit or MS-DOS Edit) will see no separation between the rows of
text, resulting in multiple lines running in to each other, at times
the entire picture compacting to a single line. Windows users who
have windows wider than 80 columns will run in to a similar problem:
If word-wrap is enabled in the window the text will generally not
wrap until a space character is detected. The effect looks like
someone took the ASCII and twisted it around the window screen
several times over.
Now you know. 79x23.
Another signature example of my interference with an
ANSImation is my method of "pausing" during an animation. Once we
evolved from animating by hand, meaning manually changing each
character one at a time in TheDraw, to what I call sprite and frame
animation, most people would simply reload or recopy the same screen
or sprite over itself for the pause effect. I felt this was messy
and did not allow for precision timing.
Messy because it was distracting to watch the cursor dance
around as it reloaded the screen. Imprecise because it often used a
whole page of interpreted data versus a single repetitive
sequence. I opted to borrow from TheDraw and manually make use of
<esc>[s, the Save Cursor Position code because it was one
of the shortest escape sequences which were invisible to the viewer.
The smaller the repetitive sequence, the easier it was to
fine-tune the timing rather than have to under- or over-compensate
by redrawing the entire picture. Another added advantage of using
<esc>[s for large animations was it achieved a better
compression ratio when archiving. |