INTRODUCTION Graphic Display System - GDS One day, I was working on a simple card game and needed a variety of cardback graphics. I referred to a library of GIF files for some good scenery to put on the backs of cards and found about 30 files which had nice scenery and pieces which could be used quite nicely. First, I converted a set of GIFs into IFF format and loaded them into Deluxe Paint II Enhanced. Deluxe Paint is one of the more powerful paint programs, and I was very surprised to find that the brush size is limited to 64K (a forgivable programming limit). After messing around with grids and reducing chunks of images down in a nice orderly fashion, I did not get the results that I wanted, I deleted the whole bunch. I was very happy to find a program called GIFDESK on a bulletin board. It seemed to be just what I was looking for, and it solved another problem for me also. The documentation said it could reduce GIFs, but it was designed for cataloging pictures, rather than just image reduction. Great! Now I could get the graphics done, and I could catalog my 150 megabytes of GIFs! WRONG. GIFDESK is great for a simple catalog program, but it doesn't do much for preserving images. The version I have simply grabs dots from the original and slaps them in a reduced space. Although I'm not sure, it seems to also use a generic palette which further reduces the quality. In short, all images get stomped on, some are very simply unrecognizable. Another problem which was mounting in the back of my mind was that every GIF viewer I've seen either has mounds of technical problems/ quirks/bugs, or a user interface that would scare the average user. I was disgusted, in between projects, and wired on coffee. I downloaded CompuServe's GIF file specifications for encoding and decoding and got to work. A day later, GDS 1.00 was a reality. I make no claims that GDS is everything. The general outline of the program is based around a very few simple concepts, and there is certainly room for improvement. Ironically, many users keep a collection of viewers available in case they run into this well known scenario: "Oh that picture! You have to use this viewer for that one..." GDS overcomes a lot of common problems like "odd aspect ratios" and enormous pictures. I have many VERY large or odd shaped GIF's that I had never seen completely before I wrote GDS. GDS handles images up to and including 2048x2048, and should be able to reduce any 2048x2048 image down to 32x32 with no problem (300 would fit on a single 640x480 screen)! The last but not least effort before version 1.07 was to support the GIF89a file format. Reading and writing these files was no problem, except that we couldn't find another viewer that would display '89a images properly. So . . . GDS will continue to write GIF87a files until the other viewers are up to speed. It has now been several weeks since the first releases of GDS, and the response thus far has been overwhelming. Only three weeks after the release of GDS 1.07 on CompuServe, GDS107.ZIP received over 190 downloads! That level of interest is phenomenal on CompuServe since the existence of GDS is not publicly advertised in any forums, BBS's, etc. When I first wrote GDS, I had no idea how much all of you wanted it. Now I do, and this latest version demonstrates how I intend to continue improving it. Many thanks go to all of you who have been invaluable in helping solve hardware and software problems, and becoming part of the GDS family of registered users. REVISION HISTORY 1.00 02-10-91 The "First Release; Hope You Like It" Version --> No bugs reported yet. (I'm plugging my ears.) 1.01 02-11-91 The "Wow! that was fast!" Version --> "Sort:" menu in earlier versions could easily lock up GDS when used to sort by "Bits per pixel" or "Resolution" if GDS had not yet read file information for all files in file list. Although I haven't seen it, this bug may cause stack overflows, 386 exceptions, and all sorts of other unpredictable stuff. --> Palette generation for array images is much more accurate for images with varying numbers of bits per pixel. In prior versions, images with fewer bits per pixel were not represented equally among pictures with many bits per pixel. This problem has been eliminated by padding smaller palettes to bias the importance of their individual color ranges. --> When displaying a 2, 4, 8, or 16 color image in single view mode and the screen format used to display the image was an EGA mode, some VGA boards would handle the EGA palette and VGA color registers inconsistently. This occasionally caused a color or two to be incorrect. GDS now resets all EGA palette registers and all VGA color registers every time the palette is set, which seems to have corrected the problem. NEW! Changed behavior of mouse clicks in file list when "View:" mode is set to "Slides." Users tend to want to point at a file and add it to the list rather than deselecting all other entries in favor of the one their clicking on. So from now on, when you're doing slides, remember that the mouse toggles files! --> Fixed small moving button click problem in array setup. 1.02 02-12-91 The "QUIX RIX FIX" Version NEW! Added RIX support through the ALT-R command. Note that GDS can only support the UNCOMPRESSED RIX file formats as RIX Software is not releasing any information about their compressed file format. If you would really like to see support for compressed RIX files, don't ask me-- ask RIX Software. --> Fixed PCX file write for 16 color screen modes. In previous versions, GDS would write odd images with the bits in the bytes flipped around, and possibly the plane order reversed. This bug may be a reflection of how much time I spent writing PCX support. GDS now reads and writes PCX files correctly in all screen modes. 1.03 02-13-91 The "New and Improved Slideshow" Version --> Corrected bug in slide shows which could incorrectly display images which had been read completely into EMS before being displayed. This bug is more common when the user hits the space bar to bypass the slide show delay. Earlier versions of GDS could display slide shows with image misalignment/fracturing or even garbage in horzontal bands of images. --> Corrected bug in array generation which could crash a system. The bug occurs when the individual array images were reduced to less than 1:32 of the original image size. This limitation was not protected against in prior versions of GDS. GDS is now capable of 1:64 image reduction and limits the size of array images to prevent users from reaching this limitation. --> Corrected many bugs in ALT-Z zoom function during single image viewing. In prior versions, the zoom feature would inversely compensate for the aspect ratio of the screen. This version should handle the zoom feature as one would expect. --> Corrected nasty bug in two dimensional antialiasing when displaying zoomed areas. This bug would skew some lines in the display to the left of where they should have been drawn. The severity of the display problems depended on the level of zooming, the aspect ratio of the original image, and the position of the upper left zoom rectangle corner. NEW! Added READMAC file format to list of supported formats. Readmac files (.MAC) can be read, but not yet written. Anybody out there want to write these files? Let me know. NEW! Added color control to single and array views. The overall color level in the palette can be adjusted with the ',' and '.' keys (normal case of '<' and '>'). To reset the color level, just hit Shift-',' or Shift-'.' ('<' or '>'). This feature, along with the other image palette options gives the user a surprising amount of control over problem images. NEW! Added page display compensation when generating arrays and using ALT-F to fit an image to the display. In previous versions, high resolution portrait files would just be remapped to the entire screen. GDS now looks at the screen resolution and tries to figure out if it's a high resolution page display file. NEW! Increased EMS support for read-ahead buffering for slideshows. Slideshows now read images of any size while the current image is displayed. This facility will automatically buffer images, provided there is enough available system RAM and/or EMS to hold the images. NEW! Increased file table size to 2800 files. Yes, now you can have a slideshow which will last just under four hours (at 5 seconds between images) without repeating an image. Previous versions were limited to 2048 files. NEW! Added "label" and "border" preference buttons to array preview user interface. The "Labels:" and "Borders:" buttons may disappear from the text file display screen in future versions. NEW! Changed user interface for selecting array images. In earlier versions, it was necessary to set the "View:Arrays" and then hit "Enter" or click on the view button in order to start array generation. GDS now starts array generation immediately when the user selects "Arrays of reduced images" from the "View:" menu. There is no longer a "View:Arrays" mode in GDS. NEW! Increased image reduction by 100%. Array images may now be displayed reduced down to 0.04% in 1024x768 graphics modes. With this increase, it is now possible to display 2304 reduced images on one 1024x768 screen. I encourage anyone who has that many images accessible to one machine to try this. At 150K per image, that's over 345 megabytes of GIF files. Unfortunately, even with antialiasing off, it should take an average of at least 5 seconds per image on a 33Mhz 80386 machine, and that works out to about 3 hours and 12 minutes. I want a copy of the result! 1.04 02-14-91 The "Quick Change Act" Version ==> CORRECTED FOUR MEMORY ALLOCATION ERRORS WHICH COULD TRASH MEMORY. The bugs would happen when memory layouts made certain combinations of allocations impossible. I spotted this problem as I did a directory and got garbage for files. I'm not sure if these bugs will trash FAT tables or not, but looking at the code, the memory addresses being written to could conceivably be any segment, including DOS. --> Bug corrected with arrow keys and shift key. It should now work like the documentation says. --> Corrected bug with screen clear which would very rarely leave one dot per 64K dots in the wrong color. 1.05 02-15-91 The "Demo" Version NEW! "Almost" fully functional version so that you can try before you buy. Only some of the "high end" functions are not in this version, all the normal viewing, modifying, and reduction features are operational so that you can enjoy it for personal use at no charge. 1.06 02-23-91 The "Apocalypse Now" Version -- GIF89a NEW! Added GIF89a compatibility. GDS will now read GIF89a files, and performs all of the user interface functions with the appropriate timing. There is one primitive in GIF89a that GDS will read over but not process. This primitive is the "plain text extension" record (ID=0x01). I'd love to support this, but I don't have a file which uses it, and I don't know if anyone has even used it yet. I'd like to see someone use it before I release something buggy that claims to support it. Anybody want to send me a file? AGH! A) Added feature to allow users to comment GIF files directly. B) Put out beta copies with this feature. C) Found out that most GIF viewers choke on GIF89a files. D) Spent hours on the phone, telling people to go back to 1.06. E) Removed the feature and changed GDS back to write GIF87a. F) Took several aspirin and went to sleep. ACK! Discovered that most other GIF viewers choke on multiple palette GIF files. All GIF files written by GDS now have only a global palette, rather than global and image palettes so other viewers don't get all wound up and display the images with an RGB palette. Other viewers would see the two palettes in the GIF file and think they should correct for differing palettes (which is actually a fair assumption). Oh well, now GDS writes only one palette. VPIC, CSHOW, PICEM, and most other viewers should work fine with images generated with this and future versions of GDS. (Sorry about the glitch, guys!) ACK! Removed "Palette" menu from all versions. This menu seemed to frustrate and confuse most users, and had limited utility besides. This menu may surface in a later "GDS Professional," but for now, its value is not really perfected and its utility is difficult to understand. For all of you graphics hackers out there who understand what it does, watch for the (as yet undefined) "GDS Professional" (see the end of the file). ACK! Removed the "palette search" menu from all versions. This menu had very little actual value when it came right down to it. The actual use for this menu is valid, but the task it performs is so intricate that I couldn't figure out how to explain it to an end user. For that matter, it was difficult explaining it to other programmers... It sure looked neat, though. Oh well, it's gone, and GDS will now dynamically perform the most accurate palette search it can at any given time. 1.07 02-27-91 The "Minor Revision" Version ==> Added final touches to the now stabilized release version of GDS. --> Corrected problems with PCX files. I've received a bunch of PCX files which have some interesting problems. One of the problems was admittedly mine, and it's fixed. It had to do with monochrome PCX files with no extended palette, which GDS 1.06 and earlier would incorrectly display in all black (ahem!). A few programs, however, apparently write PCX files which have incorrect header information. GDS now tries to make an intelligent assessment of what to do with various types of PCX file headers, even with files which have obviously been written incorrectly. Some conversion programs (1) write incorrect headers and (2) fill the 48-byte palette with zeros (black), even when the image is NOT flagged as a greyscale image, AND has more than two colors, AND does not have an extended palette in the file. In this case, GDS processes the image using a standard EGA palette. I hope this addition to GDS makes more of your PCX pictures display properly, but I would also hope that other programmers obtain the Z-Soft technical specification for PCX files (readily available from Z-Soft). NEW! Added the capability to write LBM files via the Alt-L key during single viewing and array generation. GDS can now output directly to files which Deluxe Paint II will read directly, INCLUDING the 256 color formats! NEW! File list specifiable within the program. Many of you have asked for the ability to change paths from within GDS. Registered copies of GDS now allow you to not only change paths, but to really change all of your paths. Ctrl-F now allows the user to specify a completely new list of path/file specifications to create a new file list from. Handy dandy. NEW! File rename/copy/move functions are now available to registered users through the CTRL-R, CTRL-C, and CTRL-M keys. No more exiting to DOS to do image file housekeeping! Sorry, these functions work only in registered versions. NEW! File delete function is now available in *ALL* GDS versions. This function was in such heavy demand, we decided to allow unregistered users to have it. NEW! File "Hide" function now quietly hides a single file when the CTRL-H key is pressed. This function does not delete the file; it just gets removed from the screen. This is very useful when there are oddball images in an otherwise clean list of files. 1.08 03-??-91 The Beta Version in Many Forms *** This version went out to specific users in order to solve some specific problems for our users. If you have a version 1.08, you must have dealt with us directly, or gotten it from one of our "EX" beta testers! 1.09 03-27-91 The Complete GIF89a Version *!!!* GDS 1.09 is now 100% compliant with ALL of CompuServe's GIF89a specification. In previous versions, GDS skipped over "plain text extension" records (...and we told you we did). GDS 1.09 adds support for "plain text extension" records and comment records. --> Corrected even more bizarre problems with the PCX file reader. Special thanks goes to Jean Luthringer in France, who has meticulously documented many odd varieties of PCX file headers. Some of these files do not conform to the exact word of the ZSoft PCX specs, but are somewhat detectable. One of the bugs in GDS (which was a typo on my part) would display all sorts of random colors with 16 color planar images. I apologize for this screw up. I believe there are still some programs which write PCX files which are set up in such a way that choosing the correct palette is impossible. If you come across one of these files, please send it to Phase II and we'll do what we can to find a way to detect these images and display them correctly in future versions of GDS. --> Corrected problems writing 16 color LBM files. Deluxe Paint on the IBM doesn't seem to decompress IFF files when the image compression runs across bitplane line boundaries (that's O.K., because the IFF spec. says that it doesn't have to). GDS will read files compressed that way, just in case you have an IFF encoder that does. GDS should now write 16 color (bitplanar) images which Deluxe Paint reads. --> Corrected problem reading some planar odd sized BBM brushes. GDS would occationally miscalculate the image width and display severely skewed images when a brush has an odd byte width and the masking bit was set in the "ILBM" (or "PBM_") bitmap header. This bug is no more. --> Corrected bug in GIF89a image background restore for areas larger than would fit in available system RAM. GDS writes excess screen data to a temporary file when it has to restore the data later, but a typo prevented GDS from being able to read the file data back in. Also, when a GIF89a image had a "restore to original" graphics control block in it and the image was enlarged greatly with the ALT-Z (zoom) feature, GDS would store tons of nonexistant screen data to this temporary file. Ironically, the typo made this data storage even more useless because it could not be read back in. Users who have a lot of free disk space may not have noticed anything except very long delays when this happened. These two problems have been fixed. GDS now clips restored areas to the visible screen to minimize the size of temporary files and memory consumption. These problems were annoying, but NOT harmful. --> Corrected bug in MAC file reader which would hang when displaying certain images which contained a specific compression scenario. This bug surfaced with a file called "BROOKE.MAC" which we received from a devout user. Thank you. The bug has been eliminated. --> Corrected bugs in Genoa bank switching routine which limited memory to 256KB, or four banks. Also, modified GDS.CFG to include only valid modes for current end-user Genoa cards. Some of the modes listed in GDS.CFG were supported only on Genoa 5000 cards. These modes can be re-invoked by removing the semicolon (";") at the beginning of each line in the configuration file. Special thanks goes to Herman Wadler of Genoa Systems Corporation for his quick response to my numerous inquiries. Also, at least one of Genoa's BIOS releases (3.5) has a problem with 640x400x256 mode when using an analog monitor. Genoa is aware of this problem and is working on (or has completed) a new BIOS to correct this problem. Call Genoa technical support at (408)432-9123 to get an update if you have experienced problems with the 640x400x256 mode. --> Special thanks goes to Joe Brabec in Livermore, California, just because he's a fantastic hardware designer. Will someone please hire him away from his current job? He deserves better! --> Added some logic to the mouse button up/down portion of GDS which should help those of you who have a video BIOS which plays around with interrupt enable flag and/or mouse driver during a mode change. If you have ever seen GDS return to the text screen immediately after you double click on a file, this change should prevent that from happening. --> Corrected bug with GIF files which have a Macintosh file header at the beginning. GDS was always set up to automatically detect and skip Mac headers, but somewhere along the way I disabled that code. Oops. --> Corrected bug in automatic (unattended) array generation and file writing which would write GIF files (rather than PCX or LBM) after the first image. GDS now continues to write the same format of file which the user specifies for the first array write. --> Corrected bug which would force GDS to think that the installed video card had 512K of video memory available, even when it was known that the video card had only 256K. Double Oops! NEW! Added support for GIF89a "plain text extensions." Thanks to Jim Burton (a very good artist sometimes found lurking around the CompuServe PICS forum and also responsible for many very praise-worthy GIFs), I've obtained CNTAUR.GIF, which includes several "plain text extension" records. Thanks, --> JB! NEW! Added the GIF89a comment records. GDS automatically formats and displays comment records after viewing GIF89a images. Naturally, this automatic comment viewing behavior can be diabled by using the "/K0" command line parameter. NEW! Added a short "beep" at the end of viewing an image. Many users want a beep after the display of an image because the file viewer they used to use did it. GDS now lets you know that it's done with a friendly beep. Some users will probably find the beep annoying ("BEEP!!"), and are free to kill it completely by using the "/!0" command line parameter. NEW! Added PCC format. Some users have asked to have PCC files listed along with PCX files. I left this out initially because the extension is considered obsolete in most circles, but alas, having this extension supported can't hurt. Enjoy. NEW! Added status message when writing files. Now you don't have to guess what GDS is doing after you hit an ALT key to write an image. NEW! Disabled writing images until the display cycle of each image is complete. We decided that it is in everyone's best interests to protect the rights of the authors of quality GIF images against users who write GIF89a images before the image is complete. Now disabled, this capability had little use except to conceal copyright messages in GIF files. NEW! Direct hardware support for setting palettes. In order to avoid "snow," certain display adapter BIOSs wait for a vertical retrace period before setting the palette registers. The flaw in this strategy is that programs like GDS set sections of the palette iteratively, and must wait for the video BIOS. Cards which are known to do this are the Orchid Pro Designer II, Hercules Graphics Station 34010, and TVGA (there are many others). GDS now defaults to going direct to the hardware DAC registers in order to set up the palette. IF COLORS IN IMAGES SEEM TO BE WRONG, OR SEVERELY DARKER THAN NORMAL, try using the "/C0" command line option (see "Common Problems" section). This option tells GDS to go ahead and use the video adapter's ROM BIOS to set the palette. NEW! Added command line option ("/R") which sets the default mode of the "LOck/AutO" button when GDS is first executed. This is useful if GDS.CFG is modified such that the first resolution is the one that is to be locked. NEW! Added command line option ("/E") which tells GDS to try to fit images to the screen in single view and slideshow mode. This is convenient when giving slideshows of large images on standard VGA's which support only the lower resolutions. NEW! Added the version number to the GDS exit message. Now you can tell which version you have if GDS doesn't work on your machine! AGH! ==================================== FUTURE WATCH ==================================== GDS Professional ---------------- What do you want? How much should it cost? ---------------- Do you want: More file formats? Which? Batch language for multiple processes? Palette locking/translation? Image content palette searches? Extremely high quality photomontages? Shells to DOS and/or paint programs? Scanner support? 15/16/24 bit for Targa and others? There is a big question as to when and how a "high end" version could happen. I have tools to create piles of useful stuff, including 24 bit scanner support and a plethora of esoteric image processing functions. Targa file support is in the wings, but I'm not satisfied with it yet. As it stands, it still won't display one of my files. ...it's a 3674x1588x24 scan that's over seventeen megabytes long. PLEASE LET US KNOW! Phase II Electronics Inc. 19 Sands Point Drive Toms River New Jersey 08755-5167 Phone (908) 286-0080, Fax (908) 349-3842 Compuserve 76667,1522 Bob Holland