I cannot be held responsible for any damage or loss of data as a result of use or missuse of this program.
Command line installation
Please ensure that gif2spr is in a directory pointed to by Run$Path, my copy is saved in the library directory of my harddisc and my Run$Path looks like this.
Show Run$Path
Run$Path(Macro) : ,%.,Boot:Library.,ADFS::HardDisc4.$.Library.
This program appears to be at least twice as fast as ChangeFSI even though ChangeFSI has hand coded LZW decompression. This made me very happy when I tested it.
I've tested the program on 1,2,4,6,7,8 bits per pixel all the routines have been tested since 3bpp uses the 4bpp routines and 5,6,7bpp uses 8bpp I've only tested the transparency on 8bpp and 1bpp gifs, but the masking code is almost identical to the pixel code so should not cause any problems. I did check that part of the code for typos. The images I have were not suitable for creating transparency masks as they were scanned in and did not have large areas of single colour. This program has now been in use for many months with very few reported errors, if you find any please send me the report generated by gif2spr when run with the -v option on the offending GIF file. The GIF file would also be of use.
The -q and -v options should be seperate and not of the form -qv but this would not make much sense anyway. This may change in the future as more options need to be added.
1.04 has fixed a rare problem that occured when GIF's with multiple graphic extensions caused the error message 'liblug: Unkown input file type'
1.05 Another Rare error this was created by me several versions ago. It only happens when an empty transparent index graphic extension occurs in the data stream and generates the message 'liblug: Unkown input file type'
1.06 It appears that there is a program out there on the Mac that generates GIFs with an extra byte compressed on the end of the image data. The effect was to overwrite the beginning of another malloc'd block and caused an error when trying to free that memory. The extra byte only occures when a scan line is a multiple of 4 pixels. I have 6 examples of this problem.
Another problem generated by a Mac program (possibly the same) caused the same error message as above to occur but was because the gif had a strange definition for it's colour map and caused an unallocated pointer to be freed (This is partly bad programming but should not have occured if the gif hadh had it's flags set correctly). As a result of all this gif2spr is now more tollerant of strange GIF files.
My Thanks go to the following people (in no particular order)
Simon Truss
simon@bigblue.demon.co.uk
I can be contacted on this address until about september 95
u1smt@csc.liv.ac.uk
I can be contacted at the following address for a few years yet (It has to be forwarded on, but it will reach me)
23 Charlton Gardens
Coulsdon
Surrey
CR5 1AS