The Sinclair QL Forum

Hi

I was looking at the RLE compression algorithm of sprites to compress some uncompressed sprites I have as Dilwyn Jones excellent QDock complained that the file size was too big when I tried to use them with this program. The sprites were 32x32. RLE compression algorithm is described in the QPTR manual. Following the described algorithm I found that the alpha channel decompressed to 2 bytes per pixel for the mode 32 sprites that came with QDock. These had been compressed with an item size of 2. In the QPTR manual it is stated that the alpha channel has "one byte for every pixel and nothing more".

So my questions are, is there a reason to pad the alpha channel bytes during compression and discard them during decompression, and for mode 64 sprites with 4 bytes per pixel is the alpha channel padded to 4 bytes per pixel during compression?

Thanks for any answers

Alpha channel is always 1 byte per pixel. One could compress them using the RLE2 algorithm nonetheless, but normally you‘d use RLE1 for it.

Hi

So I should ask Dilwyn why his mode 32 sprites got the alpha channel RLE2 compressed when RLE1 would compress the sprite further.

There isn't any problem with smsq/e handling sprites with the pattern compressed RLE2 or RLE4 and the alpha channel RLE1? I intend to make some.

Cheers

Artificer wrote:Hi

So I should ask Dilwyn why his mode 32 sprites got the alpha channel RLE2 compressed when RLE1 would compress the sprite further.

There isn't any problem with smsq/e handling sprites with the pattern compressed RLE2 or RLE4 and the alpha channel RLE1? I intend to make some.

Cheers

The Q-Dock sprites were mostly made with Marcel's PNGconv program. It was a while back, I don't remember much about it now!

Hi

The Q-Dock sprites were mostly made with Marcel's PNGconv program. It was a while back, I don't remember much about it now!

I thought that might be the case as I don't think there is a program yet for the QL that compresses sprite data. Lovely sprites in Qdock btw.

Artificer wrote:Hi

The Q-Dock sprites were mostly made with Marcel's PNGconv program. It was a while back, I don't remember much about it now!

I thought that might be the case as I don't think there is a program yet for the QL that compresses sprite data. Lovely sprites in Qdock btw.

There is also SMSQEsprites by Wolfgang Lenerz, a Java program, so not running under SMSQE itself.
http://www.wlenerz.com/QLStuff/
Also SQRview can create RLE sprites. New masks can then be made with an even alpha mask.
To make alpha masks with variable values like the QDock ones, you can make them as PNGs for PNGconv or create them from scratch or BMPs in EDDICON or SPRTED. http://www.dilwyn.me.uk/sprites/index.html
Mode64 sprites created in EDDICON can then be converted in SQRview to other modes and RLE'd including the mask.
http://members.upc.nl/b.spelten/ql/
(end of promo)

BSJR

Hi BSJR

I don't think there is a program yet for the QL that compresses sprite data

Thanks for the info about SQRview. When I wrote the above I meant that I was not aware of a program that ran on QDOS or smsq/e that compresses sprite data with RLE.
I have a copy of SQRView 1.02.

Mode64 sprites created in EDDICON can then be converted in SQRview to other modes and RLE'd including the mask.

While I can load a mode 64 sprite from EDDICON and save it out as mode 33 or 32 I cannot see how I can select RLE compression for the saved sprite amongst the options in the various menus of SQRview.

I have checked the sprite files that I saved via SQRview and none of them have the RLEx marker in front of the pattern or mask.
What have I missed in SQRview?

Thanks

Artificer wrote:There isn't any problem with smsq/e handling sprites with the pattern compressed RLE2 or RLE4 and the alpha channel RLE1? I intend to make some.

These are just different algorithms. After they ran the sprite will be uncompressed in memory and only then SMSQ/E makes stuff with it, so it doesn't matter what you choose in terms of functionality. RLE2 and RLE4 were added by me to improve compression ratio as RLE1 on 16-bit data is pretty pointless (unless you've got a lot of black or white going). And more complex algorithms like LZW that don't care as much for item size are much more difficult to implement and also much slower to process.

Marcel

dilwyn wrote:The Q-Dock sprites were mostly made with Marcel's PNGconv program. It was a while back, I don't remember much about it now!

I've checked the code, it should always do RLE1 for alpha masks, but maybe there is a bug or maybe there was a bug in the past. Too lazy to try it

Artificer wrote:Hi BSJR

While I can load a mode 64 sprite from EDDICON and save it out as mode 33 or 32 I cannot see how I can select RLE compression for the saved sprite amongst the options in the various menus of SQRview.

I have checked the sprite files that I saved via SQRview and none of them have the RLEx marker in front of the pattern or mask.
What have I missed in SQRview?

Thanks

It´s a two way process. First do the mode conversion, then load this and RLE will be offered when doing a Save.
Check you have the latest built dated 27/06/2018. A small bug in RLE2 was fixed there.

BSJR