The major problem for Basic programmers writing arcade games on the BBC Micro (apart from the small amount of memory left in Mode 2) is the lack of built-in 'sprite' routines. Now, what are these sprites that software houses are queuing up to give us? A sprite may be considered as a multicoloured user-defined character which is controlled by machine code routines.

It can be made to move smoothly and quickly around the screen without having to write a program in anything more awkward than Basic. The ideas has been implemented on some micros.

When using any of the four packages under review, the first task is to define the required sprite shapes. This is done using a definer program, and these take the form of a grid drawn on a Mode 2 screen, on which the sprite is built by using a cursor to fill in squares. The size of a sprite may vary from a single pixel up to, in one case, nearly a hundred in each direction.

DACC's Sprite-Gen and the standard Simonsoft sprites have a maximum size of 7 x 8, although the Simonsoft product allows 'supersprites', more of which later. Beebugsoft's routine uses a basic cell of 8 x 16 and Sprite Master provides a grid of 96 x 96.

Once defined, the data for each sprite is stored in a reserved area of RAM. Other sprites may then be defined using the same program. Each package allows different numbers of sprite designs; in the order of the heading they are 8, 7, 16 and 12. In addition, three of the routines will allow a number of copies, or 'clones, to be created and moved independently of their parent designs. A total of 32, 21, 16 and 48 sprites respectively may be controlled by the four programs under review.

The ease of use of the definers varies considerably, with the DACC routine the most cumbersome (three keystrokes are required to colour in each square of the grid) and the Beebugsoft version showing head and shoulders above the others. This program offers the definite advantage of being able to store each sprite individually by name, thus allowing a library to be built up for future use. It is also the only program available on disc which speeds up the creation of sprites considerably. Simonsoft has, however, designed the program to be easily transferable from cassette.

All the programs except Sprite Master allow two separate images of each main sprite to be created and displayed alternately from within a program. Some quite sophisticated animation can be built up using this combined with judicious use of the eight flashing colours. Beebugsoft and Simonsoft allow several individual sprites to be moved around as one larger sprite - a 'supersprite'. The size of Sprite Master's character makes this unnecessary, and it is also the only product to offer sprites in all graphics modes, excluding 7.

When using sprites within a Basic program, all but Sprite Master employ a syntax of the form:

100 A%=100:B%=100:Z%=0:CALL Y%

Each of the main sprites (and their respective clones) is assigned two integer variables to take the x and y coordinates of the position they are required to occupy. The number of the sprite or close is then assigned to another variable and a call made to the sprite routine. Thus, in the above example, sprite 0 would be displayed at the given position. With sprites you do not need to delete the character from its previous position, as this is taken care of by the code. All the programs use EOR plotting, so the colours of the sprites will vary when they pass over coloured backgrounds, or each other. The Simonsoft sprites get over this with a routine which will restore any given background after a sprite has passed, while at the same time maintaining its true colours at all times - clever!

Beebugsoft and Simonsoft programs also offer other methods of moving sprites. The Simonsoft is the more versatile in providing repeating flight paths which may be predefined for any sprite. These may take the form of quite complicated patterns of movement. This program also allows the enlargement of any sprite in stages up to five times its normal size. All but the DACC program include routines to detect collisions.

All the sprite routines take up some user RAM to house code and character shapes, and each uses a different amount. DACC houses everything in 1.25K, Beebugsoft uses 2K (2.75K for supersprites) and Sprite Master fills 3K. Simonsoft supplies twenty different routines, depending on whether you require collision detection, enlargement, preset flight paths, etc, between 1.75K and 4.25K.

Out of all this, what recommendations can be made? It is really very much a question of horses for courses: DACC manages to pack a useful program into a small amount of memory, but without collision detection, and a lot of extra Basic may have to be written to achieve this. Sprite Master is the only one to offer multi-mode sprites, and large ones at that. For my money though, Sprite Utilities wins through for its ease of use in most applications, with the Simonsoft product coming into its own when the extra facilities are needed.