Some Strange Things About Sprites

Qdock on a Q68 512x384 resolution and 16 bit colour.

Looking at the excellent sprites supplied with Dilwyn Jones Qdock program launcher QLheaven found found one surprising thing. The mask/alpha channel of his compressed sprites were run length encoded for 2 bytes for each pixel in the mask/alpha. Was this correct?

Asking on the QL Forum about this brought responses from Dilwyn and Marcel. Dilwyn thought he had used Marcel's png to sprite converter program.

 Marcel stated that only one byte per pixel was ever needed for the mask/alpha and this was also the information in the QPTR manual. Checking the .png converter program the RLE sprites produced by it had only one byte per pixel for the alpha channel whether the sprite was in mode 32 or mode 64. The version of the png converter program here is 1.01 from 2005, but the latest version is 1.04, but has not been tested here as 1.01 works. So far so good, although where Dilwyn made his sprites with 2 bytes per pixel for the mask/alpha is a puzzle unless this was a bug introduced in to later versions of the sprite converter program!

smsq/e is not troubled by the extra data nor is EddIcon_obj the sprite editor used here, or SQRView_obj. SQRView is another program that can add RLE compression to sprites and it also outputs sprites with one byte per pixel in the mask/alpha section when compressed. On the other hand compressed sprites output from SQRView were found to have an extra trailing 4 bytes of zeros padding the pattern and a slightly different RLE compression of the mask. How strange. This was discovered using the ex Digital precision file comparing program "Compare".

 The top sprite View3c.spr was a compressed sprite produced by the .png converter program, while the bottom sprite, View3.spr compressed sprite was produced SQRView from the uncompressed version of the same sprite produced by the same .png sprite converter. As can be seen the lower sprite is 8 bytes longer. Both the are displayed correctly by smsq/e as the offsets for the pattern and mask data are correct for each sprite.

Finally the reason for this interest here is a need to shrink sprites to reduce their size for use in another project, so a small basic compression routine has been written to compress sprites on the Q68. Comparing compression with the sbasic program with the same test sprite from the .png converter things are as they should be.