GL Documentation  Program: GL GLSplit Pictor Purpose: To fiddle with GRASP animation files. These are found on PClones, with the extension ".GL". GRASP is a product of Microtex Industries, Inc. Author: John Bickers (JJB Templar) - jbickers@templar.actrix.gen.nz Credits: This was written using SAS C 5.10a. The digital dissolve effect (fade 20) is from "A Digital 'Dissolve' Effect", by Mike Morton, pg 221 of "Graphics Gems". The format of a .GL file was obtained from the documentation file for xgrasp, a Sun .GL player written by Patrick J. Naughton (naughton@sun.com). This file included what appears to be documentation from an early (Useware) version of GRASP. The formula to convert from an RGB triple to a grayscale level is from Usenet's comp.graphics FAQ. Motivation is from MANDY-2.GL, which I saw running on a PS/2, and which convinced me that perhaps PClone animations are worth noticing. Using GL: This program is the .GL player. It has a number of limitations, which include no font or text support, only two fades (0 and 20), etc. However, it plays MANDY-2.GL ok, which is all I ask. The CLI usage is: WSH 3> gl [-g] filename The optional "-g" parameter tells GL to use a grayscale colormap for the data. This is usually necessary for VGA animations, which have 256-color palettes. The original 256 colors are then mapped onto 16 gray levels. Note that this makes a number of GRASP color commands and tricks useless, since the source data is converted into 4 bits per pixel during the "cload" or "pload" commands, and cannot be remapped to a new palette. GL can only handle two of the many video modes a .GL may have. These are CGA 640x200/1 ('C'), and VGA 320x200/8 ('L'). These happen to be the only sample files available to me. I'd be happy to add more, should the opportunity arise. While GL is running, there are a few keystrokes available to the user. These only take action when the animation pauses for input, so don't be surprised if it takes a while for a keystroke to have an affect. Esc terminates the animation. Space puts the animation into "command mode". In this mode, pressing 'S' will save the screen as an IFF ILBM, pressing Space will advance the animation to the next input position, then go straight to command mode, and any other reasonable key should resume the animation. GL was written on an A2630. I've tried it on the 68000, and it is quite slow, sorry. There are no waves when updating clips on the 68030. In my opinion, converting a .GL to something nice for the Amiga is too much hassle to write a free program for (I don't know any convenient Amiga formats, for example. ANIM option 5 is out). The easiest approach is probably to extract the elements of the animation, convert them to HAM if necessary, then put them back together using an Amiga animation program. Using GLSplit: This is like GRASP's "GLIB" program, but with extraction and listing capabilities only. A .GL file is similar to an archive, and GLSplit will allow one to extract any file one wishes. The CLI usage is: WSH 3> glsplit [-l] [-oprefix] [-xname] filename If no options are specified, glsplit will extract all files from "filename" into the current directory. The optional "-l" parameter will produce a list of the files within the .GL. The optional "-o" parameter specifies a prefix for the output files. For example, if one wanted to extract all files to ram:, one would use: WSH 3> glsplit -oram: filename The optional "-x" parameter specifies that a particular file should be extracted. For example, if one of the files in the .GL file happened to be "main.txt", you could extract just that file with: WSH 3> glsplit -xmain.txt filename Using Pictor: This program is intended to either display or convert PCPaint picture files. These include the .PIC and .CLP files found in .GLs. The same video modes are recognised as with GL - that is, Pictor only knows how to handle CGA ('C') and VGA ('L') pictures. Again similar to GL, Pictor displays 'L' mode pictures into a 4-bitplane LORES screen. The CLI usage is: WSH 3> pictor [-vo] [-g] [-sname] [-lname] [-wname] filename The optional "-v" parameter generates information from the header of the picture. If an 'o' follows the 'v', then this is all the processing that occurs (ie: [v]erbose [o]nly). The optional "-g" parameter uses a grayscale colormap. HAM etc conversion is better done with other tools, like HamLab(*). The optional "-s" parameter tells Pictor to save the colormap of the picture as a seperate file. The default name is "ram:savecolor", and can be overridden by placing a filename directly after the "-s". The purpose of this parameter is to provide .CLP (clip) pictures with a colormap, since they do not usually have one. For example, if you had two files "palette.pic" and "clip1.clp", you could display the .clp file with: WSH 3> pictor -s palette.pic WSH 3> pictor -l -g clip1.clp ;or pictor -l -w clip1.clp The optional "-l" parameter tells Pictor to load the colormap for the picture from a file. The default name is the same as for the "-s" parameter. This colormap can be used along with the "-g" and "-w" options, either to display correct grayscales, or to write out the correct colormap to the FIG workfile. The optional "-w" parameter tells Pictor to write out the picture as a workfile for my FIG(**) programs. The default name is "ram:pictor.wrk". Older versions of the FIG software will not work with these files, since I've added a two-byte identifier to the workfile header in order to identify them to HamLab. I either use FIG, or a filter that reads a workfile into HamLab, to process these files. (*) HamLab is an image conversion package written by Ed Hanway. The package is shareware, though freely redistributable versions are available. As of this writing, the version number is 1.1, and Ed's email address is "jeh@sisd.kodak.com". (**) FIG is an image conversion package written by me, before I got HamLab. I still find it useful, since it only fiddles with 8-bit data (therefore requires less space) and is script-driven. To do: Implement GRASP commands/video modes as required, I guess. No big deal. Use the Blitter for updating clips etc? Would be faster (and easier than using assembler), but display updates would flicker a lot, and it would require more CHIP RAM than it currently does. Assembler optimizations of some of the drawing stuff? Dithering in the grayscale mode? Personal stuff: Suggestions are welcome, and may even be implemented. I can be contacted at the following: Snail: John Bickers, 214 Rata St, Naenae 6301, New Zealand. Email: jbickers@templar.actrix.gen.nz Phone: 677-334, 672-085, or 746-625. People who use this program are also invited to send some notification of their existence to any of the above points. Feel free to pay something (esp. if you want to request that something be added :) too, but payment is not a requirement. I'd be more interested in X-rated animations, actually (NOT NOT NOT via email! I have to pay $$ for that!). Either Amiga disks, or MS-DOS disks up to 1.4M, are ok. This program may be redistributed freely, but not for commercial gain (ie: Fred Fish type costs are ok). Note that you should include the documentation. GL, GLSplit and Pictor are Copyright © 1991 by John Bickers. Heh. History: 19-Mar-91 GLSplit 1.0 Begun. 20-Mar-91 Pictor 1.0 Begun. 23-Mar-91 GL 1.0 Begun. 24-Mar-91 Pictor 1.1 Allow -w for CGA mode. 26-Mar-91 GL 1.1 Now unpacking VGA pixels at [cp]load time. Fixed box, cfade and fly y coordinates. 30-Mar-91 GL 1.1 Fixed non-byte-aligned clips. Disclaimer: "It works on my machine" (so far :).