World of Graphics/WOGRAPH.BIN/243.GDRAW97B.ZIP/GHISTORY.TXT

Text File | 1992-07-10 | 11KB | 227 lines

            GDRAW AND GBBS
            ______________


          In early 1990 I and several friends began to wonder
     why Bulletin Board Systems did not support graphics.  Now I
     know what your about to say, yes there are graphics on
     bulletin boards, ANSI is very common, and in addition there
     have been several packages that allow for the viewing of
     graphic images on-line, but what I was dreaming of was a
     graphics BBS that would allow users to gain full use of the
     graphics hardware they had spent so much money to acquire,
     and allow users to create graphics and interact within a
     graphics environment over phone lines.  If that wasn't
     enough I also dreamed of users using their keyboard or
     MOUSE to interact on a graphics screen using ICONS.  Why
     stop there?; How about Joy Stick support and the capability
     for SOUND support like Soundblaster and Adlib.  Background
     file transfer capability would also be desirable, and of
     course the whole system would have to use packetized
     transmission to assure that errors never reached the other
     side.

          So I began to experiment.  Luckily I own a small
     software engineering firm {emphasis on SMALL} and I have
     extensive design background in high speed communications
     and HOST to TERMINAL communications.  As I began to test
     some of my ideas one thing began to become evident; None of
     the graphics formats in the world would do the trick they
     were all very wasteful, and secondly this project was going
     to take an immense amount of time and effort to have any
     chance at success.

          As I began the initial system design for a Fully
     Graphic BBS I kept in mind several system rules that I
     promised to adhere as closely as possible:

          1. The System should support AT computers and above
     with any sort of graphic card and monitor combination.  (In
     reality most XT systems are also supported but we make no
     claims for the future, sorry XT technology but the old must
     die sometime).

          2. Graphics for this system must be able to use the
     full capabilities of any graphics standard.  This would
     mean running the gambit of video modes from CGA to VGA.
     {SuperVGA would be nice but until a STANDARD really
     develops the complexity and size of code needed to support
     these modes is prohibitive.}

          3. Users of this BBS should be able to View Graphics,
     play games, or view drawings, and MAKE GRAPHICS so that
     they may fully participate in this new environment.

          4. The system should be usable by anyone who has a
     2400 baud modem or faster.  With a 2400 baud modem the user
     should be able to reach the complete features of the BBS,
     viewing graphics, animations, Background file transfers,
     etc.

          5. The system should use bi-direction full duplex
     packetized transmission methods so that no errors could
     migrate between the BBS and the terminal.  Not just during
     file transfers, always.

          6. Background file transfer in both directions while
     using the BBS should be possible.

          It was obvious to me that a very powerful graphics
     engine would be necessary to display these images, and a
     graphics drawing tool that was friendly enough for the
     average user to take advantage of.  Current Terminal
     software has no knowledge of packetized communications
     {excepting file transfer protocols} or graphics output so
     normal terminal software would not work.  The BBS software
     would have to be written from the ground up to take
     advantages of this improved terminal capabilities.

          Most everyone I talked to about the idea thought I was
     a nut.  First of All they said, you can't send that much
     data down a 2400 baud modem and expect it to be anything
     but slow.  I said yes with current technology that seems to
     be impossible but what if we changed the way drawing
     packages stored the data.  We could develops a graphic tool
     that produced files that were small enough to provide
     on line animations using only 140 bytes per second.  In VGA
     I added.  They called for the rubber Truck.

          When I stepped into my basement I intended to provide
     a dirty simple tool that would stumble through these
     operations with one intent only.  To supply graphics for
     this new BBS system.  Now that a pre release version .97 is
     available for the public to play with they don't think that
     I am quit as crazy as they originally believed.  That's
     because even before the official release of our BBS
     software, [due in the next few months, no I can get no more
     specific at this time, sorry] GDRAW is being used for
     applications that I never dreamed of; Animations on Disk,
     business presentations, advertising for BBS's {which they
     include with their downloads}, or just the fun of being
     able to do animation without owning a GIGABYTE size
     hard drive or special hardware.  And since people are using
     the product maybe a little bit of background about how it
     works is in order.

            GDRAW A PRIMER

          GDRAW is a Vectored Graphics/Bit Map Graphics hybrid
     drawing tool.

          You have used a bitmap graphic tool if you have used
     DPAINT, PCPAINT, PC PAINT BRUSH or the like.

          You have used a Vectored Graphics tool if you have
     used a CAD package or any sort of object oriented drawing
     package.

          GDRAW is a combination of both of these. GDRAW files
     are incredibly small.

          Since for my original design goals file size was the
     most important criteria let's cover that point first.

          GDRAW stores how to reproduce the picture you have
     drawn as opposed to the drawing itself.  GDRAW remembers
     every control action that you perform and stores the
     command in memory.  A drawing is merely the combined total
     of all you commands you have done executed one after
     another.  Since Animation is a continuing sequence of
     drawing GDRAW is capable of animation.  File size in GDRAW
     images is in direct proportion to image complexity.  If the
     image you are drawing is very simple the file is very
     small, a more complex image takes more data and thus the
     file is bigger.  Compare this with a bitmap mode where
     every pixel on the screen is stored. [Granted encoding
     formats dramatically decrease the amount of disk space for
     bitmap graphics, but GDRAW is still vastly more efficient
     at producing small file sizes for all but the most complex
     images, ie.  digitized image data].

          GDRAW is a graphic interpreter for the GFX graphic's
     language.  I developed this graphics language because this
     would allow a compiler to act upon the source code that
     GDRAW produces yielding and even smaller run time file. The
     compiler takes GDRAW files as input a produces a GRELLED
     file as output.  The file size of a GRELLED image can be up
     to 80% smaller than the GDRAW input file!

          Every time you paint you are creating a string of GFX
     graphics commands that are remembered by GDRAW.  When you
     ask GDRAW to refresh the drawing it loops thru each command
     you have stored and performs the action that command
     dictates.  GDRAW allows you to interact with this language
     as an artist with out having to know or even look at these
     commands.

          Once a GDRAW image is saved it may be viewed with our
     free ware product GPLAY.  This player will play anything
     from a simple picture to an hours long animation.  It will
     run on any machine with at least 512k memory and the proper
     graphics hardware for the screen mode that the imagery was
     produced in.  GPLAY is FREELY DISTRIBUTABLE for any reason
     to anyone, commercial applications also {as long as the
     person is not charged for gplay, small costs due to
     transmission by phone or media is OK}.  But I do reserve
     the copyright.

          GPLAY can view uncompiled GFX (GDRAW format) or
     compiled format (Grelled) files.  Grelled files have two
     distinct advantages over GDRAW files.  They are
     significantly smaller, and THEY CAN NOT BE EDITED.  Thus if
     you were going to upload a graphic to a BBS for others to
     download if it is GRELLED then it will transfer faster and
     no one can take portions of you work and steal it.

          I am unaware if any other package protects an artists
     work, but it is something that has been needed for many
     years.

          Bulletin Boards enjoy GREL's small file size because
     their board advertisements can be flashy and still be small
     enough to be included in downloads.



            WHERE IS GDRAW GOING
            --------------------

          Our initial goal of a graphic BBS is healthy and on
     it's way as of this writing we have just about finished our
     packet based protocol called "OCTOPUS".  The upper level
     code for the BBS is well on it's way to completion, and
     GDRAW is almost ready to take on it's role as the graphics
     tool for this new technology.  The .97 version is still not
     what we dreamed of as our initial release but the need for
     people input is important, and pressure from friends has
     prompted us to make this PRE RELEASE AVAILABLE for
     pre registration.

          This product has over 50 new features planed in the
     future and we have only begun to streamline this
     technology.  Although we are unsure of release dates for a
     windows version the initial work is being carried out.

          The time for this project has been IMMENSE and it would
     be impossible to thank all the people who have helped make
     this project a reality but many sincere thanks to Clark
     Mathews for debuging endless versions {and many more to
     come}, and the support work necessary to coordinate the
     many, many, beta testers used throughout the development.
     All the Beta Testers who helped and were frustrated by bugs
     and strange methods unfamiliar to them and all the people
     who have shown their support of this project by registering
     GDRAW while still in PRE RELEASE {some even before having
     the code written}.

          This is a new technology that will take us into the
     21st century for BBS communications.  Giving us the dreams
     we see in our minds.  Please show your support by
     registering this product, as always my faith in the human
     race is undying, let no one disappoint me.

          Much happiness and good GDRAWING


          Chris Wright President Wright Engineering