Headless data files are an abomination, IMHO, as there is no way of knowing for certain what they contain and getting that wrong could therefore easily lead to a systems crash. It helps a little if there are recognised file name extensions. After all we all expect to safely be able to LRESPR a _bin or a _rext file. My main beef is with screen dumps as the same-looking data can mean very different things and there havent been any real conventions regarding what to call them.
When the screen was fixed at 512x256 it might just have been acceptable to call the dump of such a screen dump_scr (_scn was reserved by PSION's Archive). The only ambiguity was whether it was a mode 0/4 screen or mode 8. Partial screen dumps were more problematic, and now with GD2 colour screens, not to mention emulators (such as SMSQmulator which can have variable screen sizes and geometries) things are just getting out of hand.
It is far better to use the PIC or SPR file formats. PIC is just a screen dump, after all, except that it has a 10 byte header that contains an identifying (and reassuring) flag (the illegal instruction code $4AFC) and all the necessary information to display the image correctly. Thus it only requires a single file name extension, namely _pic, to cover all variants of modes and size. Sprites are a little more complex and have other advantages and disadvantages, but that is a chapter on its own.
To enable us to more easily determine the contents of a screen dump (as long as these still seem to be much loved), Id like to suggest the following file name extensions:
sc0 | screen dump mode 0 |
sc4 | synonymous with the above |
scr0 | synonymous with the above |
scr4 | synonymous with the above |
dmp0 | synonymous with the above |
dmp4 | synonymous with the above |
sc8 | screen dump mode 8 |
scr8 | synonymous with the above |
dmp8 | synonymous with the above |
scr | screen dump mode 0 or mode 8 |
dmp | synonymous with the above |
sc16 | screen dump mode 16 |
scr16 | synonymous with the above |
dmp16 | synonymous with the above |
sc32 | screen dump mode 32 |
scr32 | synonymous with the above |
dmp32 | synonymous with the above |
sc33 | screen dump mode 33 |
scr33 | synonymous with the above |
dmp33 | synonymous with the above |
sc64 | headless graphic dump mode 64 |
scr64 | synonymous with the above |
dmp64 | synonymous with the above |
Clearly the scrXX and dmpXX variants are dubious as they are five characters long, but what the hell, one doesnt have to use them!
All the above are mainly to be taken to mean full screen screen dumps in a number of standard sizes. However, they may usefully stretch to cover part-screen dumps as they at least give a clue to the correct mode, leaving only one unknown left to guess.
By standard sizes typically 512x256, 1024x512, 1024x768, etc for modes 0..8 are meant. The file sizes will normally suggest the correct dimensions. Once you throw GD2 modes 16..3X into the mix there are a number of possible "standard" sizes between 512x256 and 1920x1080 (and beyond), based on typical QL/SMSQ platforms. However, file sizes alone cant be relied on as they are not unambiguous. Eg 1024x768 mode 0/8 is 196,608b, but so is 512x384 mode 16, etc, so knowing the mode helps a little.
The PIC file format is the obvious solution. It looks like this:
* * Definition of PIC header * pic_flag equ $00 word FLAG word pic.flag equ $4afc what you expect to find there pic_xsiz equ $02 word total X SIZe pic_ysiz equ $04 word total Y SIZe pic_rinc equ $06 word Row INCrement (Distance from one row to next in bytes) pic_mode equ $08 byte MODE of saved data pic_spar equ $09 byte SPARe pic.hdrl equ $0a HeaDeR Length
While simple and versatile PICs have one main problem: File sizes tend to be massive. Therefore I have seen fit to apply a simple, fast compression method on them - the same as used with PE2/GD2 sprites. To differentiate them from the uncompressed PIC files, Id like to register the following file name extensions:
pac | RLE-compressed PIC files (PACked picture) |
pcc | synonymous with the above (PiCture Compressed) |
The PAC file format is very similar to the standard QL PIC file format. The only differences are the "RLEx" long word tag prepended to the header and the fact that the graphics data following the header is RLE-compressed:
* * Definition of RLE-compressed PIC header or PACked file * pac_rlex equ $00 long "RLEx", x = 1, 2, or 4 pac_flag equ $04 word FLAG word pac.flag equ $4afc what you expect to find there pac_xsiz equ $06 word total X SIZe pac_ysiz equ $08 word total Y SIZe pac_rinc equ $0a word Row INCrement pac_mode equ $0c byte MODE of saved data pac_spar equ $0d byte SPARe pac.hdrl equ $0e HeaDeR Length
The decompressed data size is worked out as pac_ysiz x pac_rinc
The RLE format (lifted from the SMSQ/E source documents) goes like this:
* The utility works with three different element sizes: byte, word or long * The output consists of one byte followed by one or more elements. * A count byte of 0..127 is followed by count + 1 elements of uncompressed data * A count byte of 128..255 is followed by a single element, that was found to * be repeated consecutively in the source data 257 - count times
No man is an island: I should mention that the compression format above was originally implemented for GD2 sprites by Marcel Kilgus, and Bob Spelten Jr's ideas were adopted in defining the PAC format and extension name.
While we're at it we might as well add the original PSA definition here too (This from SMSQ/E's keys/qdos_pt, originally from the QJump team):
psa | Partial Save Area |
* * Definition of partial save area header * ptp_link equ $00 long user defined LINK longword ptp_flag equ $04 word FLAG word ptp.flag equ $4afc what you expect to find there ptp_xsiz equ $06 word total X SIZe ptp_ysiz equ $08 word total Y SIZe ptp_rinc equ $0a word Row INCrement ptp_mode equ $0c word MODE of saved data (normally ms byte) ptp_bits equ $0e ptp.hdrl equ $0e HeaDeR Length
At present only my QV (QuickView) can display these files, but at least one other graphics viewer author has expressed an intention to update his viewer to support PAC files. (I wont mention any names so as not to put undue pressure on the persons involved ;o) I hope the format will be taken up by others as the advantages become apparent..
In the meantime one can use the SBASIC tool, Pac2Pic_bas, found in the GO SUB section of Knoware.no, to unpack PACs. (There are also an SBASIC version of the RLE-compressor, enrle_bas, and a PIC packer, Pic2Pac_bas.)
In the Knoware.no toolkit section, you can find a suit of commands, complete with assembler source code, that does the actual compression/decompression
So thats it, folks. If anyone has better ideas, or knows of well-established variants Im not aware of, now might be a good time to mention them, as Im about to finalise some software for public consumption that will largely rely on these extensions.