Trade Secrets (pun intended)


This CONFIDENTIAL TRADE SECRETS LIST is only to be read by AUTHORIZED PERSONEL!!! If you are not authorized, please leave!


Okay, have it you're way... Here they are...

The Animated Software Company has repeatedly been told that we have the smoothest animation in the industry. Yet, we believe we've only scratched the surface of what could be done!

Probably the first time we heard this comment was in about 1982 when we designed graphics for small computer firms in Connecticut. This was before the IBM-PC had been released, and the programs were written in some form of BASIC. The big breakthrough that allowed animation on computer was bitmapped screens, because before that, character-based animation was all that was possible, which usually looked awful and was cruel to the programmer who worked with it.

Our first paid animation job on IBM PC's and compatibles was actually for IBM Product Centers, (which no longer exist), along with Bloomingdales' department stores in 1984. It was for a Christmas promotion and what I remember most about that job was that one of the things I had to do was draw woman's pan.ties, for the department. (No, not with a live model.) I knew this was the start of something really fantastic, and that is the last time I've drawn anything like that! Oh well, it's still been fun!

Our second paid DOS project also started in 1984 but has yet to be completed. We were commissioned to produce the first in a line of educational tutorials called THE HUMAN BODY SERIES. We began with THE ENGINE OF LIFE, about the human heart.

Now, 10 years after that product was first released, it is still available and still highly praised, and upgraded to SVGA screen mode, with other improvements along the way. However, the high degree of interactivity which author John Keenan designed and Russell Hoffman programmed has kept this product in use in the "highly volatile" educational software market for over a decade. One product!

Mr. Hoffman now has numerous animation projects under his belt, including writing laser control software. One application was a concert at Art Park near Niagara Falls. The Art Park concert was conducted by the famous Eric Kuentsel and was performed by the Buffalo Philharmonic Orchestra. Our lasers showed galloping horses, R2D2, a flying Bald Eagle, and about a dozen other images, most of them animated. It was great fun being right on stage (unseen behind a low wall) during the performance of the 1812 Overture, with "real" bombs going off on stage all around us! The whole trip was one unforgettable experience after another...

But I digress...

Animated laser motion requires extremely accurate timing controls as well as interactive controls for the presenter. Only minor modifications to the "P11" framework needed to be done, which sent the X-Y signal directly to the D-A converters, which then sent the analog version of the signal to the stepper motor laser mirror controls. (It should be noted that the manufacturer of the laser mirror controllers was actually the star performer: it was the accuracy of his mirrors that made the animation signals work!)

Other projects along the way include an animated lesson for a non-profit group called Global Energy Network International, a demo logo display for INTEL, the ALL ABOUT PUMPS project, all sorts of animated animals, and bits and pieces of dozens of other things. (Many of these animations can be found in our file download areas.)

How is it possible that even in 1995, THE ANIMATED SOFTWARE COMPANY is still able to get high praise for the quality of it's animation? It's not because we do everything right: we're far too small a company to be able to do everything right! But we do know HOW to do the most important things very well. We aren't always able to accomplish what we would like, and we can't adhere to every rule we've listed here, but we get enough done to get by.

As a public service, we are presenting these "TRADE SECRETS" to any company that might want to listen, in the hopes that they will begin to write code that handles animation properly, or when setting standards, to require companies who produce products that adhere to those standards to follow these guidelines for animation.


Therefore you have to optimize it. There isn't much in computers these days that you really have to optimize, but animation is one thing you do. And realize that animation is just about the best thing a computer can do! Books are still generally easier to read than online documents (and many of you will probably print this out to read it.) Newspapers, even with their poor contrast, are still common for their overall ease of use. But these media can't give you animation. Animation is a great instructive device. Pictures really can be worth a thousand words. Computers do animation, and it's really important! It has to be optimized!

Like what can be done to optimize it? Like this:

Don't redraw the background screen as an interim step. When an object moves across the screen, you cannot remove the previous position by redrawing the entire background area over the previous position, unless the amount of movement caused the object to have no overlap with it's previous position. The overlapped part is usually 80% or more, so ONLY the nonoverlapped part should have the background redrawn. Do programmers really not know this or are they just lazy?

Preread your header files. Nearly every animation file can benefit from being placed on the screen quicker. The same animation, running at 30 Frames Per Second, that uses only one hundredth (1/100) of a second to place each of the thirty frames of animation on the screen, will look better than one that uses two hundredths of a second to put each frame on the screen, even though both will run at the proscribed 30 FPS. Mice, joysticks, keyboards and other devices will also all work better if the higher display rate can be achieved through software efficiencies.

Preread each frame, esp. the last-back-to-the-first transition. Because the speed that the image is placed on the screen is as important (more or less) as the frame rate (as just described) you always need to preread the next frame. This allows you to more quickly "flick" the image onto the screen. In fact, I have made conscious decisions to trade absolute frame rate for an increase in the speed that the individual image is placed on the screen. Must be important, then, huh?

Let the user adjust the speed of the animation. Two ways: First, they should be able to slow down and speed up the animations so that it runs at a speed that is good for them. Second, they should be able to size the window if necessary to smooth out and speed up a slow animation.


Because, you see: We are all idiots. Some of us are idiots some times, and others of us are idiots other times, and some of us are idiots more often than others of us are. But it's a given: We are all idiots sometimes.

Don't punish people for using your computer program. If they don't know the rules, explain the rules. If they don't do the right thing, tell them what the correct choices are--don't just tell them they're wrong!

Explain errors. Don't just tell someone they've made an error without telling them what the error is, what to do about it, and where to go instantly for more help. Most importantly, if they ask for more information, don't just repeat what you've already told them. Don't be like the foreigner who simply talks louder when he is not understood.

Function Key One should always be the Help key. Do I have to explain this?

Programs should state their purpose and exit when asked. If a user starts a program with just a question mark for a parameter, or -? or /? or \? or (?) or--you get the idea--then the program should just state its purpose (to sysout) and exit back to whatever invoked it. No program should be allowed to execute if it can't perform that simple function of answering to a ? without actually "running". Virus checkers should test for that behavior as well.


Don't make people search for the next logical step. Here's an idea for a user interface of two, three, up to maybe eight or ten choices: draw the choices as sections of a pie and place the user's mouse in the center. Then let them move the mouse as far or as little as they want into the various sections of the pie and then click. Don't let the mouse go outside the pie until they click, (other keys or other mouse buttons can override that) so that they don't have to stop moving towards the sector they want. This would be an extremely fast selector device and could become standard. For two choices, a flick to the left and a click or a flick to the right and a click would do it, and even the click could be eliminated with a small inner "dead zone" circle where they start.

But mainly, you have to give them large areas where choices are made, so they don't have to focus on the mouse's cursor at all for most things. They should know intuitively where the mouse will be relative to the major choices--to the left is back, to the right is forward, etc..

Having the use of the mouse is nice, but why limit people to finding a couple of tiny buttons on a screen? Is it some kind of a contest to see who is the most dextrous user? For example why are we forced to focus on some stupid little part of an icon (not even a whole icon, sometimes) to PG UP and PG DN a screen? I mean, browers that don't implement Page Up and Page Down keys are unbelievable to me--and why don't keyboards have standard PIXEL UP and PIXEL DOWN buttons and LINE UP and LINE DOWN buttons as well? Every text file from antiquity has needed these display tools, let's get them on the keyboard where they belong!


Every computer needs an A-D converter somewhere. And you know what? Just about every computer has one, but hardly anybody's using it. It's called the Game Port, aka Joystick. The joystick is a powerful pointing device and beats the mouse in a thousand tasks. Unfortunately only the game programmers seem to have discovered this wonderful device! Why is it that spreadsheet software doesn't use the joystick to enhance the cursor control capabilities?

I added what seemed like a simple toy to the "P11" drawing program, that allows the mouse and the joystick to cooperate on a cursor. It in turn allowed all kinds of new drawing capabilities (which show up in the ALL ABOUT PUMPS tutorial, for example.) The joystick controls scaling of an object's size, and rotation of the object, while the mouse controls position and draw mode. It works really well and is incredibly versatile! Other serious graphics programs should consider using these two devices together. The joystick port--it's not just for games anymore!


Eliminate flicker. Whoever decided that computer monitors should refresh at the 60 and 70 frames per second rate should be shot with a slow-moving bullet. Animation needs a much higher rate, partly because of the low resolution of the screens. What happens is the images obtain additional flicker as they move around on the screen quickly, due to artifacts that are introduced by the low resolution (another scandal) in pixels. The lower the resolution and the faster the objects move the more this problem manifests itself.

I won't even bother to spend a lot of time attacking low resolution issues. We do all our work at the 1024 by 768 dots, 256 color level and feel strongly that the whole world should move to screen resolutions of at least 4096 by 4096 dots, and 36 bits of color. Yes, even for home animations. 12 levels of the three primary colors and 4096 dots by 4096 dots on the screen should allow incredible images that rival visiting a museum.

I also want to harangue about the com port! When are we getting fiber optics into the home? What is your problem, guys? Are you afraid of the brave new world where video stores don't exist, camera stores don't exist, film developers don't exist, record stores don't exist, libraries don't exist, municipal records desks don't exist, bookstores don't exist, newsstands don't exist. You really think those things, those things, not those concepts, make your quality of life? No, it's not those things, it's those concepts, which will all turn cyber. Do you think Edison cared about his cylinders, or his motion picture cameras? No! He cared about reproducing sound and images, by whatever means he could come up with! We don't need the physical thing, the record, tape, video, film print, magazine, book, or whatever. We need the file, that's all. Just let us look at the file. That's publishing in cyberworld.

Another problem: Delays between screens. We should all realize that the user's time is valuable, and we should waste as little of it as possible. For example, on the Internet it takes "forever" to download HTML files with even small pictures. Files greater than about 20K are generally considered worth warning the user about, and HTML files should load "in not more than 9 to 15 seconds". And, it doesn't even matter if that's other pages in my site, or jumping to a whole new site. On the other hand, my ALL ABOUT PUMPS tutorial takes two seconds, three tops, to load the next page (often only one second), and in three keypresses you can be at any section from the hundreds of screens in the program. Compare that to your own experience right here with The Internet Glossary of Pumps, which doesn't even have animated images (as of this writing, Feb. 1996.) I would never have thought back in 1980 that in 1996 I'd still be preaching about the delay between screens being a waste of time but I am. And, I probably wouldn't have if it weren't for the fact that the browsers I've seen don't put the TEXT up before the GRAPHICS... Know what I mean? I know, as an HTML author I'm guilty to some extent, but the truth is, the browser should handle it, and force the text onto the screen before the graphics so that the user has something to get started with right away! (In the ALL ABOUT PUMPS tutorial, the text loads first, probably 99% of the time.)

Written by Russell D. Hoffman


Table of Contents

The Animated Software Company
Mail to:
First presented online on February 14th, 1996.
Last modified March 27th, 1997.
Webwiz: Russell D. Hoffman
Copyright (c) Russell D. Hoffman