home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
World of Graphics
/
WOGRAPH.BIN
/
243.GDRAW97B.ZIP
/
GHISTORY.TXT
< prev
next >
Wrap
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