Animation

You may be excused for thinking there is no need for this chapter since several animation facilities have been described in previous chapters. These were offered by Euclid/Mogul and 3D Construction Kit described in Chapter 6, ARCtist described in Chapter 9 and ArcLight and Render Bender described in Chapter 13. But in those chapters the animation facilities were incidental; it was some other feature of the software that merited its description there.

Animation techniques

Every animation system that man has devised (apart from 'live' puppets and automata) relies on the same optical illusion. If you show a sequence of static pictures in quick succession and each picture shows a successive stage in the same process, perhaps a man walking, the observer will be tricked into thinking that he is seeing not a sequence of still pictures but one moving picture. From the schoolboy flicking the corners of his notebook to achieve a crude animation of his doodlings, through the Victorian 'what the butler saw' machines on seaside piers, and on through cinematography to video, this same fundamental principle has always applied. And computer animation is no exception.

It is generally accepted that a minimum of 12.5 frames (i.e. pictures) per second is needed to achieve the illusion of motion. Increasing the number of frames per unit of time gives smoother animation and reduces the flicker effect. VMS video recorders in Europe use 25 frames per second. Broadcast television in Europe actually displays 50 pictures per second, but only 25 frames; each frame is shown twice but using alternate lines. On the A5000 computer the monitor displays 70 frames per second, so that in theory it can display computer animations that are smoother than is possible on a standard video system.

Computer animation may use either vector graphics or pixel graphics. For interactive animations such as adventure games, flight simulators and virtual reality, vector graphics is the only choice, since it would be impossible for the computer to store all the sprites needed to display every possible view of every possible scene. Instead the computer stores a mathematical model of the whole scene and repeatedly redraws the user's view of it. Even for an ARM3 this imposes a massive burden on the processor and a special form of vector graphics is essential to speed up the processing. For example, medium-resolution mode 13 is often used because it combines 256 colours with a quick refresh time. No curves are permitted since their plotting involves onerous calculation. Even in the most sophisticated virtual reality systems wheels and other round objects when closely examined turn out to be polygonal: curves are a luxury that present virtual worlds cannot afford!

Most computer animation, however, is sprite based. Sprites have the advantage that they can be thrown on the screen very rapidly indeed and RISC OS sprite plotting routines are readily accessible from BASIC or even the command line interpreter (see Appendix 2). The principal drawback of sprite-based animation systems is their massive memory requirement. If your animation consists of full-size mode 15 screens you will only have room for four of them on an 800 Kbyte floppy unless you employ a compression system. And unless the decompression system works in real time, another limitation will be the number of frames you can simultaneously hold in RAM.

Consequently, as in so many aspects of computer graphics, animation is an exercise in the art of compromise. Practical animation on the ARM machines tends to use the following techniques to keep its films to manageable sizes:

1. frames considerably smaller than full-size screens
2. 16-colour screen modes (sometimes less than that)
3. repeated action (so that the same sprites are used over and over again)
4. compression of individual frames
5. delta compression, i.e. compression applied to successive frames so that only the differences between them are stored.

These techniques used individually or in various combinations allow interesting animations of several seconds duration to be created and stored in files of conveniently manageable size. A typical example is Tony Cheat's animation SmallFly created using Euclid and Mogul. This fascinating little film, lasting about 5 seconds, gives you a 'fly's eye view' as it buzzes through the rooms of a modern house. The animation consists of 70 mode 15 frames, each 320 x 256 OS units, i.e. 1/16 of a mode 15 screen. But compression techniques have reduced it from the expected 70 x 160 x 1/16 = 700 Kbytes to just 44 Kbytes!

This kind of animation is not interactive: the viewer must accept the film as it is shown, just as in a TV broadcast or cinema performance; he or she cannot influence the development of the action.

This chapter describes three software applications, all from Ace Computing, which are designed to take the anguish out of the creation of computer animations: Tween allows you to create animations from Draw files; Splice allows you to edit animations in Ace film format and Projector is a utility for playing animations in Ace film format. Finally, the chapter describes a few animation techniques for those who wish to go it alone and produce animations with or without the help of proprietary software.

Tween

Tween is to Draw what Mogul is to Euclid. If you want that in plainer English, here goes. Tween takes a pair of Draw files and produces from them as many intermediate frames as you specify; it does the 'inbetweening'-hence its name. And it will convert the resulting frames to a sprite-based film in Ace film format if you require.

The difference between Tween and the interpolate/grade/blend facilities offered in Draw3, Vector and ArtWorks is that Tween interpolates whole drawings consisting of many objects including groups, and produces intermediate independent drawing files, whereas the other packages only interpolate between single path objects within the same drawing. In Tween the parent drawings must of course contain the same numbers and types of object in the same sequence and each object must contain the same numbers and types of segments. Size, position and colour are all interpolated. But in fact it's more sophisticated than that since it will simultaneously interpolate between several pairs of drawings in different directories and will superimpose the results in a user-defined order. In those different directories you might have drawings of two or three different characters performing different actions but whom you wish to include in the same scene; and in one you might have a background scene which remains unchanged throughout the action. Each such directory is called a 'toon'.

As in Mogul, an Action chart appears containing across its top the names of the relevant directories, one for the camera and one for each toon. Beneath these you enter the filenames of the Draw files relating to the key frames. If you click Menu in an empty space the main menu will offer you the chance to see that 'missing' frame. When this is drawn (it takes a little while, depending on complexity) it appears in a window and you can save it as a new Drawfile.

Although the files are described as Draw files, the originating software need not be Draw itself. Vector offers a special advantage for users of Tween. When the drawings being 'inbetweened' are fairly complex (say 20 objects, three of which are groups of six further objects each) it often happens that in editing the drawings for the key frames, the component objects get out of order, usually as a consequence of grouping operations. Sorting so many objects into the right order is a hit and miss affair in any drawing package except Vector whose order dialogue box tells you the precise position in the stack of the currently selected object and allows you to move the selected object to any position by number. The trick is to make a master list of the objects in the drawing (and in the groups) and after finishing each key version, to select each object in turn and move it to its proper place if necessary.

If you intend to save the film in Ace film format, you may also need to attend to the camera. This is a special rectangular object whose size determines the size and aspect of the drawing contents as they will appear in the finished film. You can even change the size of the camera during the film's progress-it can tie 'inbetweened' like the drawings-so that the camera can. for instance, zoom in on some point of interest in the action. Often, however, no camera motion is required and the camera column can be left blank,

Another of the options from the main menu is to save the complete film in Ace film format. This may be a long process, depending on the number of toons and frames involved, as each drawing in turn must be interpolated and then compressed. But even if you use some other film format, if you are an animation enthusiast who appreciates the exciting potential of vector graphics, you will find Tween an invaluable tool.

Splice

Splice is a utility for editing Ace films. It cannot edit the contents of individual frames, for that you must use Paint or some other pixel graphics editor, but it can be used to step through films frame by frame, to examine or export frames, to delete or insert frames or even to join films together, i.e. to splice them, hence the application's name.

Predictably, you start up Splice by dragging an Ace film icon on to its icon. (Double-clicking on an Ace film loads it into Projector instead.) This opens a viewer window similar to that of Paint in that it contains a miniature version of each frame in the film. Clicking SELECT in a miniature selects that frame, Double-clicking SELECT opens a window showing that frame full size. Clicking Select in the full-size frame changes the view to that of the next frame and clicking ADJUST to the previous frame. Holding down SELECT or ADJUST causes the film to run forwards or backwards at more or less normal speed within the window. Clicking MENU in that window opens a dialogue box with a save option allowing you to save the frame as a sprite. To edit an individual frame you would use this option, drag the frame into Paint and use that package to edit the picture. When your editing is finished, you save the sprite, dragging it back into the Splice window where it will replace the existing frame.

Individual frames or groups can be selected and subjected to such manipulations as vertical and horizontal flipping, although I confess to being uncertain as to why one should ever wish to flip individual frames.

A useful facility allows the size of the frames to be changed. All frames in an Ace film are the same size and sizes are always expressed in OS units rather than pixels. Interestingly, resizing Tony Cheal's SmallFly to full screen size of 1280 x 1024 (multiplying the area of each frame by 16) only multiplied the file size by about 5 to a little over 200 Kbytes, slightly more than a single mode 15 screen.

A scale-to-fit toggle, if selected, ensures that the design is scaled to fit the new size. If unselected, scaling up introduces lots of free space into each frame, so that additional action could be added into a film by those with sufficient dedication. You can join two films together very easily by dragging one film's icon into the other's window.

The newcomer is appended to the end of the original film. If the films have a different frame size, the newcomer will be scaled to the same size as the original, an operation that may take some time. Since Splice allows you to save a selection of marked frames as a separate film and to delete selections of marked frames, by combinations of joining, deleting and saving you can insert one film into another and introduce repeat action. A facility for reversing the sequence of a film makes it easy to produce reciprocating action, such as a swinging pendulum.

You can convert a whole film to a sprite file, but beware! It might be too big to load into Paint. Similarly, if you drag a sprite file into Splice it becomes an Ace film. So Splice could be used in conjunction with Paint alone to create animations. But my experience suggests that the preparation of animations is simpler using Vector and Tween or Euclid and Mogul, with Splice being used for edits to nearly finished films. The range of Ace products certainly allows limitless opportunities to the computer animation enthusiast.

Projector

The last of the trio from Ace computing, Projector is an application for playing Ace films.

Ace have placed it in the public domain so that you can freely distribute copies of it together with Ace films that you have created (and to which you therefore presumably own the copyright).

You can play an Ace film by dragging it on to the Projector icon or by double clicking on the film icon provided that Projector is installed or the computer knows where to find it. The film starts up automatically in a window in the current screen mode (whether or not that is the film's 'native' mode). When the film finishes it will automatically restart; this cycling continues until you intervene.

Clicking MENU within the window reveals just a few of the application's facilities such as freeze frame and reverse, which are self-explanatory. Yo-yo plays the film alternately forwards and backwards. First frame restarts the film (forwards) at the beginning and last frame restarts the film backwards at the last frame. Set mode changes the screen mode (if necessary) to the film's native mode.

Full screen reveals the other facilities in Projector. As its name suggests, it temporarily exits the desktop and commands the whole screen. The benefit of this is that animations run faster in full-screen mode than in a window and some larger films may only be playable at their proper speed in this mode. You can return to the desktop at any time by pressing Escape. All applications will be intact and the film will again be playing in its original window.

If you slide right on the Full screen option without clicking on it you call up a list of controls available in Full screen mode: this is shown in Figure 14.4. The space bar starts and stops the film. The speed of the film can be controlled by entering a number between 0 and 9: the higher the number the slower the film wall play. Return allows you to single-step through the film, while + and - single-step forwards and backwards. F is equivalent to the First frame option and L takes you to the last frame, but does not reverse the film; it simply starts again. Skip to next film only works if you load several films and choose the Roll option from the icon bar menu or if you use the projector to control a whole rolling demo using an obey file-this is explained in the file /Help in the 'Projector directory. 'The frame counting cursor is an optional numerical indication of the current frame number displayed at the pointer position, Clearly a projector is an essential prerequisite if you wish to enjoy films! It was indeed thoughtful of Ace to place this application in the public domain-and in their interest as well as the public's since it can only lead to a greater awareness of the enjoyment available from animations on the ARM machines.

Getting into animation

You may well feel that you want to make your own way in computer animation without the constraints (although they are minimal) of proprietary film formats. In fact it is not that complicated. Computer animation is not some startling innovation that has only been made possible by the advent of the ARM chip. Can you remember those halcyon days when we huddled around the BBC Model B (then seemingly the ultimate in computing power) enthralled by such games as Frogger, Monsters and Snapped These involved simple, but very effective, sprite-based animation. And they achieved it, hard to believe though it now seems, in just 32 Kbytes of RAM which also had to include the screen memory, operating system workspace, the application program and such variable data as the scores and players' names! Bearing in mind what was possible with 32 Kbytes, just think what ought to be possible with 1 Mbyte or 4 Mbytes!

Let's examine the practicalities of sprite-based animation. In the BBC games mentioned above, animation consisted almost exclusively in moving small brightly coloured sprites around the screen against a generally black background. This is indeed the simplest scenario. Moving a sprite from A to B involves plotting the sprite at A, erasing it at A and plotting it at B. Depending on the distance between A and B and the speed with which you wish the sprite to cover that distance you may also plot the sprite at one or more intermediate locations (and erase it again of course before the next plot), there may be moments when the sprite is not on the screen at all, i.e. when it has just been erased at one location and has not yet been plotted at its next location. But provided the time between plotting and erasure exceeds that between erasure and the next plot, this is unlikely to be noticed. Moreover, if the background is black and the sprite is brightly coloured, the human eye will fail to notice such temporary disappearances. Indeed with the ARM and a small sprite, if the plotting instruction follows immediately after the erasure instruction, both may occur in the same interval between frames so that the sprite is never absent from the screen at all.

Plotting a sprite is one matter; erasing it is another. There are several ways this may be done. Simplest is 1,0 first; plot the sprite on the screen using the exclusive-OR plotting mode (plotting action 3 in the ARM SWIs). Then to erase the sprite you simply plot it again at the same point. This has the advantage that it puts the background behind the sprite back exactly as it was before you first plotted it there. But it has the disadvantage that the background colour will affect the appearance of the plotted sprite. Not that this really matters, for you could always design your sprites in their intended colours and then exclusive-OR them with the background colour (by dragging a square of background colour over the design in Paint having first selected EOR) before using it in the animation. Seen in the raw in Paint its colours will now look extraordinary, When it is first EORed against the intended background colour the sprite will be restored to its design colours. And when you EOR it again in the same location, it will conveniently disappear.

An even simpler way to achieve the same effect is to design the sprite with a margin of background colour around its edges. Having plotted the sprite you can now move it in any direction up to one margin's width and simply replot it. Ordinary 'overwrite' plotting action is sufficient. The previous instance will be overwritten by the margin of the new instance and so will disappear. All commendably simple, but the margins make the sprite rather larger than it need otherwise be. Of course, you may not need all the margins. If the sprite is, say, a car that is only required to travel repeatedly from right to left along a level road across the screen, it only needs a margin at its rear end. But few games or other animations are satisfying if all they do is move a single sprite around a screen of solid background colour To add interest we need a few other sprites to move around as well. What happens when two sprites meet?

The answer is with the EOR system, all still works as intended. It's true that you get funny colour effects when one sprite is plotted on top of another having different colours (of course, if you plot a sprite right on top of its identical twin, both disappear). But as each sprite is replotted to make it disappear so it restores the other sprite and the background to its original condition.

So too with the margin system: all will sort itself out in the end, but you may find that the sprite that way first on the scene at the point of collision becomes invisible for a while, hidden beneath the other sprite's margin.

But what happens if, in the interests of realism, you want a detailed background? Suppose you want a car to drive past houses and shops or a man to walk in front of a detailed brick wall or a train to pass a signal box and trees and telegraph poles? If you want all this, you can have it, but it will be costly in terms of computing power,

If the sprite has an odd shape (i.e. if it is any shape other than rectangular) or if its design has windows or gaps through which the background can be seen, you will need to give it a transparency mask. That immediately doubles its memory requirement. Also, if you are using your own software to plot the sprite and if you are calling a SWI (operating system routine.) you must remember to set bit 3 of the plotting action number or the mask will he ignored (and transparent pixels will be reproduced as the highest value palette colour).

As the sprite travels along it will overwrite parts of the background. these will have to be put back. The easiest way to do this is to calculate the exact area where the sprite will next be plotted (you know the sprite's size and intended location so this is no problem.) and to save this area of screen as a temporary sprite using OS_SpriteOp l4. (This will of course take more memory: I said that realism was demanding on computer power.) When you have saved the background as a temporary sprite, you then plot your sprite over that location. Then when you wish to move your sprite on, you plot the temporary background sprite in its original location; this puts the background back as it was, erasing the mobile sprite. Now repeat the process at the mobile sprite's next location. You could use the same sprite name over and over again to save the background, but if, as is likely, you have several such mobile sprites in your animation, each will need its own background sprite.

If two of these mobile sprites, each having its own background sprite, should overlap (for example, if they depict two cars or two trains passing each other) you have further complications. If it is important that one particular sprite should appear to be in front, then that sprite must be plotted last, even if this is out of the normal plotting sequence. Another problem is that when you save the area of background where the second sprite is about to be plotted, it will already include the image of the first sprite and we probably will not wish to include that in the background which we replace when the second sprite moves on, because by then the first sprite itself should presumably have moved on. If your animation allows the possibility of two mobile sprites occupying the same area of the screen, you must before each plot check to see it any other sprites are already there and, if so. then you must erase them immediately before saving the newcomer's background. Then replot the other sprites and lastly the newcomer itself.

All this applies well to cars and trains which don't change their shape as they move, although perspective may well change the aspect ratio of, for instance, a train coming towards you. That can be accommodated by careful separate scaling of the sprite's x- and y-axes as you plot it.

But what about people and animals walking, or even people staying in one place but striking different poses (such as waving their arms)? People (and animals) have such awkward shapes for animation! Forget what I have said about masks and backgrounds. The easiest way to animate people and animals is to use Draw or another vector graphics package. Introduce your background and draw your person or animal in front of it. Then grab the portion of screen with Paints Grab screen area/Snapshot facility. And then change the pose a little for the next frame. This is an ideal task for vector graphics. In fact the layers facility in Vector, DrawPlus and ArtWorks is ideally suited for this. You can lock the background in an unselectable layer, put the first pose in the next layer and copy it into another layer for editing into the next pose and so on. Each time you copy the drawing you copy a piece of background so you need not worry about the background, except that you will need to use the equivalent of the 'margin' system to replace the background behind a walking person or animal. It's costly in memory and processing power, but I did warn you it would be.

It's also costly in artistic ability and powers of observation. You may lie a brilliant portrait artist, but to create an animation of a person walking is something else. You may well discover how little you know about human locomotion! A suitable passage of videotape seen repeatedly in slow motion or frame by frame may help a lot in this respect. So may standing on a corner and watching all the folk go by..