GL Documentation  Software: 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. The CLI usage is: WSH 3> gl [-g] [-p] 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. The optional [-p] parameter tells GL to use the picture offset positions given in the .PIC files as their initial offset positions. 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, it is possible to send input to it. There are two "input windows of opportunity". The 1st is at the end of each command, when GL does a quick check of it's task signals. The 2nd is during the .GL "waitkey" command. Window 1: no delay. ^C in the CLI you started GL from will kill it. Esc will quit. Space will go into pause mode. Window 2: will delay until "waitkey" timeout occurs. Esc will quit. Space will go into pause mode. Once in pause mode, a few key commands are available: Space will leave pause mode, but reenters it at next window 2. The 'S' key will save the current screen as an IFF ILBM. The 'I' key will output some status info to the console. Any other key leaves pause mode. GL was written on an A2630. I've optimized some parts of the drawing for VGA 'L' animations in assembler, but GL is still a little slow on a 68000. 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. People on Usenet have recommended Director 2.0(*) for this purpose, though as far as I know no-one has tried it. Let me know if you do (or if you can get format specs, and want me to take a shot at writing an automatic converter). (*) Note I have no affiliation with this program. I've never even _seen_ it. 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. Known problems: Symptom: the right edge of a "clip" disappears from time to time. This is a fault in the shifting routine not correctly handling clips that overlap the left edge of the screen. Symptom: parts of the picture are being drawn as black. Some animations load "clip" data before they load "pic" data. "clip" data does not usually contain color information, so when the image data is converted to bitplane format, the result is a blank clip, since the colors in the palette have not yet been initialized. To do: Implement GRASP commands/video modes as required, I guess. No big deal. As I get new animations, I'll implement basic stuff required to play them. More assembler. Consistent operation across video modes and similar operations. Dithering in the grayscale mode? Change in the way things are done, to use the Blitter, double buffer, etc? 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 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. The nature of the animations is not a problem either. X-rated or clean are both fine. 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. History: GL1.0 Began on 23rd Mar '91. Didn't do clips right. GL1.1 Released. 68000 performance is slow and looks wavy. GL1.2 Has some assembler optimization. 68000 copying performance is ok. Still slower than it should be, but the waves appear to be significantly reduced. GL1.3 Added a variety of commands, transparency, offset positioning, etc. Mostly motivated by animations received from David Yee. Disclaimer: "It works on my machine" (so far :).