Hall of Fame/HallofFameCDROM.cdr/gamegif/gds109.lzh/GDSINFO.DOC

Text File | 1991-04-08 | 26KB | 500 lines

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 [phone] 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 [phone],  Fax [phone]
               Compuserve 76667,1522  Bob Holland