Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!comp.vuw.ac.nz!actrix!templar!jbickers From: jbickers@templar.actrix.gen.nz (John Bickers) Newsgroups: comp.sys.amiga.graphics Subject: .GL files Message-ID: <4955.tnews@templar.actrix.gen.nz> Date: 29 Jun 91 11:04:17 GMT Organization: TAP, NZAmigaUG. Lines: 36 Folks using my .GL playing program may care to note that it cannot decode .GIF files. .GL animations containing such files die with the error: "Bad magic cookie in header.". My excuse is I wasn't aware .GLs used the .GIF format. :/ Anyhow, this is an opportunity for a rehash of the program - given the problems I believe exist with decoding 8-bit data on the fly, I would like to shift to a two-stage process where one utility "amigatizes" the .GL file, and a second utilility plays it back. This means some things (like changing a 256-entry palette on the fly, which .GLs can do) will never be done with the player running on normal Ami hardware. And an "amigatized" file would not be exportable to other platforms. It also means that we could use external conversion tools to go from .GIF/Pictor to HAM (note that on a friend's version of ADPro, PCX decoding doesn't handle the .PIC files - wierd, but I only saw ADPro in passing, so I haven't checked this one properly). I'd also like the player to have only one video mode (HAM), so support for type 'C' CGA .GL files would disappear. This depends a bit. Some issues are how much RAM (especially CHIP) should it use, will there be a problem with compression (GIF is very tight, and a converted file will probably be larger). Now is the time to suggest useful ideas, lay complaints, etc... to the email address in the .sig, if you can. The ideal suggestion would be provision of some existing Amiga format that can handle the things a .GL does...! -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***