|★ APPLICATIONS ★ CREATION GRAPHIQUE ★ SPRITE EDITOR ★|
|Sprite Editor|The Amstrad User)||Applications Creation Graphique|
Most people are used to animation in Basic using the print command. This is very similar to sprites except they are slow and jerky.
Both types of animation have their advantages and disadvantages. Both types can be produced using Basic although to produce true representations of them you would need to delve into machine code. Sprites are only useful if you want to animate small objects or figures. Vector graphics are used for large scale animation, for example an object which would almost fill an entire screen.
We will be discussing sprite graphics first of all. Animation is the art of fooling the eyes into thinking an object is moving on the screen. What all types of animation rely upon is redrawing of the figure or object several times a second. Basic can be used to produce animation however it is not as good.
Listing 1 is an example of animation produced in Basic. As you can see, animation of this sort is rather flickery. You can control the helicopter by using the cursor keys. Up and down keys simply move the helicopter up and down. Pressing the left and right cursor keys increases and decreases its speed. Good exercise in inertia and velocity isn't it?
Listing 1 fools you into thinking the helicopter is moving by drawing it many times a second. To make it even more realistic there are 4 different frames of the helicopter.
To produce true sprites you really need to delve into machine code. But before we start printing sprites onto the screen we need to create them. This is where listing 2 comes in. This program is a sprite designer.
Unlike Basic type sprites, the sprites you create with this sprite designer can be multi-coloured and are less messier to use. A far cry from flickering single-colour Basic character animation.
You can create up to 99 sprites with this program. It is rather crude and a bit user-unfriendly but I have found that most people like to alter a program to their own needs. Besides, making it foolproof and user-friendly would have doubled the length of an already long program.
Upon running the program you will be asked in which mode you want to design the sprites. The program will only work in modes 0 and 1. Anything else you type in should be rejected. Well, that's the theory.
After this the screen will clear and you should be presented with 3 boxes and several bits of text. The box below the words "Actual sprite" shows the actual size of the sprite you are working on. The box below that contains any prompts or questions the sprite editor might throw at you. The last remaining box contains a blown up picture of the sprite which is where the actual editing occurs. Anything plotted on this is also plotted on the smaller box. The cursor keys will move the cursor around. COPY will plot the current pen on the sprite. T will toggle the trail option on or off. When trail is on the cursor will leave a trail of points behind it whenever it moves.
The < and> keys move the pen pointer selector left and right respectively. The ink colour for each pen is stored in the data statement in line 230. If you're not satisfied with the present ink colours just change their value in the data statement.
M will memorize the current sprite into memory. R will recall a sprite. You will be prompted for which sprite to recall. Remember that you have to press M and then R if you want to edit another sprite. Otherwise, the sprite that you are currently editing will be erased.
S will save a set of sprites and L will load a set of sprites. In both eases you will be prompted for how many sprites you want to save or load and the filename.
The sprite editor will allow you to design sprites of 16 by 16 mode 1 pixels. From now on when we arc dealing with sprites we will be using "byte" co-ordinates. Byte co-ordinates start in the top left hand corner. The x co-ordinate ranges from 1 to 80 instead of the usual 1 to 640 with the normal graphics commands. The y co-ordinate is numbered from 1 to 200.
The sprites that are designed on the sprite editor when measured in byte co-ordinates arc 4 by 16. It helps to remember that 2 mode 0 pixels, 4 mode 1 pixels and 8 mode 2 pixels arc all equivalent to 1 y byte-co-ordinate.
I call it byte co-ordinates because that is how many bytes arc needed to encode one line of the screen. If you multiply 80 by 200 you get 16,000 which is how many bytes constitutes a screen. This means that each of the sprites that you create take up 64 bytes of memory (4*16).
Next month we will be carrying on with the sprite business. All the technicalities will be discussed and several sprite routines will be given.