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