home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Frozen Fish 1: Amiga
/
FrozenFish-Apr94.iso
/
bbs
/
alib
/
d5xx
/
d571
/
gwin.lha
/
Gwin
/
Gwin.doc
< prev
next >
Wrap
Text File
|
1991-12-22
|
78KB
|
2,046 lines
17 Nov 1991 GWIN by Howard C. Anderson
GWIN GRAPHICS SYSTEM - Version 2.0
AMIGA SHARED LIBRARY VERSION
Author: Howard C. Anderson
1895 E. Auburn Dr.
Tempe, Az 85283
(602) 897-7425
GWIN V2.0 (c) Copyright 1991 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-
17 Nov 1991 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:
#include "gwin.user.h"
main()
{
float x,y;
USTART("high2",0.,100.,0.,100.);
umove(G,20.,20.);
udraw(G,50.,50.);
ugrin(G,&x,&y);
UEND();
}
Ahhhh... Isn't that better???
(NOTE: USTART and UEND are macros contained in gwin.user.h. This is a
change from previous versions of GWIN. More will be said regarding
these two macros in the "ustart" and "uend" procedure descriptions
below. Another change is the use of the variable "G" in the GWIN
procedure calls. I tried to avoid this but shared Amiga libraries are
reentrant. G is a pointer to something similar to a "Graphics Status
Area" in the X-window system. If I had found a safe way to hide it
using operating system "hooks" I would have but I don't think any
provision for this was made readily available in the Amiga operating
system. I could cheat on the operating system to do it but that would
not be safe in the long run.)
Other example programs are provided in the GWIN EXAMPLES directory.
-2-
17 Nov 1991 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 macro 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.
NOTE: I have made changes to attempt to accomodate Europeans using PAL
instead of NTSC television standards so you should be able to use
larger y values than the ones listed above if I was successful. See
"ustart" procedure description for details.
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.
-3-
17 Nov 1991 GWIN by Howard C. Anderson
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
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.
-4-
17 Nov 1991 GWIN by Howard C. Anderson
TEXT
Ufont establishes the font that will be used for subsequent uprint and
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 returning a
non-zero value. (Unless the uset option "nclo" is set for ugrinc and
ugrinl in which case the CLOSEWINDOW event is returned to you via the
-5-
17 Nov 1991 GWIN by Howard C. Anderson
event parameter.)
NOTE: THE ABOVE IS A CHANGE FROM PREVIOUS VERSIONS OF GWIN. You MUST
monitor the return value and issue a UEND() and an exit(0) whenever
the returned value is non-zero. This change was required because the
GWIN library is opened from your program when you issue the USTART
procedure call and the only way I can get the library closed properly
is to do it under control of your program. The examples in the
example directory all reflect any necessary code changes.
NOTE: ANOTHER CHANGE FROM PREVIOUS VERSIONS OF GWIN is that return of
the event and keystroke for ugrinl, ugrinc, ugrina, and uigrina, is
now handled via a structure. This was forced on me by the LATTICE
compiler. It uses index register a4 as a base register for the object
code. The way I handle menu selections is to call the user-selected
function via a function pointer. Ugrinl, ugrinc, ugrina, and uigrina
are called using pragmas. Pragmas save and restore registers. When I
call your menu function, the registers have not yet been restored.
When I used a4, LATTICE object code blew up. I have restricted my use
of registers to a0, a1, a2, and a3 now. All examples have been
updated to reflect these changes.
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
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 uigrina 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.)
-6-
17 Nov 1991 GWIN by Howard C. Anderson
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.
SCREEN DUMP TO PRINTER
If you have an Epson LQ series printer, you can dump the screen image
to the printer using uprscr.
ABORT
ANOTHER CHANGE. Abort handling via an AMIGA library does not make
sense. I have removed the abort handler. If you catch your own abort
signals, be sure to call UEND() if USTART has been issued.
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-
17 Nov 1991 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.
One good thing about using an AMIGA shared library is that the object
code storage requirements are greatly reduced. Object code for all of
the examples is now able to reside on the disk.
The examples and a brief description of each are as follows:
clipdemo
Demonstrates setup of a GWIN clipping window within an Amiga
window.
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.
text
Demonstrates use of font selection and various text display
options.
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-
17 Nov 1991 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.
three-d
Allows construction of three-dimensional figures. You would
need red/blue glasses to see the three-dimensional effect
however.
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.
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
-9-
17 Nov 1991 GWIN by Howard C. Anderson
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-
17 Nov 1991 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. I released version 1.1 of GIN to
provide release 5.0 compatible graphics object files that could be
used to create GWIN applications under the release 5.0 version of the
MANX AZTEC C compiler. Similarly, Lattice released Version 5.1 of
their compiler which produces object modules that, I have been told,
will not link with object modules produced by version 5.0. (I would
have thought that non-upward compatibility of object modules would
have rated a major number change like release 6.0 or something.)
Reacting continually to all this vendor-induced recurrent obsolescence
of object libraries seemed like a losing proposition.
I had investigated turning GWIN into an AMIGA library several times
but rejected it because of the horrendous complexity associated with
making an AMIGA library. Finally the answer appeared in premier issue
of "The AmigaWorld Tech Journal" in an article entitled "Shared
Libraries for the Lazy" by Jim Fiore. This article and the LibTool
program on the disk reduced the complexity to a level just below my
pain threshold.
It was still a lot of work and I'm not entirely happy with some of the
complexity I had to add back into the GWIN system but I think over all
the trade-off is good. Since GWIN is now a library, I won't have to
worry about all the changes that the MANX and LATTICE people make.
You LATTICE people are now supported (I do not have a LATTICE
compiler) properly. The down side is that you have to add the "G"
parameter to the procedure calls and you have to check the return
codes from some of the routines to see what errors occurred within the
GWIN library routines if something goes wrong. (Libraries cannot
communicate directly to the screen so I cannot print error messages
from within the GWIN library.)
MANX NOTES
I used version 5.0e of the MANX AZTEC compiler to build the library.
To use the GWIN library, you must write a C program that calls
procedures in the GWIN library, and compile it with the Manx
compiler. (The makefile in the gwin/examples directory shows many
examples of compile and link statements that accomplish what is
necessary.
I have simplified the problem of options regarding code size, floating
point type, etc. The GWIN library uses the "Motorola Fast Floating
Point" format and "large code" and "large data". This seems to solve
-11-
17 Nov 1991 GWIN by Howard C. Anderson
all sorts of problems and reduces my maintenance problem.
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 -mc -md -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 -lmfl -lcl
This will result in the executable graphics module "prog".
When "prog" runs, it will look for the library "GWIN.library" in the
directory libs:. You must copy the file "GWIN.library" to the libs:
directory to run GWIN applications because that is where the system
looks to load shared library files. The GWIN shared library is
automatically loaded by the system when the USTART macro is executed.
LATTICE NOTES
Similar to above. You should copy the file "gwin.lattice.user.h" in
the examples directory to "gwin.user.h". This gets the correct LATTICE
pragmas. Also copy the file Makefile.lattice to the file Makefile.
You will then be able to use "make" to compile the example programs
with the LATTICE compiler. For other programs, sumply use
LATTICE-specific compilation and linking commands similar to the ones
used in Makefile.lattice. Use large code, large data, and the Motorola
Fast Floating Point format. Be sure to place GWIN.library in "libs:"
before running any program that calls GWIN procedures.
-12-
17 Nov 1991 GWIN by Howard C. Anderson
PROCEDURE CALLS
USTART(mode,xmin,xmax,ymin,ymax);
char mode[255];
float x1,x2,y1,y2;
Macro that you should use instead of ustart below. This macro
open up required libraries, defines the G variable, opens up
screens and windows and sets up everything ready for use of other
GWIN procedure calls. You must include the include file
"gwin.user.h" in your program because that is where the USTART
macro is defined and also where the G parameter is defined. The
USTART parameters are the same as those defined in ustart below
since they are passed directly to ustart.
struct G_user_subset *ustart(mode,xmin,xmax,ymin,ymax);
char mode[255];
float x1,x2,y1,y2;
You should use the USTART macro above instead of ustart in most
cases. USTART calls ustart. Ustart returns a pointer to a
G_user_subset structure that is used in subsequent GWIN procedure
calls. This structure is defined in gwin.user.h which should be
included in each application program that you write that uses
GWIN procedures. 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.0, 400.0);
will create an Amiga window that fills the screen.
ustart("high1", 0.0, 320.0, 0.0, 100.0);
-13-
17 Nov 1991 GWIN by Howard C. Anderson
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.
What I attempted to do for you PAL users in Europe is to allow
you to enter ymax values outside of the above ranges. I received
a letter from Jerome Santini in France indicating that I should
check GfxBase->NormalDisplayRows and use either it or
GfxBase->NormalDisplayRows/2 for the maximum ymax value. This
data is undocumented in the "Amiga ROM Kernal Reference Manual:
Libraries and Devices" that was printed by Addison Wesley in the
USA in 1986. My dealer didn't have anything newer or more
complete. I used the MANX debugger to look at the value and
found it was always 200 here on my machine. If the value in
Europe is 256 then I should multiply by two rather than divide by
two. If the value in Europe is 512, I should do as Jerome says.
But if it is 512, then I would expect the value here in the USA
to be 400 which it is not. The only safe thing to do, to be sure
you COULD get higher values, was to use the value
GfxBase->NormalDisplayRows for the maximum ymax value
corresponding to low-resolution screens and to use the value
2*GfxBase->NormalDisplayRows for the maximum ymax value
corresponding to high-resolution displays. This leaves the
maximum values unchanged from the above limits in the USA and
hopefully accomodates you PAL users in Europe. Unfortunately I
have no way to test this here. It should work. The only thing
that I would expect to go wrong is that you might be able to
specify a screen size that would be too large in the y direction
which would probably cause a problem. Write to me if you PAL
users can't get a full size screen now. The following examples
should now be valid in Europe:
ustart("low1", 0.0, 320.0, 0.0, 256.0);
ustart("high2", 0.0, 640.0, 0.0, 512.0);
ustart("high2.backdrop", 0.0, 640.0, 0.0, 512.0);
UEND();
Macro that 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.
-14-
17 Nov 1991 GWIN by Howard C. Anderson
uend(G);
You should use UEND above instead of uend for most purposes.
UEND calls uend which actually closes things down. The UEND
macro also closes the GWIN library.
udarea(G,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(G,0.0,100.0,0.0,100.0);
Allows use of the entire graphics region of the window.
udarea(G,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(G,"ncli").
uwindo(G,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(G,0.,100.,0.,100.);
-15-
17 Nov 1991 GWIN by Howard C. Anderson
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(G,-50.,150.,-50.,150.);
Backs away or zooms out from the previous window setting.
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(G,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(G,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(G,"ncli").
uwhere(G,&x,&y);
float x,y;
Returns the virtual coordinates of the current beam position.
Note that this procedure uses ADDRESSES of the variables.
urect(G,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.
-16-
17 Nov 1991 GWIN by Howard C. Anderson
uplygn(G,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
by the upset "colo" option) is applied.
ucrcle(G,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(G);
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(G);
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(G,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.
-17-
17 Nov 1991 GWIN by Howard C. Anderson
urotate(G,x,y,theta);
float x,y,theta;
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(G,&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(G,&x,&y,&uuev);
float x, y;
struct uuevent uuev;
Graphic input routine for responding to MOUSEBUTTONS and
VANILLAKEY. Ugrinc returns the x and y location of the cursor,
the event type (uuev.event), and the keyboard character
(uuev.key) that was pressed if the event type was "VANILLAKEY".
If the event type was "MOUSEBUTTONS", the uuev.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: Uuev is defined and allocated in gwin.user.h. Creation of
the uuevent structure was necessary because of a limitation of
the LATTICE compiler. I would have preferred to have a call that
looked like this: ugrinc(G,&x,&y,&event,&keystroke).
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".)
-18-
17 Nov 1991 GWIN by Howard C. Anderson
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.
ugrinl(G,&x,&y,&uuev);
float x, y;
struct uuevent uuev;
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(G,&x,&y,&uuev);
float x, y;
struct uuevent uuev;
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(G,&ix,&iy,&uuev);
int ix, iy;
struct uuevent uuev;
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.
-19-
17 Nov 1991 GWIN by Howard C. Anderson
ufont(G,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
"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(G,"topaz",11.0). An example of the latter would
be
ufont(G, "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(G,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
-20-
17 Nov 1991 GWIN by Howard C. Anderson
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(G,option,data);
char option[4],data[255];
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(G);
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(G,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(G,ix,iy,&x,&y);
long ix,iy;
float x,y;
Converts screen display coordinates (ix,iy) to virtual
coordinates (x,y).
-21-
17 Nov 1991 GWIN by Howard C. Anderson
uyorn(G,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
beginning at the upper lefthand corner of the screen so width and
height are measured from that point.
uimove(G,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(G,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(G,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
-22-
17 Nov 1991 GWIN by Howard C. Anderson
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
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
-23-
17 Nov 1991 GWIN by Howard C. Anderson
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
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(G,1,0,0,"test1",' ',0,MIDRAWN|MENUENABLED,0);
uamenu(G,1,1,0,"test2",' ',0,MIDRAWN|ITEMTEXT|HIGHCOMP
|ITEMENABLED,function110);
uamenu(G,1,1,1,"test3",'B',0,MIDRAWN|ITEMTEXT|HIGHCOMP
|COMMSEQ|ITEMENABLED,function111);
uamenu(G,1,2,0," test4",'C',0,MIDRAWN|ITEMTEXT|HIGHCOMP
COMMSEQ|CHECKIT|ITEMENABLED,function120);
usetrgb(G,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(G,colorindex,&redvalue,&greenvalue,&bluevalue);
float colorindex;
-24-
17 Nov 1991 GWIN by Howard C. Anderson
float redvalue,greenvalue,bluevalue;
Retrieves the red, green and blue values of the color register
indirectly pointed to by colorindex.
ugetstring(G,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
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(G,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(G,option);
char option[4];
OPTION:
"fill" Turns on polygon fill mode.
"nofi" Turns off polygon fill mode. Closes and fills
current polygon. (DEFAULT)
-25-
17 Nov 1991 GWIN by Howard C. Anderson
"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)
"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(G,"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
-26-
17 Nov 1991 GWIN by Howard C. Anderson
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
colors (such as red) are repeated in the colormap.
"ncom" Turns complement mode off.
upset(G,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.
-27-
17 Nov 1991 GWIN by Howard C. Anderson
APPENDIX 1
GLOBAL VARIABLES AND CONSTANTS IN GWIN MODULE ACCESSIBLE
FROM PROGRAMS WHICH USE THE GWIN LIBRARY AND INCLUDE THE FILE gwin.user.h:
#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.
-28-
17 Nov 1991 GWIN by Howard C. Anderson
COLOR TRANSLATION TABLE.
Use these values for color_value in upset(G,"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;
-29-
17 Nov 1991 GWIN by Howard C. Anderson
ACTUAL COLOR REGISTER ASSIGNMENTS IN GWIN
Normally you would't use these. You would use
upset(G,"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;
-30-
17 Nov 1991 GWIN by Howard C. Anderson
ERROR RETURN CODES
Since AMIGA libraries cannot write to the screen, the following return
code values are used to indicate problems:
RETURN VALUE GWIN PROCEDURE MEANING
1 abort_ User abort. (I'm not sure that this is
possible now.)
2 USTART, udarea Illegal values of screen size entered.
Error occurs when:
xmax <= xmin || ymax <= ymin
3 uwindo Illegal parameters passed to uwindo. The
error occurs when:
(xmax-xmin) <= 0.0 || (ymax-ymin) <= 0.0
4 ugrin A CLOSEWINDOW event has occurred. You
ugrinc must call UEND().
ugrinl
ugrina
uigrina
5 uplygn Illegal parameters passed to uplygn.
Largest legal polygon has 2000 or less
sides. You have requested a polygon
with more than 2000 sides.
6 uamenu Negative menu number was passed to
uamenu. You cannot use negative
menu numbers.
7 usetrgb A value greater than 15.0 was entered for
red, green or blue. Cannot have color
values greater than 15.0.
8, 9, 10 ustart Internal, required libraries not found.
These are intuition.library,
graphics.library and diskfont.library.
The result of failure of one of these is
that ustart will return a NULL value
for G.
11 ustart Internal, screen cannot be opened.
Ustart checks xmin, xmax, ymin, ymax
for validity. The USTART (macro)
returns NULL.
12, 13, 14, ustart Internal, window could not be opened.
15, 16, 17 Check xmin, xmax, ymin, ymax for
validity. The USTART macro returns
NULL.
100 All procedures The G structure is invalid. Either the
pointer is incorrect or the data has
been overwritten.
-31-