The Sinclair QL Forum

New QL graphics format

Pertains to GD2-capable platforms.

For a number of graphics projects Im working on Ive created a new graphics file
format: RLE-compressed PIC files. Based on a suggestion by BSJR, the format
looks like this:
The uncompressed length can be worked out thus: y-size x line_length, so no need
to specify separately, unlike sprites.

In other words, this is basically the PIC spec headed by a "RLEn" flag.

The RLE format itself is identical to that used for sprites.

Ive been doing some tests with RLE compression on larger objects like (partial)
screen shots, but also of artwork and photo-type images. To me the results seem
promising with, typically, between 90% - 50% compression, and at reasonable
speeds. I have no timings to show yet, but its fast, especially decompression.
For typical screen shots RLE can often return better compression than JPEG! Eg:
A screen shot of a QPAC2 Files window listing 32 files came at 401,390b as a
mode 32 PIC. Converting to BMP24: 150%, JPEG 32%, RLE2 20%.

QL mode PICs are only catered for in a step-motherly way: RLE2 seems to give the
best general results with an average of around 50% compression, which is not
spectacular, but better than nothing.

Unfortunately, SMSQ/E does not provide hooks into the RLE decompression code nor
the various format conversion routines that already are built in to cater for
sprites. However, I have made equivalent toolkits that will do all that, and
they are available to anyone to use.

My upcoming graphics viewer, QuickView (or QV) - and other projects - will
support this format. I mention this here as, since QV etc are intended to cater
for all general QL graphics formats (and the most popular mainstream formats
too), Id hate for another, near-identical-but-incompatible format to turn up
once Im done..

So if anyone has any suggestions for changes or improvements, NOW would be a
good time to bring them up!

As for the file extension, I am still open. Here are some ideas: picc, pcc,
pix,.. Preferences or suggestions?

Sounds interesting. But then again, I'm not a graphics man, so what would I know.

I'm sure it can't do any harm though, and maybe, at some future point, SMSQ will let you hook into the routines.

Have fun.


Cheers,
Norm.

Maybe I'm missing something, but I don't quite get what's the advantage of this proposed format in contrast to a sprite with no mask (which is something I specifically implemented for this usage scenario).

Cheers, Marcel

mk79 wrote:Maybe I'm missing something, but I don't quite get what's the advantage of this proposed format in contrast to a sprite with no mask (which is something I specifically implemented for this usage scenario).

Cheers, Marcel

When a PIC is unpacked to a buffer it can be partially shown in a window with QPTR or EasyP commands.
SPRs must always fit inside the channel and cannot be partially shown or panned/scrolled if larger than the window.
That's why SQRview defaults to converting big sprites to PIC.

BSJR

Thanks Bob for explaining it all again. Additionally one could mention that there are a number of tools, pre-eminently PHGTK, for manipulating graphics, that work mainly with PIC files.
Ultimately, its down to the software available to manage the format, not the format as such. I dont see anything amiss in trying to create more fluidity between them.

Well, then the goal should be to get this integrated into the PE I guess as then you could re-use the sprite code. I'm not volunteering though, your little feature request with the drive name has cost me several evenings already, I'm done for a while
But even if you want to implement this on an application level you should ideally leave the door open for a later integration into the OS/PE, which cannot be done with your proposal. The _PIC format after all is just an on-disk version of the PE's internal save area data structure and putting stuff in front of it breaks the structure. The same is true for EasyPtr by the way, check out the description of WSAIN.
A more compatible approach would be for example to set an additional bit in the MODE byte (bit 7 maybe) and then have the RLEx at the start of the data.

Cheers, Marcel

mk79 wrote:Well, then the goal should be to get this integrated into the PE I guess as then
you could re-use the sprite code. I'm not volunteering though

As it is, Ive done all the work separate from SMSQ/E. Some of the code has been
lifted out of SMSQ/E and some is original. Im not inclined to re-do it all again
just now for the 3.2 people who may possibly be interested. Perhaps later. (Unless
you get there first

your little feature request with the drive name has cost me several
evenings already, I'm done for a while

If you mean the 20 char device name thing, I plead not guilty! My nose was put out
of joint as much as yours.The change didnt come from me or at my request! All
Ive done is spend many hours updating my affected programs to bring them into
compliance (hopefully) with those changes.

But even if you want to implement this on an application level you should
ideally leave the door open for a later integration into the OS/PE, which cannot
be done with your proposal. The _PIC format after all is just an on-disk version
of the PE's internal save area data structure and putting stuff in front of it
breaks the structure. The same is true for EasyPtr by the way, check out the
description of WSAIN.
A more compatible approach would be for example to set an additional bit in the
MODE byte (bit 7 maybe) and then have the RLEx at the start of the data.

I considered that. However, setting bits, or using the spare byte in the
header without also changing the PIC flag, would just cause problems for
existing programs.

What I ended up with, after consultation, was the Partial Save Area as defined
in the QPTR manual (p 155):
Also known to us grunts as the PSA format. I may need to investigate how
Wman/Qptr/EasyPtr handle that. I just assumed they did, since thats what is
specified..

The object of this exercise is to have it out in the open before things get tied
down. As it stands, the format is still easy to change. So Id be glad if we
could find a good solution. Input from anyone who has knowledge of, or an
interest in, this matter is appreciated!

mk79 wrote:.... The _PIC format after all is just an on-disk version of the PE's internal save area data structure and putting stuff in front of it breaks the structure. The same is true for EasyPtr by the way, check out the description of WSAIN.
A more compatible approach would be for example to set an additional bit in the MODE byte (bit 7 maybe) and then have the RLEx at the start of the data.

I must admit that I was not familiar with the WSAIN way of reserving PIC space. SQRview only uses ALCHP for its PICs but tests the header beforehand to see if the 4 spare bytes, as defined in the QPTR docs, are preceding the $4AFC flag.
So as far as QPTR is concerned the proposed RLEx flag does not break that but it can be a problem for programs using WSAIN.
I don't know how Per's tools will implementing this. Is it automatic like WSPR & SPRW or just unpacking it to a valid PIC before so PREST or WSARS can be used? Then also any mode conversion should have been done before that.
The bit 7 way will correctly trigger an error with PREST/WSARS.

BSJR

To my previous message: Sorry, I wasnt thinking straight. Any conversion and/or decompression will have been performed into a normal-looking PIC buffer. So the WSAIN issue is moot.