This article was originally written for the French fan club, ARMada, and covers the following topics:

• How to deal with 256 true-colour palette sprites.
• How to plot sprites in any native modes onto a screen of any mode.

All Basic routines referred to are on the Archive magazine disc. They have been developed with OS 3.6, so I am sorry if you haven't upgraded your OS to that level yet, but this information is ready for when you do.

Sprites with 256 true-colour palette

Our first problem is how to deal with 256 true-colour palette sprites. I will further designate these sprites as 256 true-colour sprites to distinguish them from 256 pseudo-colour sprites. From the desktop iconbar, you can select two 256-colour modes:

• one called '256 greys' that is a 256 true-colour mode. The offered system palette is made of 256 grey colours.
• one called '256 colours' that is a 256 pseudo-colour mode where actually the 256 colours aren't fully independent. I'm not going to comment any further on this video singularity since it isn't relevant to this article.

There are many ways to create a 256 true-colour sprite.

1. The first option is to create one with Paint in the '256 greys' mode and edit the palette to make up each colour with a percentage of red, green and blue colour by means of the colour picker. Unfortunately, in this desktop mode made only of grey colours you won't obtain a realistic view of your artistic talents. A 20 pixel × 40 pixel 256 true-colour sprite created this way and fitted with a mask and the building palette will generate a 3704-byte sprite file when saved on disc. You will notice that, for obscure VIDC hardware reasons, this desktop mode is very slow in redrawing screen sections. So you may decide to switch your computer to '256 colours' mode and edit the palette with the colour picker. In this case, your work will immediately be displayed on screen. Just remember that each colour of the palette can be edited by using <menu> over your sprite and not over the palette as you might think!
2. Another way to go could be to directly switch your computer to '256-colour' mode and create a 20 pixel × 40 pixel 256 colour sprite with Paint. Two possibilities here :
   1. Should you select the 'mono' option, the sprite created is exactly like the one built in case (a). Of course, you can edit its palette as explained above. Saving it on disc with mask and palette attached will again generate a 3704-byte sprite file.
   2. Should you select 'colour', the sprite to be edited is a 256 pseudo-colour sprite. If, at this time, you save it on disc, also fitted with a mask and its palette, it will occupy 2,168 bytes of disc space. It is logically of smaller size than the previous 256 true-colour sprite. You will notice that you can't edit its palette unless you save its palette with a magic drag-and-drop on the sprite itself (only Acorn could master a trick like this). Now, should you want to save it on disc, you will notice that the sprite file has exactly the same size as the previous 256 true-colour sprite, that is to say 3,704 bytes. Magic? No, the only difference with case b-1 is that you have a colour palette instead of a grey one. Surprisingly, sprites created in '256 grey' mode and '256 colour mode' still bear the old mode 28 number.
   3. You can also build such a 256 true-colour sprite by processing a 256 pseudo-colour sprite. The Basic application called '!Create256' does the job of building a 20 pixel × 40 pixel 256 true-colour sprite called 'palette256' in a sprite file named 'Sprite256c' located in the directory Data . In the present case, a randomly built-in palette is attached to the sprite. Basically, a blank source sprite is created with the command 'OS_SpriteOp' 15. Mode 28 is arbitrarily chosen to achieve the same result as above. You will notice that the sprite file 'Sprite256c' occupies 2,904 bytes as there is no mask definition attached. The sprite 'palette256' can be edited with Paint with no problem as before. You can then attach a mask to it. In this case, the end result would be a 3704-byte file when saved on disc.

   As an example, a 60 pixel × 60 pixel sprite called 'test256c' has been created by the same process, but it has then been edited with Paint to add a pattern and a mask. Part of the PRM code supplied on page 1.833 has been used to build this application. OS 3.6 doesn't provide a routine to define the size of a user sprite area to contain sprites to be created. In this application, the memory allocated has been over-sized - I will talk about this problem another time.

To finish this section, one final trick: to discriminate quickly between 256 true-colour sprites and 256 pseudo-colour sprites you just try to edit the palette with Paint. If you succeed, you are editing a 256 true-colour sprite.

Plotting any sprites in any mode

I want to move on to explain how to plot sprites in any native modes onto a screen of any mode.

This issue is very important should you want to develop an application. At one time or another, you will have to handle some redraws of window sections that may contain some sprites of your own and that you want to handle yourself. These sprites have a native format; that is to say a definition dependent on a colour mode. Dimensions are in pixels as conversion to OS units will be handled by the system when you provide the necessary info. Two universal Basic routines are proposed:

• application !PlotSpNoP plots a series of sprites with no palette onto any screen mode,
• application !PlotSpPal plots a series of sprites with built-in palette onto any screen mode.

I use all old sprite types but also new sprites, such as 256 true-colour sprites dealt with earlier, and sprites with 32 thousand and 16 million colours (with no palette) where applicable. Sprites display information on their native mode and are all fitted with a mask. When a palette is attached, it has been edited while creating the sprite to change typical colours as proposed by the system and consequently to show some colour differences between both applications.

How does it work? A universal routine called 'PROCInitialiseSpriteToScreenArray()' is run to initialise both the scale and colour arrays needed as input for the command 'OS_SpriteOp 52' that plots the sprite on screen. While the scale array dimension is fixed at 16 bytes, apparently the colour array dimension never exceeds 256 bytes.

Command 'ColourTrans_GenerateTable' allows determination of the dimensions of the colour array, but I didn't use this procedure as it complicates the code for no reason.

Command 'Wimp_ReadPixTrans' is always needed to initialise the scale array. As for the colour array, it is a little bit more complicated for no obvious reason.

Command 'Wimp_ReadPixTrans' works up to 16 colours, for initialising colour arrays, but beyond 16 colour modes, use of command 'ColourTrans_ GenerateTable' is required to initialise the colour array. This command doesn't work below 256 colours on sprites with no built-in palettes. With these two arrays properly initialised, command 'OS_SpriteOp 52' can display your sprites on screen.

Next time, I will put forward an application that will make use of the same palette stored separately to plot a series of sprites originally edited with this palette, but saved with no palette attached to save disc and memory space.