Animation

Animation





[ This was a series of two articles by the same author,


both dealing with animation through direct storage and


recall of whole screens. Both articles are below. You


should also have a TZX file with all the programs, and


some screen shots representing the illustrations that


went with the articles. Most of these consisted of the


screens used in the programs themselves; I wasn't going


to put these on the TZX a second time, but in the pro-


cedure described it turned out to be necessary to have


them on some TZX, so I decided it might as well be the


same one.]





Moving pictures





Is your Spectrum inanimate? Mike Rapps


demonstrates how to put it through the motions





One of the significant advantages of the 48K Spectrum over


its 16K little brother is the ability to store and recall


four or more screen displays. The recalling of such


screens, using a short machine code routine, can result in


very effective animation displays. Use is made of the


powerful LDIR instruction, which recalls an entire screen


in a fraction of a second. Interchanging the screens rapid-


ly in this manner gives rise to the animation effect.


The technique is illustrated by two examples, first a


simple representation of an internal combustion engine


piston and, second, a practical application turning your TV


into a very workable disco light set. The technique is


limited only by the user's imagination.


The screen storage program which enables screens to be


stored safely above RAMTOP is shown in figure one. The data


for the store routine is contained in line 100 and that for


the recall in line 110. Lines 220 and 230 calculate the


POKE values which are necessary to adapt the routines for


the various individual screens. Each screen, including its


attributes, occupies 6,912 bytes. For security and conve-


nience they are stored 7,000 bytes apart and start at bytes


33,000, 40,000, 47,000 and 54,000. Enter the storage


program and SAVE it. [It's on the TZX as "Storage".]


To produce flicker-free animation, it is important that


each screen is based on a template which remains constant.


The template for the "piston" program is shown in figure


two. That was produced using the Melbourne Draw program,


which is also very useful at a later stage when adding


details and attributes to the individual screens. Similar


professionally-produced programs would no doubt serve as


well and home-made drawing programs could suffice. [This is


on the TZX as "piston tpl". My version, which is somewhat


cruder than the original, was made in... Gilsoft's PAW! In


case someone wants to improve on it, the PAW database is


also on the TZX.]


Once the template has been produced it should be saved on


tape as a SCREEN$. It can then be re-loaded and modified to


produce the four individual screens, adding details and


attributes as necessary - for the "piston" screens see


figure three. They should also be saved on tape, sequen-


tially, as individual SCREEN$. ["piston 1" ... "piston 4".]


We need a program to control the animation. The program


for the piston animation, which can easily be adapted for


other uses, is shown in figure four. Lines 100, 110, 120


and 130 call the machine code routine to supply the various


screens in order. That is achieved by poking into the fifth


and sixth bytes of the recall routine - see line 110 of the


storage program - the following values relating to the


addresses from which the screen is being recalled:


Screen Poke Poke


start byte fifth byte sixth byte


33,000 232 128


40,000 64 156


47,000 152 183


54,000 240 210


The overall effect is that the four individual screen


eventually will be recalled sequentially, producing an


animation effect. As a refinement, the program has been


modified to give two options. Either it will run slowly,


allowing the individual screens to be seen and labelled,


or it will run at speed, in which case it appears to rival


the original.


Once the control program has been evolved, it should be


saved - SAVE "" LINE 999 - at the beginning of the tape


which is eventually to be used for the whole program. Leave


the tape set at the end of the program, clear the computer,


LOAD the storage program and RUN it.


With the storage program running, return to the tape on


which the four screens are saved. Load the first of them


and activate the storage routine with GO TO 200 - do not


use RUN, since that will clear the screen, which is some-


what counter-productive. In response to the prompt, store


that screen with storage number 1. Then CLS [or not, since


the next step is:] load the second screen and store as


number 2. Repeat the procedure for the third and fourth


screens.


Once that has been done, return to your main tape and,


immediately after the control program, save the block of


score which includes the four screens. That should be done


as SAVE "name"CODE 32000,29000 - see line 999 of control


program. That will pick up the recall routine automatic-


ally, stored at byte 32,000 onwards, which the control


program will use. The tape can then be re-wound and the


program run automatically. [The program is on the TZX as


"Piston", and autoruns to load "pistons"CODE.]


An interesting variation is used in the program listed in


figure five. The procedure is largely the same, the program


being saved on tape and followed by the block of code,


including the recall routine and four screens. The template


for those screens consists of a screen produced by the


following CIRCLE commands:


39, 40,32


127, 40,32


215, 40,32


39,135,32


127,135,32


215,135,32


The six circles thus produced simulate disco lights and


each is filled with a different INK colour in each indivi-


dual screen, so that a flashing effect is produced - my


view is that a block PAPER background produces the best


effect. [This program is on the TZX as "Disco".]


Once the program has been saved and is running it con-


trols the flashing effect by using the value of up to 255


returned on the computer EAR input socket, using the simple


machine code routine contained in subroutine 400 to deter-


mine it.


Each time the value jumps by three or more from its


previous value, line 115 calls in the next screen by means


of the main subroutine - line 500 - and various subsidiary


subroutines - lines 1000-1310. The figure of three is obvi-


ously adjustable but appears to produce the best results.


With the program running a musical input can be directed


through the EAR socket and at a suitable volume will pro-


duce the flashing effect, controlled by the beat of the


music. The difficulty with using a cassette player is that


the use of the EAR socket on the player cuts out the loud-


speaker, which is somewhat self-defeating. On my player,


the jack plug can be manoeuvred into a half-in, half-out


position, which allows both functions simultaneously but


that is somewhat precarious.


I have produced a much more satisfactory arrangement on


my music centre where I have run an extra two-core sound


wire out of one of the loudspeakers, terminating it with a


standard Sinclair jack plug which can then be plugged into


the Spectrum EAR socket. The music centre is thus effec-


tively interfaced through the Spectrum to the TV.


___________________________________________________________





Night moves





Mike Rapps brews up a midnight storm


using machine code animation





In the August issue of Sinclair User we investigated simple


machine code routines to store and recall, virtually


instantaneously, a number of different screens of graphic


information to produce simulated animation.


This month we will explore further the possibilities of


animating scenes on the 48K Spectrum. The end result is a


visual effect which, hopefully, is both interesting and


entertaining.


One problem of exploring the technique is that the pro-


gram which controls the animation is related very closely


to the actual screens on which it operates. As these are


stored as a literal SCREEN$ it is obviously impractical to


convey them exactly. However, illustrations of the three


screens used initially appear in Figure 1, and for those


who wish to reproduce the screens used, a second illustra-


tion of the first screen with a grid superimposed on it -


Figure 2 - is provided; the other two screens are, as can


be seen, developments from this. [The screens themselves


are on the TZX as "scene 1" ... "scene 3". They were made


in the PAW, just as for the first article, and again the


database is on the TZX as well. The illustration with the


grid is _not_ on the TZX. If you want something similar,


load the database in the PAW, modify the Graphic for loca-


tion 1, and press Symbol Shift-Y.]


The screens were produced using the Melbourne Draw


program, and the machine code routines used are largely


derived from Super Charge Your Spectrum by David Webb,


published by Melbourne House. Other routines could just as


well have been used to produce other effects, but the main


object is merely to illustrate possibilities.


The Basic control program used is listed in Figure 3.


That should be typed in and saved: SAVE "storm" LINE 999.


Immediately following that should be saved the block of


code, a dump of which is given in Figure 4. The code is


given in hexadecimal and should be read in rows from left


to right. It may be entered using the short loader program


listed in Figure 5, eltters to be entered in lower case.


The dump contains reference numbers underlined to show the


first byte of each of the various routines, and should be


ignored when entering the code. They refer to the list of


routines - Figure 6. When the routines have been entered,


they should be saved after the Basic program: SAVE "rou-


tines"CODE 32000,360.


Finally, the three screens used should be assembled into


a single block of code using the prodedure and the screen


storage program given in the August article. That block


should then be saved as the third element of the program,


immediately after the routines. The screens will commence


at address 33000, and should be saved: SAVE "scenes"CODE


33000,21000.


Let us take a look now at how the action unfolds. It is


the dead of night. One by one, the lights of the house on


the hill go out. A violent thunderstorm erupts, with


lightning casting eerie reflections on the house. The storm


abates, the moon rises, the stars come out - even a few


shooting start. As morning approaches, the lights are re-


kindled.


_________________________________________________________





Program explanation


Line 20 Deals with the initial colour settings.


Lines 30-40 The machine code recall routine at 32012


calls in the second screen as a title screen.


Before it can do that, the routine has to be


given two POKEs - in the fifth and sixth


bytes - which tell it the start address of


the screen to be recalled. A table of which


POKEs is given in figure 7. A text title is


printed, with a pause following.


Line 60 Clears the screen, using the routine at 32320


Lines 90-100 Supplies fresh POKEs to the recall routine


and calls in the first screen.


Line 110 Prints three lit windows on house


Line 120 Pause, then re-calls first screen


Line 130 Prints two lit windows on house


Line 140 As 120


Line 150 Prints one lit window on house


Lines 160-170 As 120 followed by a pause


Lines 200-210 Sets up an outer loop of three, so that the


following action takes place three times. On


each occasion, a nested loop uses the recall


routine, suitably POKEd, to call in the


second screen (line 200) followed by the


first (line 210) in rapid succession, thus


giving the "lightning" effect


Line 220 A further loop produces the 'thunder' - what


do you expect on a Spectrum?


Lines 230-240 Pause. Return the outer loop.


Line 300 Provides the POKEs necessary to use the


rightward pixel scroll routine at 32025 to


scroll away the clouds. The routine works on


a defined rectangle within the screen. The


rectangle has co-ordinates for its upper left


(x1, y1) and lower right (x2, y2) corners.


The x co-ordinates are the usual horizontal


character positions (0-31), but the y co-or-


dinates work on a pixel scale (0-175) reading


vertically down the screen, not the usual


PLOT co-ordinates which read upwards. The


POKEs, taking s to equal the routine's start


address of 32025, are: s+32, x1; s+37, x2;


s+1, y1; s+23, y2. POKE 23361, 0 leaves a


clear screen immediately behind the scroll.


The POKEs used in the line define a rectangle


which covers the clouds


Line 310 Calls the routine set up in line 300 a suffi-


cient number of times to scroll away the


clouds, with suitable pauses to slow the


action


Line 320 Similar to 300, but sets the upwards pixel


scrolling routine at 32150 to operate on the


moon. The rectangle co-ordinates are simi-


larly defined, the POKEs being: s+15, x1;


s+36, x2; s+1, y1; s+23, y2.


Line 330 Similar to 310, scrolling the moon


Line 400 Sets up a loop for plotting the start to


random co-ordinates. The parameters of the


y co-ordinates are set to encompass only the


upper sky part of the screen


Line 410 Excludes any random co-ordinates which would


plot stars over the moon


Line 420 Carries out plotting of stars, with random


colour, and returns loop


Line 430 Saves, as screen four, the existing screen.


To do that, the screen save routine at 32000


is used, with appropriate POKEs as set out in


Figure 7. In the case of this routine, it is


the second and third bytes which must be


POKEd.


Lines 500-510 Sets up UDGs for shooting stars


Line 520 Sets screen recall routine to fourth screen


Line 525 Sets up outer loop of six, so that there are


six shooting stars, followed by a semi-random


initial horizontal co-ordinate for each


Line 530 Sets up inner loop of eight, and prints the


shooting star on each return of the loop


Line 540 After a pause, recalls the fourth screen,


thus overprinting the star. The star horizon-


tal co-ordinate is then decreased by one,


which within the loop makes the star move


diagonally across the screen.


Line 550 Returns inner and outer loops


Line 560 Brings house lights back on


Line 570 After a pause, clears the screen using the


routine at 32270


Line 600 Resets recall routine to daytime and calls in


that screen


Lines 630-650 Opportunity to review


Line 999 The auto-run line, which sets RAMTOP to


protect the code and loads the two blocks of


code.


_________________________________________________________





Figure 6. List of routines





Start address Routine


32000 Screen save


32012 Screen recall


32025 Horizontal scroll


32150 Up scroll


32270 Screen clear (fade)


32320 Screen clear (shift)


_________________________________________________________





Figure 7. List of POKEs





Screen number Start address Poke 1 Poke 2


1 33000 232 128


2 40000 64 156


3 47000 152 183


4 54000 240 210





For screen save routine POKE 1 should be in second byte


of routine, POKE 2 in third byte. For screen recall


routine POKE 1 should be in fifth byte of routine, POKE 2


in sixth byte.


_________________________________________________________