Last time (13.9 p63), we learned how to plot any sprites (with or without built-in palette) onto a screen of any mode by means of a universal routine. This time, I am going to present another way to plot palette sprites onto the screen.

Should you want to plot a big collection of sprites, built from the same native mode and the same palette, you may logically be interested in sparing both disc and memory spaces. For example, when you save a 256 true-colour palette sprite with its palette, it will occupy 2,048 bytes more than the same sprite saved with no palette. Consequently, for a collection of 20 true-colour palette sprites, you can save up to 40,000 bytes of space if you can just handle one single palette for all of them. This is what I will describe hereafter through two different methods.

Method 1

All the sprites are saved with no built-in palette, the latter being saved separately.

a) To generate the single common palette to use for colour processing: Simply use the Palette save option in Paint, once the collection of sprites have been edited with this particular palette, and then saved without it. You will then get a datafile of type "Palette" equivalent to &FED.

b) To make use of this palette data file: As explained last time, construction of the scale array for plotting on screen is an easy task, whereas generation of the colour array containing information on colour translation is more difficult to obtain. I propose to make use of the command "ColourTrans_GenerateTable" where both the sprite mode and palette data are to be provided as input. Unfortunately, palette data to be supplied to this command has got a different structure from the one as saved by Paint! Let us examine it in more detail:

• The palette as stored with Paint has six-byte entries, but the palette definition as needed by command "ColourTrans_GenerateTable" has four-byte entries with each first byte equal to &00 which is not the case in the saved palette. Therefore some processing is required to remove the two first bytes and to make the first byte of each four byte-entry equal to &00. But this isn't all!
• Palettes saved in 16-colour modes have four extra entries of six bytes each, the meaning of which is not known to the author (very likely for flashing modes). Therefore, for 16-colour modes, some extra processing will have to be done to remove these bytes.

I haven't found any information included in a header of the data file that would help to discriminate between the different colour modes. Counting bytes would make a distinction between 256 true-colour sprites and 256 pseudo-colour sprites impossible as both data files have the same number of bytes (256 times 6 bytes = 1,536 bytes). This isn't a problem as all this is supposed to be known by user choice.

Processing of the palette is achieved by function "FNProcessPaletteForColourTrans_GenerateTable" that loads raw palette data and returns a pointer to the palette structure usable for command "ColourTrans_GenerateTable". Basically, it shrinks the original data file buffer from the same buffer pointer making no extra space necessary for the processing job.

Routine "PROCInitialiseSpriteToScreenArrayWithPalette" initialises both scale and colour arrays for plotting on screen.

Method 2

All the sprites but one are saved with no palette, the palette being saved with one particular sprite.

a) How to generate the palette to use for colour processing

Simply extract it from the particular sprite data (the one saved with built-in palette) that includes it. To achieve this, I use command "ColourTrans_ ReadPalette" where I supply the necessary input data. This command first allows you to get the size of the destination buffer to collect data. Then allocation of the necessary memory space is achieved by executing the same command.

b) How to make use of this palette data

In this case, data is properly formatted for use by command "ColourTrans_GenerateTable".

The Basic programs !PlotwPal1 and !PlotwPal2, for methods 1 and 2 respectively, are provided on the magazine disc. Just for comparison purposes, sprites are plotted on the bottom row using the routine tested in last month's article applied here to sprites with built-in palette, and on the top row with the new one.

It shows that processing the colour array is much slower when a specific palette is provided with method 1. This isn't a problem for the redraw procedure as computation of the translation table is done once for all.

With what has been proposed in this and the previous article, you can now use whichever routine looks appropriate to you to plot sprites on screen. They make plotting of sprites mode independent, which typically makes them fully usable for Wimp applications. As they contain, in some cases, generic code, this may be optimized for specific sprites where, for example, some tests become useless.

When the Wimp sends a message indicating that a screen resolution change is taking place (automatically sent by the Wimp when the application is first executed). The user can then initialise scale and colour arrays accordingly. As for plotting sprites on screen, it is typically handled through redraw routines.

In the third article, I will tackle the problem of plotting any sprites located in a user area.