home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fish 'n' More 2
/
fishmore-publicdomainlibraryvol.ii1991xetec.iso
/
disks
/
disk433.lzh
/
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-