Gold Fish 1

home *** CD-ROM | disk | FTP | other *** search

/ Gold Fish 1 / GoldFishApril1994_CD2.img / d4xx / d433 / gwin / gwin.doc < prev next >

Wrap

Text File | 1991-01-12 | 79KB | 2,045 lines

15 July 1990 GWIN by Howard C. Anderson GWIN GRAPHICS SYSTEM - Version 1.1 Update for MANX AZTEC C Compiler (Version 5.0b) Author: Howard C. Anderson 1895 E. Auburn Dr. Tempe, Az 85283 (602) 897-7425 GWIN V1.1 (c) Copyright 1989 Howard C. Anderson All rights reserved. Software may be distributed for non-profit only. This software is NOT shareware, i.e., don't send me money. The Amiga is a great computer but don't you think the graphics interface involves a lot of drudgery? I mean it takes almost a hundred lines of code to set up enough trash and trivia to draw one straight line segment. (Refer to "Inside the Amiga" by John Thomas Berry - the example in the "Using Intuition" chapter, "The Creation of a Window in a Custom Screen".) If you encapsulate the low-level routines, you can simplify the interface and still provide access to most of the low-level features. In addition, you can eliminate the possibility of GURUs. The trade-off of course is ease-of-use, virtual windowing, automatic clipping, greatly simplified mouse and keyboard interaction, freedom from GURUs, automatic menu generation, speed of application development, etc. versus speed of execution. If your application needs extra speed though, you can still call the Amiga low-level routines while in GWIN. You at least save yourself a lot of setup time because you can get any of five types of Amiga screens and a window up by using just ONE PROCEDURE CALL. Who needs GWIN? I do. I am a mathematician who's been a software engineer for quite some time. The first machine I worked on was the Philco 2000. It was one of the largest and most powerful machines in existence at the time (It had 1/5 the memory of the Amiga 2000 here on my desk and was probably slightly faster than the Amiga for floating point calculations.) Graphics on the Philco 2000 consisted exclusively of assembly language programs to produce plots on printers. At two runs per day maximum for compiling - and debugging provided for via 200 page core dumps it was all drudgery and I loved it. I loved it less as time went on but there is great mystique, glamour, and prestige associated with writing programs that no one else can understand or debug. Is it the desire for such past glories that accounts for the sorts of interfaces we have these days??? Perhaps there is not enough time to neatly package things??? Perhaps the only possible flexible software interfaces are of necessity mind-warpers??? Maybe everyone but me has time to muck around endlessly wondering from whence the next GURU or screen shattering misunderstanding will arise??? I agree that you lose flexibility when you go up one level but you do gain development efficiency. The applications I have in mind are scientific applications such as interactive graphing and mapping. Several years ago, I used a system called the Graphics Compatibility System (GCS) that was developed by the government. That system was not particularly fast but it certainly made development of scientific graphics applications MUCH easier and faster. The source code of GCS -1- 15 July 1990 GWIN by Howard C. Anderson (in FORTRAN) is available through the National Technical Information Center. It is a very large system. Trying to compile it and run it on an Amiga would probably allow you to relive some of the past glories mentioned above. Instead, I designed a system with capabilities similar to GCS but with additional Amiga-specific features and wrote this simple graphics system in the C language. The result is a graphics system that I refer to as GWIN (Graphic WINdow). GWIN includes many of the virtual windowing features that were part of the GCS philosophy and also includes and simplifies use of many of the strictly Amiga features such as menus and requesters. The underlying architecture of GWIN has much in common with most high-level two-dimensional graphics systems. "Fundamentals of Interactive Graphics Computer Graphics", the classic text by Foley and Van Dam, describes well the sort of mathematical transformations, clipping algorithms, etc. that are part of the GWIN system. Over the years there have been many higher level graphics systems: PLOT10, GCS, GKS, CORE, etc. Most of them presumably have been too massive to adapt for use on the Amiga system. I am unaware of any high-level graphics system that provides the range of features on the Amiga system that is provided by GWIN. The goal of GWIN is to allow a person to write interactive scientific graphics applications programs in C without having to master all the complexities of the Amiga graphics system. Here is a program that draws one straight line segment in a high resolution interlaced window using GWIN and then waits for the user to press the left mouse button before exiting: main() { float x,y; ustart("high2",0.,100.,0.,100.); umove(20.,20.); udraw(50.,50.); ugrin(&x,&y); uend(); } Ahhhh... Isn't that better??? Other examples are provided in the GWIN EXAMPLES directory. -2- 15 July 1990 GWIN by Howard C. Anderson GWIN THEORY OF OPERATION FLOATING POINT GWIN is intrinsically floating point. Most of the parameters passed to and from GWIN routines MUST BE FLOATING POINT. There are exceptions however so I have provided the type of each parameter with the description of the calling sequence of each routine. COORDINATE SYSTEM Normal mathematical xy coordinate system is assumed with larger x values to the right of the screen and larger y values at the top of the screen. (The machine manufacturers tend to put the small y values at the top of the screen because that is where the raster scan starts. This is an unfortunate accident of the history of television. If they had started the raster at the bottom of the screen and gone up instead of vice-versa it would have been much nicer. (Surely you don't REALLY want to work in quadrant IV - with NEGATED Y values???) GWIN corrects for this historical, perpetuated, accident. STARTUP Graphics operations are begun with a USTART procedure call. USTART will allow you to open any size window you choose on a screen whose type you may choose. Screen types are: low1 - 320x200 pixel, low resolution, non-interlaced, 32 colors. low2 - 320x400 pixel, low resolution, interlaced, 16 colors. high1 - 640x200 pixel, high resolution, non-interlaced, 32 colors. high2 - 640x400 pixel, high resolution, interlaced, 16 colors. ham - 320x200 pixel, hold and modify, [4096 colors]. low1.backdrop - Same as low1 but active region fills screen. low2.backdrop - Same as low2 but active region fills screen. high1.backdrop - Same as high1 but active region fills screen. high2.backdrop - Same as high2 but active region fills screen. ham.backdrop - Same as ham but active region fills screen. ACTIVE REGION When you open a screen and window with USTART, the active region of the Amiga window is everything inside the borders. This full area is always thought of as running from 0.0 to 100.0 in both the x and y directions. You may use UDAREA to select some subset of this area as the active region. UDAREA calls are always relative to the original 0.0 to 100.0 bounds. Drawing is always restricted to the active region by internal -3- 15 July 1990 GWIN by Howard C. Anderson clipping routines unless you have turned internal clipping off using uset("ncli"). (See "Fundamentals of Interactive Computer Graphics", Foley and Van Dam, section on "Viewports" if you need further information.) VIRTUAL WINDOWING Virtual windowing is automatic. The UWINDO command allows you to change the size of the virtual window. The default virtual window is from 0.0 to 100.0 in the x direction and 0.0 to 100.0 in the y direction. Whatever is in the virtual window is expanded or contracted as necessary and mapped onto the active region determined with UDAREA. By changing UWINDO and redrawing, you can pan and zoom. (Clearly, we are not talking real-time pan and zoom here of course.) (See "Fundamentals of Interactive Computer Graphics", Foley and Van Dam, section on "Windows and Clipping" if you need further information.) ROTATION OF COORDINATES The coordinate system may be rotated through an angle theta (value 0.0 through 360.0) relative to any point in the virtual coordinate space through use of the UROTATE call. The point about which the coordinate space is rotated is ALWAYS with respect to the ORIGINAL UNROTATED COORDINATE SYSTEM. This point becomes the new origin, (0,0), of the new rotated coordinate system. There is no way provided to rotate Amiga text. The position at which the text is to appear will be rotated and the text will begin at the new position but it will still be horizontal like this line you are now reading. DRAWING UMOVE, UDRAW, UCRCLE, URECT, and UPLYGN are the primary line and polygon drawing tools. UMOVE moves the beam to the specified virtual point. UDRAW draws a line from the current virtual beam position to the virtual beam position given in the UDRAW call. Clipping is performed as necessary. URECT draws a rectangle and has some speed advantages over UPLYGN. UPLYGN draws a polygon of the specified number of sides within a circumscribing circle of radius provided in the call. The optional "fill" switch set via a USET call cause polygons or rectangles to be filled when drawn and causes UMOVE, UDRAW, UDRAW, UDRAW,... UMOVE sequences to be filled. Setting "nofi" with a USET call turns off the filling operation and closes and fills immediately any UDRAW sequence that has not yet been closed by a UMOVE call. TEXT UFONT establishes the font that will be used for subsequent UPRINT and -4- 15 July 1990 GWIN by Howard C. Anderson UPRNT1 calls. Any font that you have on your system may be used. The default is the standard Amiga default font which at the moment is Topaz. Its default size is selected by you with the Preferences tool. UPRINT will print a line of text at the given location in accordance with the USET options "inte", "real", and "text". UPRNT1 prints a line of text at the current beam location and allows you to set "inte", "real", and "text" for the duration of the call. COLOR The current drawing color is established by a UPSET("colo",color) call where color is a real number between 0 and the maximum color for the particular screen type you are using. (GWIN does a modulus operation if you forget and exceed the maximum color.) The "colo" option to UPSET sets the A pen and the O pen so that lines, fills, and outlines are all set to the designated color. The "bcol" option to UPSET sets the B pen so that the background color for text may be set as desired. The "ccol" option to UPSET sets the color that will fill the screen when the UERASE screen clearing call is issued. CLIPPING Line and polygon clipping are automatic. These are sometimes suppressed if the item being drawn such as a polygon or rectangle is seen to fall completely inside the virtual boundaries. You may suppress clipping for speed IF YOU ARE ABSOLUTELY CERTAIN THAT NONE OF THE THINGS YOU DRAW WILL FALL OUTSIDE OF THE CURRENT VIRTUAL WINDOW. If you blow it, ANYTHING can happen - loss of screen synch, GURUs, etc. Clipping is disabled by the "ncli" option of USET. Clipping is reenabled by the "clip" option of USET. RECTANGLE INTERIOR ONLY FILL If you have a rectangle whose color you wish to change but you do not wish to change the color of the bounding box, use USET("rint"). Use USET("rext") to include the exterior bounding box if you wish. GRAPHICS INPUT UGRIN, UGRINC, UGRINL, UGRINA, and UIGRINA are provided. Each of these responds to the window close gadget by calling UEND and exiting IMMEDIATELY. (Unless the USET option "nclo" is set for UGRINC and UGRINL in which case the CLOSEWINDOW event is returned to you.) UGRIN (GRaphic INput) returns the x and y location of the cursor when the left mouse button is pressed. UGRINC (GRaphic INput Character) returns the x and y location of the -5- 15 July 1990 GWIN by Howard C. Anderson cursor, the event type, and the keyboard character that was pressed if the event type was "VANILLAKEY". Event types may be one of MOUSEBUTTONS, VANILLAKEY, CLOSEWINDOW (only if you have called uset("nclo")), or REFRESHWINDOW. If the event type was "MOUSEBUTTONS", the key returned is an "a" if it was a left mouse key "down" event code and an "A" if it was a left mouse key "up" event code. MOUSEMOVE events are NOT monitored by UGRINC. UGRINL (GRaphic INput Locator) returns the x and y location of the cursor, the event type, and the keyboard character that was pressed if the event type was "VANILLAKEY". If the event type was "MOUSEBUTTONS", the key returned is an "a" if it was a mouse key "down" event code and an "A" if it was a mouse key "up" event code. MOUSEMOVE events ARE monitored by UGRINL and you are notified immediately of the last one in the current message stack. UGRINA (GRaphic INput All) is identical with UGRINL except it returns even if no event occurred. This allows you to continuously monitor user activity while in a processing loop. You can use this to allow the user to interrupt a process if he desires (maybe he wants to change his mind regarding the 30 hour Mandelbrot drawing...) UIGRINA (Integer GRaphic INput All) is identical with UGRINA except that it returns integer mouse coordinates with no coordinate transformations performed. This allows greatest speed since it bypasses all floating point operations. If you need speed, use UIGRINA. Coordinates returned are normal Amiga coordinates with the origin at the top left corner of the screen. (For a high-resolution screen, 640x400 pixels, the x coordinate will be an integer from 0 to 639 and the y coordinate will be an integer from 0 to 399.) EASY AMIGA MENUS With a one line call (UAMENU), you can set up each menu item of a hierarchical menu structure. GWIN creates all necessary structures, allocates all necessary space. You pass a "function pointer" that tells which of your functions will be called when the user selects that menu item. EASY AMIGA YES/NO REQUESTER With a one line call (UYORN), you can put up an AMIGA boolean requester containing your text. When the user makes his choice, you will receive a TRUE/FALSE return code. EASY AMIGA STRING REQUESTER With a one line call (UGETSTRING), you can put up an amiga string requester containing your prompt text. The requester will wait for the user to enter a text string. The requester exits when a carriage return is received. -6- 15 July 1990 GWIN by Howard C. Anderson SCREEN DUMP TO PRINTER If you have an Epson LQ series printer, you can dump the screen image to the printer using UPRSCR. ABORT GWIN has its own abort handler so that GWIN can be aborted if desired. The abort is graceful, i.e., all memory areas are deallocated, all libraries released, etc. If you have your own cleanup handler (via USETCLEANUP) it will receive control after GWIN completes its cleanup after an abort condition occurs. Note: The above is true for MANX compiler. I've accomplished this by overlaying the _abort() function described on page lib68.ap.1 of the version 3.6 Manx compiler manual. Within the Lattice environment, Glen Fullmer (my good friend and associate who compiled the LATTICE versions using his LATTICE compiler) used the SIGNAL function to attempt to catch the "SIGINT" signal. Neither of us is impressed with either compiler's abilities in this area. USER CLEANUP HANDLER The routine USETCLEANUP allows you to pass a function pointer to GWIN that points to your own cleanup routine. When GWIN exits, for whatever reason, if you specified a cleanup routine, control will be passed to your cleanup routine after GWIN completes deallocation of its memory allocations, release of its libraries, etc. In your cleanup routine, you may then release any storage you may have allocated, close any files, etc. -7- 15 July 1990 GWIN by Howard C. Anderson EXAMPLES Examples of the use of GWIN routines are located in the gwin/examples directory. Execute these examples and study their source code to see how to use GWIN calls. The examples and a brief description of each are as follows: clipdemo Demonstrates setup of a GWIN clipping window within an Amiga window. (Object code was deleted to make this all fit on one disk. You must recompile before running this program.) colormap2 Demonstrates changing the colormap. Place cursor inside a triangle, depress left mouse button and move cursor around. The points of the triangles correspond to Red, Green and Blue. Distance from the center determines how much Red, Green or Blue. placeobject Demonstrates moving and placing a rectangle of various colors. rubberbandline Demonstrates a rubberband line. Simple demo intended only to illustrate how a rubberband line is generated. (Object code was deleted to make this all fit on one disk. You must recompile before running this program.) text Demonstrates use of font selection and various text display options. (Object code was deleted to make this all fit on one disk. You must recompile before running this program.) graph Accepts a list of numbers either from the keyboard or from standard input. The numbers are assumed to be Y coordinates. Integer X coordinates are automatically assigned. A graph is drawn. Menu options allow switching between line graph and bar graph modes. If you place a list of numbers in a file (say file1) then issue the command "graph <file1", the numbers will be graphed. -8- 15 July 1990 GWIN by Howard C. Anderson request Shows how to use a requester to ask the user a yes/no question. screentypes Demonstrates all 10 types of screens supported by GWIN. (Object code was deleted to make this all fit on one disk. You must recompile before running this program.) three-d Allows construction of three-dimensional figures. You would need red/blue glasses to see the three-dimensional effect however. (Object code was deleted to make this all fit on one disk. You must recompile before running this program.) menu Demonstrates how to build and use menus in GWIN. rubberbandbox Demonstrates building boxes using a rubberband box. spiceplot For you Electrical Engineers who have access to some version of the "SPICE" program. Spiceplot reads a SPICE output file from standard input, i.e., type: "spiceplot <spiceoutput" to see it plot curves contained in the spiceoutput file. Note the format of the data in the spiceoutput file. Spiceplot is looking for the lists of node data. Depress the left mouse button and hold, drag, and release. A rubberband box will have appeared and the selected region will be expanded to fill the screen. Use the menu to restore the curves to their original scale. As the cursor moves, the coordinates are displayed. geomap A geographic mapping system. Geomap asks for latitude and longitude coordinates of where you wish the center of the -9- 15 July 1990 GWIN by Howard C. Anderson map to be. I used some simple coordinate transformations that allow a lot of power without a lot of work. Note that the cursor reads latitude and longitude as it is moved. Note menu options. We have orthographic and Mercator projections available with oblique Mercator projections thrown in for free. Note that the cursor also provides accurate latitude and longitude data when an oblique projection is displayed. I have untransformed (back to latitude and longitude values) one of the map databases contained in the "WorldDataBank" directory on Fish disk 262 for use with geomap. Mike Groshart and Bob Dufford are the authors of WorldDataBank and are members of the Amiga Users of the Heartland in Omaha Nebraska. The "ortho2" menu option simply draws the back side of the globe in blue and the front side in red. "Ortho" only draws the front side. The "cspec" menu option illustrates cylindrical projection. (Object code was deleted to make this all fit on one disk. You must recompile before running this program.) speedy Demonstrates how Amiga calls can be used within a screen and window initiated by GWIN. GWIN saved all of the effort of bringing up a special screen and window while allowing full use of all standard Amiga graphics functions. Speedy makes use of direct Amiga graphics function calls to provide the fastest possible graphics operations. This means that for special purposes, it is possible to bypass the floating point world/screen coordinate transformations that are a part of normal GWIN operation. The function uigrina is provided to allow transformationless return of x and y cursor coordinates for greatest possible speed. The slowest thing in "speedy" is perhaps the call to the random number generator, "ran". -10- 15 July 1990 GWIN by Howard C. Anderson USING GWIN I am using the MANX C compiler. When I began this project I foolishly assumed that compilers on the Amiga produced compatible object modules as is done on Sun, Apollo, Multics, IBM, etc., computer systems so that they could be linked together with object modules produced by other compilers. Alas, Amiga does not have a standard linker so Lattice and Manx each apparently wrote their own and defined their own standards so Lattice C object modules cannot be linked with MANX C object modules. I also did not expect the compiled objects to become obsolete so quickly. You cannot link MANX release 5.0 produced object files with MANX release 3.6 object files. The reason for this re-release of GIN is to provide release 5.0 compatible graphics object files that you may use to create GWIN applications under the release 5.0 version of the MANX AZTEC C compiler. I am still considering organizing GWIN as an "Amiga library". I am very happy with release 5.0 of the MANX AZTEC C compiler. They have provided tools to greatly simplify the creation of "Amiga libraries". If I can find time, I will attempt to make GWIN an "Amiga library". This is really the way to go. I still have concerns regarding areas such as transmitting error messages from within an Amiga library to the user. For example if someone blows the USTART or UDAREA parameters, how does one notify the developer from within the library? (If you said GURU, you still don't understand what I've been trying to say about making things easier for the developer... Please read the previous paragraphs again.) I haven't had time yet to test what does and does not work. LATTICE NOTES I have a MANX compiler. I don't have a Lattice compiler. Glen Fullmer, my good friend and associate, does have a Lattice compiler (release 5) and graciously offered to create Lattice-compatible GWIN object modules. I am not a Lattice guru so what we'll do for you Lattice users is list the names of the Lattice-compatible GWIN object modules here, show a tiny bit of makefile data here and tell you that everything works in a manner similar to the way the Manx versions are used. The Lattice-compatible GWIN object modules are: gwinl.ff.o gwinl.ffCD.o gwinl.fiCD.o The ff, ffCD, and fiCD labels have the same meaning as given below in the descriptions of the corresponding MANX-compatible versions of GWIN. Glen says he believes gwinl.fiCD.o can be used in place of gwinl.ffCD.o. The makefile entry used to compile the GWIN object module gwinl.ff.o looked like this: -11- 15 July 1990 GWIN by Howard C. Anderson gwinl.ff.o: gwin.v1.c gwin.h lc -ff -cw -ogwinl.ff.o gwin.v1.c The makefile used to link gwinl.ff.o with the example placeobject.c looked like this: CFLAGS = -ff -O LIBTYPE = ffp COMPILETYPE = f placeobject: placeobject.o gwinl.f$(COMPILETYPE).o blink lib:c.o placeobject.o gwinl.f$(COMPILETYPE).o lib lib:lcm$(LIBTYPE).lib lib:lc.lib lib:amiga.lib placeobject.o: placeobject.c lc $(CFLAGS) placeobject.c NOTE: The "blink" line above has been folded to fit on this page. it and the next three lines should all be on one line. Now just one more thing... I have not been having a good time figuring out what sort of "wierding way" was used by the Amiga designers to handle font loading. Nothing seems to be exactly right. Rather than put Glen through another painful compilation process, I have made a small change to the MANX version that is not currently reflected in the Lattice version. The MANX version always reads the font from the disk. This is slower but always gets exactly what you ask for with respect to size and style. The Lattice version tries to read the font from the system first then from the disk if the system read failed. The read from the system often is satisfied if the resultant font is "close" to what you want. Reading from disk is slower and each time a font is read from disk, memory appears to disappear. This memory does not reappear after termination of the program. A note from someone on USENET indicated that this memory is not really "gone" however and will be recovered as soon as some memory allocation request asks for more than appears to be left. I have tried this and they are right. Its REALLY goofy. I've tried "AvailFonts" - It doesn't seem to update the "system font list". I've tried a lot of things but a lot of "smart" interaction is built into the Amiga font loading processes apparently. Perhaps a little too smart. Hopefully I will figure this out eventually and provide an updated version some time in the future. Thats it regarding Lattice. Now back to MANX. MANX NOTES To use the GWIN library, you must write a C program that calls procedures in the GWIN library, compile it with the Manx compiler and link the object module with the GWIN object module. (The makefile in the gwin/examples directory shows many examples of compiling and -12- 15 July 1990 GWIN by Howard C. Anderson linking with GWIN.) Fortunately or unfortunately depending on the degree to which you appreciate simplification, there are four floating point formats allowed by the Manx compiler, the "Motorola Fast Floating Point" format, the "Amiga IEEE Double Precision Floating Point Emulation" format, the Manx IEEE floating point functions, and the "68881 Floating Point" format. In addition, there are "large code / small code" and "large data / small data" compiler options. We could have compiled 12 versions but we didn't. We chose to make three versions of the object code, a fast floating point, small code / small data version, a fast floating point large code / large data version and an IEEE large code / large data version. The compiler options for these are, respectively, "-ff", "-ff -mc md", and "-fm -mc -md". A version of GWIN has therefore been compiled for each of these formats so you may link the one that is compatible with your mainline program and the capabilities of your machine. The three versions of GWIN are "gwin.ff.o", "gwin.ffCD.o", and "gwin.fiCD.o". For the greatest speed, you should use "gwin.ff.o" unless the size of your data or code requires use of the slower "gwin.ffCD.o" version. Version "gwin.fiCD.o" should be used if you need high precision arithmetic. Remember that YOUR object segments must be compiled so as to be compatible with the version you select. There is also a potential problem with the default size of integers. The three versions of GWIN were compiled with the MANX C compiler default which in release 5 default to long integers. That means that the GWIN routines expect to link up with the "lm" and "lc" libraries. So that you will not be in the dark, the GWIN object segments were compiled with these statements: cc -ff -o gwin.ff.o gwin.v2.c cc -ff -mc -md -o gwin.ffCD.o gwin.v2.c cc -fm -mc -md -o gwin.fiCD.o gwin.v2.c Assume you have a program named "prog.c" that calls GWIN routines such as "ustart", "umove", etc. Then to compile and link it, you would execute the statements: cc -ff prog.c This will result in an object segment called "prog.o". To link GWIN in with your object segment, issue the link command: ln prog.o gwin.ff.o -lmf -lc This will result in the executable graphics module "prog". Similarly, to use the fast floating point format large code and large data version, you would compile your program with: cc -fm -mc -md prog.c -13- 15 July 1990 GWIN by Howard C. Anderson You would link this with GWIN by using the command: ln prog.o gwin.ffCD.o -lm -lc Similarly, to use the MANX IEEE format, large code / large data version, you would compile your program with: cc -fm -mc -md prog.c You would link this with GWIN by using the command: ln prog.o gwin.fi.o -lm -lc Now if you wish to simplify further for day-to-day use, you can make one of the GWIN object modules a "library" module (this is the OTHER type of "library", like the ones in "sys:lib".) For the "ff" version of GWIN this would be done by issuing the statement: lb sys:Aztec/lib/gwin.lib gwin.ff.o Linking your program, prog.o, would then be done with the statement: ln prog.o -lgwin -lm32 -lc32 The advantage is that you don't have to remember where you put the GWIN object module. -14- 15 July 1990 GWIN by Howard C. Anderson PROCEDURE CALLS ustart(mode,xmin,xmax,ymin,ymax); char mode[255]; float x1,x2,y1,y2; Starts everything. Creates a screen and a window within the screen within which all graphics operations will occur. Mode is "low1", "low2", "high1", "high2", or "ham" or any of these with a ".backdrop" appended. low1 - 320x200 pixel, low resolution, non-interlaced, 32 colors. low2 - 320x400 pixel, low resolution, interlaced, 16 colors. high1 - 640x200 pixel, high resolution, non-interlaced, 32 colors. high2 - 640x400 pixel, high resolution, interlaced, 16 colors. ham - 320x200 pixel, hold and modify, [4096 colors]. low1.backdrop - Same as low1 but active region fills screen. low2.backdrop - Same as low2 but active region fills screen. high1.backdrop - Same as high1 but active region fills screen. high2.backdrop - Same as high2 but active region fills screen. ham.backdrop - Same as ham but active region fills screen. xmin determines the window x-pixel minimum value on the screen. xmax determines the window x-pixel maximum value on the screen. ymin determines the window y-pixel minimum value on the screen. ymax determines the window y-pixel maximum value on the screen. EXAMPLES: ustart("high2",0.0,640,0.0,400.0); will create an Amiga window that fills the screen. ustart("high1",0.0,320.0,0.0,100.0); will create an Amiga window that fills the lower left quarter of the screen. ustart("high2.backdrop",0.0,640.0,0.0,400.0); will create a Amiga window that fills the entire screen. No borders will be shown. You can draw on the entire screen. uend(); Stops everything. Call this when you are through doing graphics. UEND closes the window, the screen, the graphics libraries, frees storage allocated by GWIN, etc. Be sure to call this routine before exiting your application program. -15- 15 July 1990 GWIN by Howard C. Anderson udarea(xmin,xmax,ymin,ymax); float xmin,xmax,ymin,ymax; Default active region boundaries if UWINDO is not called: Full active window region selected by USTART. Determines the active region of the full display region. The minimum and maximum values are expressed as percents of the x and y full screen limits. UDAREA may be called at any time after USTART and may be used to define the active sub-area of the screen. All input values to this procedure must be in the range [0.0,100.0]. The xmin value must be less than the xmax value and the ymin value must be less than the ymax value. EXAMPLES: udarea(0.0,100.0,0.0,100.0); Allows use of the entire graphics region of the window. udarea(10.,20.,10.,20.); Allows use of a square sub-region of the full graphics region defined by USTART. All graphics operations are clipped and scaled to this region unless you turned clipping off with uset("ncli"). uwindo(xmin,xmax,ymin,ymax); float xmin,xmax,ymin,ymax; Default virtual window boundaries if UWINDO not called: [0.0,100.0] x and [0.0,100.0] y. Determines the virtual window boundaries. Everything inside the bounds will be mapped and plotted into the current active region of the screen as determined by USTART or UDAREA. Any real values may be used for the values input to this procedure. Xmin must be less than xmax and ymin must be less than ymax. Calls to this procedure allow pan and zoom operations (not like real-time smooth pan and zoom however. You must clear the screen and redraw everything to see the panned or zoomed image.) EXAMPLES: uwindo(0.,100.,0.,100.); Sets the virtual window to [0.0,100.0] x and [0.0,100.0] y. Every part of your image that has coordinates falling into this square will be mapped and plotted to the active graphics region. uwindo(-50.,150.,-50.,150.); Backs away or zooms out from the previous window setting. -16- 15 July 1990 GWIN by Howard C. Anderson Everything that was drawn with the previous window setting would be drawn twice as small in the center of the screen with this window setting. umove(x,y); float x,y; Moves the beam (invisibly) to the specified virtual coordinate point (with respect to the virtual window set up in UWINDO.) X and y may assume any legal floating point values. udraw(x,y); float x,y; Draws a line using the current color from the current beam position to the new beam position designated in the UDRAW call. Updates the current beam position to the new position. X and y are floating point numbers and are with respect to the virtual window set up in UWINDO. They may assume any legal floating point values. The resulting line will be clipped as necessary unless you turned clipping off with uset("ncli"). uwhere(&x,&y); float x,y; Returns the virtual coordinates of the current beam position. Note that this procedure uses ADDRESSES of the variables. urect(x1,y1,x2,y2); float x1,y1,x2,y2; Draws a rectangle outline in the current color whose opposite corner points are (x1,y1) and (x2,y2). Fills the rectangle with the current color if the USET "fill" option is in effect. This routine is much faster than calling a four-sided polygon with uplygn. uplygn(x,y,n,r); float x,y,n,r; Draws a regular n-sided polygon whose circumscribing circle is of radius "r" and whose center is at (x,y). Fills the polygon if the USET "fill" option is in effect. Current color (previously set -17- 15 July 1990 GWIN by Howard C. Anderson by the UPSET "colo" option) is applied. ucrcle(x,y,r); float x,y,r; Draws a circle of radius "r" centered at (x,y). Uses the Amiga Ellipse or AreaEllipse routine unless the circle exceeds the bounds of the viewing area. When this occurs, the circle is merely a clipped 30 sided polygon. If you need a higher resolution circle in this case, call uplygn with more sides. uoutln(); Draws a border around the current active graphics region in the current color. If the USET "fill" option is on, the region is filled with the current color. uerase(); Erases the current active graphics region as defined by UDAREA. The region is filled with the "ccol" or "clear color" that was set with UPSET. (The default is black.) uadjust(x,y,&xadj,&yadj); float x,y,xadj,yadj; This converts the coordinate (x,y) to display coordinates then converts the display coordinates back to our current virtual coordinates and provides them to you as (xadj,yadj). Since the display coordinates are discrete and the virtual coordinates are not, there are times when you need to know what the mapping is doing with your coordinates. This allows you to "adjust" coordinates to the discrete coordinate space. An example would be if you wanted two lines side by side and didn't want to try to calculate the mapping from your virtual coordinates to the display's discrete coordinates. UADJUST can be used to figure out the mapping since it "adjusts" your virtual coordinates to the virtual equivalent of the nearest discrete point in display space. urotate(x,y,theta); float x,y,theta; -18- 15 July 1990 GWIN by Howard C. Anderson Rotates the virtual coordinate system through an angle theta (value 0.0 through 360.0) relative to the point (x,y) in the virtual coordinate space. (x,y) is ALWAYS with respect to the ORIGINAL UNROTATED COORDINATE SYSTEM. The origin of the new coordinate system (0,0) is located at (x,y) of the original unrotated coordinate system. There is no way provided to rotate Amiga text. The position at which the text is to appear will be rotated and the text will begin at the new position but it will still be horizontal like this line you are reading. ugrin(&x,&y); float x, y; Graphic input routine for responding to MOUSEBUTTONS. When this procedure is called, your application waits for the user to press the left mouse button. When he does, UGRIN returns to your program with the virtual coordinates of the point selected by the user. Use this for selecting things with the mouse button. Also use this if you want the display to pause long enough for you to see what you have drawn! ugrinc(&x,&y,&event,&key); float x, y; long event; char key; Graphic input routine for responding to MOUSEBUTTONS and VANILLAKEY. UGRINC returns the x and y location of the cursor, the event type, and the keyboard character (KEY) that was pressed if the event type was "VANILLAKEY". If the event type was "MOUSEBUTTONS", the KEY returned is an "a" if it was a mouse key "down" event code and an "A" if it was a mouse key "up" event code. MOUSEMOVE events are NOT monitored by UGRINC. Note that the definition of the variables MOUSEBUTTONS and VANILLAKEY reside in the Amiga include file "intuition/intuition.h" and this file should be included if you wish to check the EVENT for these types. (For what its worth, MOUSEBUTTONS is defined as "8", VANILLAKEY is defined as "0x00200000L".) UGRINC also informs you of the "WINDOWCLOSE" event if the USET option "nclo" is in effect. (If its opposite, "clos", (the default) is in effect, the program closes everything down automatically and exits.) UGRINC also informs you of "REFRESHWINDOW" events. If the user resizes the window, the display is destroyed. You should redraw the entire display upon receiving this event. -19- 15 July 1990 GWIN by Howard C. Anderson ugrinl(&x,&y,&event,&key); float x, y; long event; char key; Same as UGRINC above except UGRINL also reports MOUSEMOVE (locator) events. If the user moves the mouse, the (x,y) coordinate of the current mouse position in virtual space is provided to you. This is useful for making running coordinate displays on the screen. (I have been doing speech signal processing and find it useful for displaying microseconds from the beginning of a segment of speech as I move the cursor within the waveform. The microsecond display updates in real-time as I move the cursor.) Now not EVERY MOUSEMOVE event is provided - you wouldn't have time to respond to them all - but the last one reported in a series is reported to you. It provides all of the ones that you could hope to use. ugrina(&x,&y,&event,&key); float x, y; long event; char key; Same as ugrinl except that ugrina does not enter a wait state. Ugrinc returns immediately with whatever events were generated by the user if any. Ugrina can be used within processing loops to give the user the option to abort a 5 hour Mandelbrot drawing for example. uigrina(&ix,&iy,&event,&key); int ix, iy; long event; char key; Same as ugrina except that uigrina does not make a coordinate transformation of the returned ix, and iy cursor coordinate data. They are returned as integers that are the cursor coordinate position data normally reported by Amiga. This increases the speed with which cursor tracking can occur. This is useful if you are calling Amiga graphics functions directly for speed. ufont(name,size); char name[255]; float size; Sets the current font and font size that will be used by UPRINT and UPRNT1. FONTNAME may be the name of a font in the directory -20- 15 July 1990 GWIN by Howard C. Anderson "sys:fonts" that you wish to use or it may be the full path name of a font on any disk you have mounted. An example of the former would be ufont("topaz",11.0). An example of the latter would be ufont( "df1:SlavicFonts/cyrillic/moskva.font", 11.0 ); from Fish disk 202. You can use any font that is in Amiga form. Many fonts are available on the Fish disks for example. GWIN searches the sys:fonts directory first. If the requested font is not found, GWIN then searches the disks. If the requested font is still not found, GWIN blinks the screen and writes an error message to the window in which you started your application. Fonts provided by Amiga are in "sys:fonts". Available font sizes can be obtained by listing the directory of the same name as the font. For example allowable sizes for the "ruby" font are 12.0, 15.0, and 8.0 as can be seen when you list the directory sys:fonts/ruby. The numbers that are printed are the allowable font sizes. For example, the ones on my system are: FONT AVAILABLE SIZES sys:fonts/curtools 16.0 sys:fonts/frettools 10.0 sys:fonts/ruby 12.0, 15.0, 8.0 sys:fonts/timetools 15.0 sys:fonts/diamond 12.0, 20.0 sys:fonts/garnet 16.0, 9.0 sys:fonts/sapphire 14.0, 19.0 sys:fonts/topaz 11.0 sys:fonts/emerald 17.0, 20.0 sys:fonts/opal 12.0, 9.0 sys:fonts/tab 8.0 uprint(x,y,data); float x,y; char data[255]; Prints the data in "data" beginning at the virtual location (x,y). "data" may be a character string or a real number. The USET options "text", "real", and "inte" determine how "data" will be interpreted. If "text" is in effect, "data" is expected to be a character string. If "real" or "inte" are in effect, "data" is expected to be a real number. It will be converted to a string and printed as either a real number or an integer in accordance with whether "real" or "inte" is in effect. uprnt1(option,data); char option[4],data[255]; -21- 15 July 1990 GWIN by Howard C. Anderson Same as UPRINT except it prints at the current beam position as set by UMOVE or some other drawing operation. OPTION is "text", "real", or "inte". The provided option is in effect for the duration of the UPRNT1 call only. Data must be either a text string or a real number. (The "inte" option truncates the real number and prints an integer.) The beam position is updated to the position of the end of the string that was printed. It is positioned properly for the beginning of the next string that you may wish to print with UPRNT1. You can use UWHERE to find the virtual location of this point if you need to know where that point is. uprscr(); Dumps the screen image to the printer. Works for an Epson LQ-850 and presumably will work for other similar printers. Output is sent to "par:", the parallel port. uzvtodconv(x,y,&xt,&yt,&ix,&iy); float x,y; float xt,yt; long ix,iy; Converts virtual coordinates (x,y) to screen display coordinates yielding floating point (xt,yt) and fixed point (ix,iy) values. uzdtovconv(ix,iy,&x,&y); long ix,iy; float x,y; Converts screen display coordinates (ix,iy) to virtual coordinates (x,y). uyorn(bodytext,positivetext,negativetext,width,height); char bodytext[],positivetext[],negativetext[]; float width,height; Puts up yes/no requester. Returns true/false value depending on the choice made by the user. Bodytext is the text of the yes or no question you wish to ask the user. Positivetext is the text that will be displayed with the positive selection box. Negativetext is the text that will be displayed with the negative selection box. Width and height are the width and height in "percentage coordinates", i.e., a width and height of 100 will fill the whole screen. A width and height of 50.0 will fill the upper left quarter of the screen. The requester is always drawn -22- 15 July 1990 GWIN by Howard C. Anderson beginning at the upper lefthand corner of the screen so width and height are measured from that point. uimove(ix,iy); long ix,iy; If you wish to bypass floating point and know exactly where you want your pixels to begin, use this command. (Or you could use the Amiga "Move" command because GWIN merely calls Move with the coordinates you pass in.) uidraw(ix,iy); long ix,iy; If you know exactly where you want your pixels to fall, use this command. If you get it wrong though anything can happen. The Amiga does not respond well to data drawn outside of the bounds of the screen. It is possible to overwrite important things accidentally and cause GURUs. This command merely passes the integer data (ix,iy) to the Amiga "Draw" command. uamenu(gwinmenu0,gwinmenu1,gwinmenu2,text,comchr,mutex,flags,routine); long gwinmenu0,gwinmenu1,gwinmenu2,mutex; USHORT flags; char comchr; char text[255]; long routine(); Uamenu makes creating menus easy. The first three parameters define the menu that you are setting up. Amiga menus have three levels. The top level (I'm calling it level 0) appears in the title bar when the right mouse button is depressed. The top level merely gives the NAME of the menu. It is highlighted when the mouse is placed over it. A level 0 menu cannot select any activity. It is there to allow you to select a level 1 menu item. A level 1 menu item can either cause an action to occur or cause a level 2 menu to appear depending upon whether a level 2 menu is attached. Lets consider the triplet (gwinmenu0, gwinmenu1, gwinmenu2). If the values are (1, 0, 0) we are referring to the first level 0 menu in the title bar. (2, 0, 0) refers to the second level 0 menu in the title bar, and so on. If the values are (3, 1, 0) we are referring to the first level 1 item in the third level 0 menu. If the values are (3, 2, 4) we are referring to the fourth level 2 item in the second level 1 menu in the third level zero menu. (Please see the example program "testmenu.c".) Menus items can be referred to in any order. GWIN will fill in with "dummy" names and actions if necessary. GWIN allocates all -23- 15 July 1990 GWIN by Howard C. Anderson storage necessary for the menus - and cleans up when you exit. Text is the text that will appear in the menu bar. Comchr is an Amiga "command character." This is a character that allows the menu item to be selected by depressing the character while holding down the right "Amiga" key. Saves the user the trouble of having to actually use the menus if he remembers the "command character." If "comchr" is chosen to be ' ', i.e., a blank, there will be no "command character" associated with the designated menu item. A command character appears to the right of the text within the menu item preceded by a symbol indicating the right Amiga key. Mutex contains mutual exclusion bits. These bits may be set to indicate which other menu items on this same level should be deselected when this menu item is selected. If mutex is set to 0, no mutual exclusion occurs. For most normal menus you should set mutex to 0. Setting bit 0 to 1 means that the first item in the menu list is excluded by selecting this item. Setting bit 5 to 1 means that the fifth item in the menu list is excluded by selecting this item, etc. Flags contains flag bits that provide additional control over menus and menu items. If you are addressing a level zero menu, only two flag bits are active: MENUENABLED - When set means that the menu is ready for action. When not set the menu and its items are disabled. MIDRAWN - When set means that the menu is display. The menu is not displayed when MIDRAWN is not set. If you are addressing a level one or level two menu, the following flags have meaning: CHECKIT - Places a check mark in front of an item when it is selected. If you use this flag, you should leave room for the check mark by having 3 or 4 leading blanks in the "text" parameter. CHECKED - Places a check mark in front of an item when the menu first comes up. ITEMTEXT - Indicates that the menu item is text rather than graphics. The current version of GWIN allows text only. You must set this flag. COMMSEQ - Indicates that there is a command key sequence. If comchr is set non-blank, you should set COMMSEQ if you wish the command key to appear in the menu bar. ITEMENABLED - Enables menu item. You must set ITEMENABLED in this version of GWIN. One of the following three menu highlighting flags must be set: HIGHCOMP - Complements all bits of this menu item's menu bar when -24- 15 July 1990 GWIN by Howard C. Anderson it is selected. Gives a visual indication to the user. HIGHBOX - Draws a box outside this item's select box. HIGHNONE - Specifies no highlighting. Routine is a function pointer that points to the function that you wish control transferred to when this menu item is selected. This is a function in your program that you design to carry out the activity selected by the user. UAMENU EXAMPLES: The following are examples of valid uamenu calls: uamenu(1,0,0,"test1",' ',0,MIDRAWN|MENUENABLED,0); uamenu(1,1,0,"test2",' ',0,MIDRAWN|ITEMTEXT|HIGHCOMP |ITEMENABLED,function110); uamenu(1,1,1,"test3",'B',0,MIDRAWN|ITEMTEXT|HIGHCOMP |COMMSEQ|ITEMENABLED,function111); uamenu(1,2,0," test4",'C',0,MIDRAWN|ITEMTEXT|HIGHCOMP COMMSEQ|CHECKIT|ITEMENABLED,function120); usetrgb(colorindex,redvalue,greenvalue,bluevalue); float colorindex,redvalue,greenvalue,bluevalue; Sets the color register indirectly pointed to by colorindex to have the designated red, green and blue values. See appendix to see which Amiga color registers are pointed to by the colorindex. The red green and blue values are converted to integers and each must be in the range 0 to 15. ugetrgb(colorindex,&redvalue,&greenvalue,&bluevalue); float colorindex; float redvalue,greenvalue,bluevalue; Retrieves the red, green and blue values of the color register indirectly pointed to by colorindex. ugetstring(x,y,width,prompt,text); float x,y,width; char prompt[],text[]; Puts a requester on the screen and waits for the user to type in -25- 15 July 1990 GWIN by Howard C. Anderson a string. X and y gives the coordinates of the upper left hand corner of the requester box. These coordinates are virtual coordinates. Width gives the width of the requester box as a virtual x coordinate distance. Prompt is a text string that you provide that lets the user know what sort of data (string) you are expecting from him. "Text" should be declared in your calling program as a length 255 character array. Prompt may be up to 255 characters. (They probably won't all fit on the screen if you use them all.) The font assumed within the requester is "topaz.font", size 8. (It comes with the machine, I expect it to be available...) usetcleanup(cleanup_routine); long cleanup_routine(); This allows you to have your own cleanup routine. It is possible for the user to exit a GWIN-based application by clicking on the close window gadget. (Unless the "nclo" uset option is in effect.) If you had done memory allocation in your application or left the sound on, etc, having your own cleanup routine allows you to clean those things up. When the close window gadget is selected, GWIN cleans up all of its storage allocation, window and screen allocations, closes libraries it opened, etc. Control is then passed to your cleanup routine if you specified one via a usetcleanup call. Cleanup_routine is a function pointer to your cleanup routine. For an example, see routines in the examples directory. uset(option); char option[4]; OPTION: "fill" Turns on polygon fill mode. "nofi" Turns off polygon fill mode. Closes and fills current polygon. (DEFAULT) "text" Sets text mode for UPRINT. UPRINT assumes input was a character string. (DEFAULT) "inte" Sets "integer" mode for UPRINT. UPRINT assumes input was a floating point number that should be truncated and displayed as an integer. "real" Sets "real" mode for UPRINT. UPRINT assumes input was a floating point number that should be displayed as a floating point number. "clip" Turns polygon and line clipping on. (DEFAULT) -26- 15 July 1990 GWIN by Howard C. Anderson "ncli" Turns polygon and line clipping off. Use this only when you are absolutely certain that your drawing will be confined to the active graphics region! "rint" If polygon "fill" mode is on and "rint" is on, then only the interior of rectangles plotted using URECT will be filled. Their borders will be unchanged. "rext" If polygon "fill" mode is on and "rext" is on, then the whole polygon including the border will be filled with the current color when URECT is called. "clos" Allows UGRIN, UGRINL, and UGRINC to close down the GWIN graphics system and exit back to the system if the user selects the close window gadget. (DEFAULT) "nclo" Allows UGRINL, UGRINC and UGRINA to report the CLOSEWINDOW event to your program. No shutdown of the GWIN system results. It is then up to you to issue the UEND() call. This option allows you to handle the problem of freeing storage areas you may have allocated in your main program among other things. NOTE: UGRIN exits any time the CLOSEWINDOW gadget is selected by the user. The "nclo" option has no effect on UGRIN. "comp" Color "complement" mode. The color with which to draw is selected by calling upset("colo",xx). The number xx is mapped to an Amiga "color register". Let's say that xx maps to color register rr. (See appendix for GWIN color mapping information.) Each color register contains red/green/blue values that determine the color drawn when that color register is used. When "comp" is in effect, instead of using color register rr for drawing, each pixel in the display bitmap that would have been drawn using rr is examined to see what color register generated it and then the complement of that register number is substituted for that pixel. Each pixel that would have been drawn using rr changes color. If you draw a line or an object once using complement mode, the line or object appears. If you draw it again, it disappears and the screen image returns to its exact original state. Complement mode is used for drawing rubberband lines, rubberband boxes, and placing objects. I have arranged the color map so that if the background color of the region over which you are drawing in complement mode is black (the default), then the colors drawn in complement mode will be what you expect, i.e., red will be red, blue will be blue, etc. This requires black to be assigned to color register zero and the current drawing color to be placed in register 15 or 31 depending upon the number of colors allowed for the type of screen you have chosen. This is why certain -27- 15 July 1990 GWIN by Howard C. Anderson colors (such as red) are repeated in the colormap. "ncom" Turns complement mode off. upset(option,value); char option[4]; float value; OPTION VALUE ACTION "colo" 0.0 through 31.0 Set current color for drawing. See Appendix 1 for color map. (Sets "A" pen and "O" pen.) "acol" 0.0 through 31.0 Set current color for A pen only. "ocol" 0.0 through 31.0 Set current color for O pen only. "bcol" 0.0 through 31.0 Set current color for background color. Background refers to text background. "ccol" 0.0 through 31 Set current color for clearing active graphics region when UERASE is called. "fsty" 0.0 through 16.0 Set font style. Amiga allows the following font style settings to be applied to font sets that allow such settings: 0.0 = DEFAULT 1.0 = Underlined 2.0 = bold 4.0 = italic 8.0 = wider Add the values of each of the above that you wish to choose and use the result as "VALUE" when you call UPSET with the "fsty" option. -28- 15 July 1990 GWIN by Howard C. Anderson APPENDIX 1 GLOBAL VARIABLES AND CONSTANTS IN GWIN MODULE ACCESSIBLE FROM PROGRAMS WHICH LINK WITH GWIN: #define SCR_MAX 2 #define WIN_MAX 50 #define MAXVECTORS 1000 struct RastPort *rport1; struct Window *win[WIN_MAX]; struct Screen *scr[SCR_MAX]; struct GfxBase *GfxBase; struct IntuitionBase *IntuitionBase; struct DiskfontBase *DiskfontBase; Rport1 is the raster port pointer that you would use if you issued your own Amiga graphics routine call. It is possible while in the GWIN system to call Amiga graphics routines. You must then of course insure that your graphics figures do not exceed the established pixel boundaries. You should not find it necessary to make such calls and they are discouraged generally - but if you need to, want to, and are willing to assume the GURU risks, feel free. Win[0] is the pointer to the window that GWIN is using. (Multiple windows are not allowed within GWIN at present. You could open another window of your own for your own purposes using Scr[0] presumably - at your risk.) It is available for use if you need it. Hopefully you won't. Don't close the window yourself in any case. GWIN closes everything and releases all allocated space when you call UEND() or when you select the close gadget. Scr[0] is the pointer to the screen that GWIN is using. (Multiple screens are not allowed at present.) It is available for use if you need it. Hopefully you won't. Don't close the screen yourself in any case. GWIN closes everything it opened and releases all space it allocated when you call UEND(). The MAX_VECTOR variable refers to the maximum number of sides that can be handled by uplygn. You will NOT need a 1000 sided polygon. It will merely look like a VERY slowly drawn circle and a 100 sided polygon is a nearly perfect approximation. You could also bump up against this limit if you do too many UDRAWS in a row without doing a UMOVE while in fill mode. -29- 15 July 1990 GWIN by Howard C. Anderson COLOR TRANSLATION TABLE. Use these values for color_value in upset("colo",color_value) calls to obtain the corresponding color. black = 0.0; red = 1.0; green = 2.0; blue = 3.0; cyan = 4.0; yellow = 5.0; magenta = 6.0; white = 7.0; darkred = 8.0; darkgreen = 9.0; darkblue = 10.0; orange = 11.0; lime = 12.0; forestgreen = 13.0; aqua = 14.0; red2 = 15.0; violet = 16.0; brickred = 17.0; grey = 18.0; goldorange = 19.0; skyblue = 20.0; redorange = 21.0; brown = 22.0; pink = 23.0; purple = 24.0; tann = 25.0; bluegreen = 26.0; darkbrown = 27.0; lightaqua = 28.0; cadyellow = 29.0; white2 = 30.0; red3 = 31.0; -30- 15 July 1990 GWIN by Howard C. Anderson ACTUAL COLOR REGISTER ASSIGNMENTS IN GWIN Normally you would't use these. You would use upset("colo",(float)color_number) where color_number is given in the color translation table above. The "actual color register" numbers in this table would be used only if you wished to directly call SetAPen(rport1,number) or other similar Amiga call directly. (Allowable but discouraged.) black = 0; blue = 1; red = 2; green = 3; cyan = 4; magenta = 5; lime= 6; yellow = 7; aqua = 8; darkblue = 9; darkgreen = 10; darkred = 11; forestgreen = 12; orange = 13; white = 14; red2 = 15; violet = 16; brickred = 17; grey = 18; goldorange = 19; skyblue = 20; redorange = 21; brown = 22; pink = 23; purple = 24; tann = 25; bluegreen = 26; darkbrown = 27; lightaqua = 28; cadyellow = 29; white2 = 30; red3 = 31; -31-