The HOOPS/3dGS Platform Device Guide details a list of the currently supported drivers. This guide details a list of drivers that are deprecated.
The HOOPS Computer Graphics Metafile (CGM) Driver has been verified with clear text encoding on various host computers running Solaris, AIX, IRIX, HP-UX, Linux, and Windows. It has also been tested with ANSI binary encoding using the CGM interpreter on HP-UX Starbase. The ANSI binary, CALS, and clear text formats have been verified using METACHECK. In theory, it should run from any other computer system driving CGM-compatible devices.
To set up your machine so that the CGM driver is the default HOOPS driver you must define the environment variable "HOOPS_PICTURE". Typing:
Unix> setenv HOOPS_PICTURE cgm/output.txt
Specifies a file named output.txt to contain your CGM output. Graphics that you insert into the segment named "?picture" are placed into the CGM output file. For instructions on using "?hardcopy" in place of "?picture" see the discussion of this topic for the HPGL driver. The same process applies.
To open the CGM driver explicitly within a running program, you would create a segment with the special name "?driver/cgm/output.txt".
The file, CGM.HDI, must be present at run-time either in the current directory or in the current PATH. For faster access, these files are in a directory (e.g. \hoops\driver) defined in the HOOPS_DRIVERS environment variable.
In addition to setting the HOOPS_PICTURE environment variable, you will also want to set the HOOPS physical size driver option to match the drawing area of the CGM display device. The physical size of the ultimate viewing device is used by HOOPS (to maintain aspect ratio and scale (if scaling is enabled)) when CGM commands are written to the specified output file. For instructions on setting the physical size driver option, see the discussion of this topic for the HPGL2 driver. The same process applies.
The HOOPS CGM driver allows for 4 possible data encoding methods; however, at this time, only 3 methods have been implemented (1 is used for debugging). The encoding method used by HOOPS is selected based on the output format driver option or the 3 character file extension (lower case) of the output file specified via HOOPS_PICTURE:
Driver Option :ANSI Binary
Suffix :< name >.ans
Encoding :ANSI binary encoding
Notes :implemented - this is the default encodingDriver Option :CALS binary
Suffix :< name >.cal
Encoding :CALS (Computer aided Acquisition and Logistics Support) binary encoding.
Notes :implementedDriver Option :
Suffix :< name >.chr
Encoding :Character Encoding
Notes :not implemented - HOOPS printf clear text output is generated to CGM file when this suffix is supplied.Driver Option :Clear Text
Suffix :< name >.txt
Encoding :Clear text encoding.
Notes :implemented.
If HOOPS_PICTURE is set to a file name that ends with something other than
one of these suffixes (or no suffix at all), ANSI binary encoding is used.
HOOPS provides users with the ability to specify a variety of line styles and widths. With regard to the CGM driver, there are two possible methods of rendering lines of a specified width and style:
The first method is to use the CGM LINE WIDTH and LINE STYLE commands to set drawing attributes for the CGM interpreter. The advantage of this method is that fewer drawing commands are generated to the output file, and drawings adhere to device specific characteristics. The disadvantage is that drawings may have slight differences from device to device depending on their respective implementations of LINE WIDTH and LINE STYLE.
The second method is to have HOOPS draw all patterned and wide lines by successive combinations of thin solid lines or polygons. The advantage is that device specific anomalies are bypassed, but the disadvantage is that CGM output files are much much larger.
The HOOPS CGM driver allows users to select either of these methods. The customary method of communicating with a HOOPS driver regarding drawing preferences is with the HOOPS debug driver option.
line style | default | debug = 2 |
`----' | Method 1 | Method 1 (width = 1) Method 2 (width > 1) |
`- -' | Method 1 | Method 2 |
`...' | Method 1 | Method 2 |
`-.-.' | Method 1 | Method 2 |
`-..-..' | Method 1 | Method 2 |
`-...' | Method 1 | Method 2 |
`-- --' | Method 1 | Method 2 |
center | Method 1 | Method 2 |
phantom | Method 1 | Method 2 |
setenv HOOPS_DRIVER_OPTIONS debug=0
This is the default. It does not even have to be set. What this means is that line widths are specified using the CGM LINE WIDTH command and line patterns for solid, dashed, dotted, dash dot, and dash dot dot, are specified using the CGM LINE STYLE command, i.e. method 1. Patterns for long dash, dash dot dot dot, center, and phantom are not available in the standard CGM set so these are always rendered using method 2.
setenv HOOPS_DRIVER_OPTIONS debug=2
This instructs HOOPS to ignore the built-in line width and line style capabilities and render all patterned or wide lines using method 2.
By default the HOOPS CGM driver assumes that the CGM interpreter is a mapped device that can handle up to 256 color map entries. This is the maximum number of colors allowed in this mode; however, if fewer colors are actually possible, the number of colors driver option can be used to set this to a lower number.
In addition to devices with color maps of up to 256 colors, the HOOPS CGM driver can generate output files that can be interpreted by devices with direct color specification. The advantage of such devices is that they are not limited to a predetermined maximum number of colors (number of colors driver option is then moot). To instruct HOOPS that the intended CGM interpreter is a direct color device, once again, the debug driver option is used.
setenv HOOPS_DRIVER_OPTIONS debug=4
This instructs HOOPS to ignore its default method of mapped color handling and use direct color.
On the other hand, in cases where a mapped color device has a fixed pen set (e.g. 0 = red, 1 = white, 2 = black), application programs may indicate this mapping via a structure:
struct {
unsigned char number_of_colors;
struct {
unsigned char r, g, b, pen_number;
} color[256];
} User_Defined_Map;
The application program fills in this structure and passes its address to HOOPS via the use colormap ID option. For the example cited, the application code would look like:
User_Defined_Map map;
char options[256];
map.number_of_colors = 3;
map.color[0].r = 255;
map.color[0].b = 0;
map.color[0].g = 0;
map.color[0].pen_number = 0;
map.color[1].r = 255;
map.color[1].b = 255;
map.color[1].g = 255;
map.color[1].pen_number = 1;
map.color[2].r = 0;
map.color[2].b = 0;
map.color[2].g = 0;
map.color[2].pen_number = 2;
sprintf (options, "use colormap ID =%d", &map);
HD_Set_Driver_Options (options);
By passing the address of this map to the CGM driver, the driver writes a color map to the CGM file where red is the first entry in the map (index = 0), white is the second entry (index = 1), and black is the third (index = 2). Although the example provided has pen numbers appearing in order (e.g. 0, 1, 2), this is not required. Furthermore, a one to many relationship may exist between (r,g,b) values and pen numbers. Thus it is possible to map two different colors to the same pen number. (This is useful when a device may lack a particular pen color, e.g. orange, that can be mapped to an available color, e.g. red.) In addition, if a HOOPS program uses colors other than those specified in the map (e.g. blue for the example cited), the indexes for these unspecified colors are derived in the same manner as if the user supplied pen map was not defined. The next available pen index (for the example, blue would be pen number 3) is simply used. If this is not desirable, the debug driver option may be set to instruct the driver to map all unspecified colors to CGM index 1:
setenv HOOPS_DRIVER_OPTIONS debug=64
Naturally, the debug = 64 option has no effect unless the use colormap ID option is also specified. The debug = 4 option cannot be used in conjunction with the use colormap ID option. If this occurs, the user defined color map is ignored, and direct color specification appears in the CGM output file. The lowest pen number in the user defined color map should not be less than the value set (default = 0) by the first color driver option. If this occurs, the CGM driver generates an error message and the first color driver option is ignored. Likewise, with pen number values being unsigned chars, legal values are 0 to 255.
A second method of dealing with color indexes is by number. By default, with calls to set color of the form:
HC_Set_Color ("windows = white, lines = black");
HOOPS allocates colors as needed, e.g. color index 255 and color index 254. HOOPS simply starts from the tail of map and works forward. In this example, white is 255, and black is 254. The CGM driver recognizes that only 2 colors have been allocated and writes a color table to the CGM output file of the form:
COLRTABLE 0
(255, 255, 255),
(0, 0, 0);
The color table starts at index 0 and has two entries.
On the other hand, if a user program sets colors by index:
HC_Define_Color_Map ("red, blue, black, white");
HC_Set_Color_By_Index ("windows", 3);
HC_Set_Color_By_Index ("lines", 2);
HOOPS allocates colors by index, e.g. red= 0, blue = 1, black = 2, and white = 3. HOOPS starts at the front of the map and works forward. Once again, the CGM driver recognizes that only 2 colors have been used and writes a color table to the CGM output file that is just like the example previously described. This poses a problem if the application program really intends for white to be index 3 (not 0) and black to be 2 (not 1). To instruct the CGM driver that color indexes should be preserved in the CGM color table, the debug driver option is set.
set HOOPS_PICTURE_OPTIONS=debug:32
setenv HOOPS_DRIVER_OPTIONS debug=32
When the preserve index number (debug = 32) option is used, the CGM driver still recognizes that only 2 colors are used and writes a color table to the CGM output file of the form:
COLRTABLE 2
(0, 0, 0),
(255, 255, 255);
If the program uses a third color, red (index 0), the map written to the file is:
COLRTABLE 0
(255, 0, 0),
(1, 1, 1),
(0, 0, 0),
(255, 255, 255);
Since the color blue was not actually used in the program, a dummy entry
(1, 1, 1) is inserted into index 1 so that black is still 2 and not 1. Naturally
the debug = 32 option has no effect if the debug = 4 (direct color) option
is also set.
By default the HOOPS CGM driver assumes that the CGM interpreter is a frame buffer device. As such, windows are drawn as filled rectangles. Although this practice allows HOOPS programs to include overlapping windows in their CGM output (one solid rectangle can cover a previously drawn one), it does not work well for pen plotter type devices (what you draw is what you get).
To accommodate such devices, the CGM driver can issue CGM background color commands in place of drawing filled rectangles. By using background color, pen plotting devices can ignore or render window colors based on their own heuristics. To activate use of the background color method, the debug driver option is used.
setenv HOOPS_DRIVER_OPTIONS debug=8
When the background color (debug = 8) option is used, the background color
is set to the window color on the ?picture segment. If this option is set
in conjunction with the use colormap ID option, the supplied color map should
not assign any color to pen 0. If pen 0 is specified in the supplied map,
the color assigned to pen 0 must match the window color set on the ?picture
segment.
The HOOPS CGM driver outputs its drawing commands to a virtual device coordinate space of (0,0) up to as large (32766,32766). The actual VDC used is based on the physical size driver option. The VDC is set as large as possible to allow for maximum precision (but be within the 32766 limit) and still maintain the aspect ratio defined by the physical size driver option. It is not necessary that the physical size be specified as a square. A rectangular VDC is possible.
Although this technique works on many devices, for some a virtual device coordinate system of (0,0) to (32766,32766) is too precise. In short, there are just too many virtual pixels for the physical size of the device. The results are pictures whose wide lines are too thin or varying geometry that gets mapped to the same pixel locations. To select a precision value that is less than 32766 (e.g. 1280), the write mask driver option is used.
setenv HOOPS_DRIVER_OPTIONS write mask=1280
As mentioned in the section on Virtual Device Coordinates, by default, HOOPS CGM output is not scaled. This allows HOOPS pictures to be interpreted by any CGM device and fill the entire viewing area. This is normally desirable; however, there may be instances where it is desirable to have the picture comprise only a portion of the viewing area, e.g., display an A size drawing on a C size piece of paper. For this, scaling is turned on via the debug option:
setenv HOOPS_DRIVER_OPTIONS debug=16
When scaling is enabled, the CGM driver computes the necessary scale factor to map VDC units to physical size. The result is a drawing that is the exact physical size as defined by the physical size driver option; however, there may be instances where this is not desired. A drawing smaller than the specified physical size may be desired. For this, the scale factor must be specified. Since the pen speed option serves no purpose for this driver, this option has been perverted to supply the scaling factor. For example, to specify that the drawing is to be half the size of the physical device:
setenv HOOPS_DRIVER_OPTIONS "pen speed=0.5"
The pen speed option is only necessary when the default mapping of VDC to physical size units is not what is wanted. The default value for pen speed is 1.0, so its default value has no impact on the scale factor calculation.
The HOOPS CGM driver adds a comment as the metafile description of each CGM file. The comment is specified to the CGM driver by setting the HOOPS title driver option.
setenv HOOPS_DRIVER_OPTIONS title='my comment'
The following is a summary of the relationships among the various CGM driver options and their effects.
The HOOPS PICT driver can be run on various host computers to produce an Extended Format Version 2 PICT file which is readable by many Macintosh programs.
There are two ways to use the PICT driver from HOOPS. The simplest is to replace the computer screen with the PICT driver as the graphics output device. The advantage of this method is that the software being used does not have to be modified or recompiled.
To set up your computer so that the PICT driver is the default HOOPS driver for your graphics programs, define the environment variable "HOOPS_PICTURE" to be "pict/picture0". Please see the release notes for your particular operating system for details on how to define environment variables. Once this definition is made, HOOPS programs that refer to the HOOPS "?Picture" segment will write a picture to a file named "picture0" each time they update the display.
Any valid file name can be substituted for "picture0". If the name contains HOOPS special characters, you should add extra quote marks as described in the system notes. For example, to send the output to a file in another directory, you might type:
setenv HOOPS_PICTURE "pict/'/usr/jeff/picture0'"
on UNIX under csh.
define HOOPS_PICTURE "pict/'picture0'"
on VMS.
HOOPS_PICTURE = "pict/'MyDisk:picture0'"
in your "Hoops Preferences" fileforothee Macintosh.
The extra quotes keep the special characters, if any, from being interpreted as HOOPS segment delimiters. Either single or double quotes will work.
Another method lets you display your graphics on the screen and also send the same picture to a PICT file. To do this, however, you have to add some more code.
First specify "HOOPS_PICTURE" as you would normally, then define "HOOPS_HARDCOPY" as "pict/picture0" as above. This will define the alias named "?Hardcopy" when your program starts up. Note that you can specify driver options for "?Hardcopy" from outside of the program by using the environment variable "HOOPS_HARDCOPY_OPTIONS".
To send a single snapshot of your "?Picture" scene to a PICT file, a typical code sequence would be:
Open_Segment ("?Hardcopy") Include_Segment ("?Picture") Update_Display () Close_Segment () Delete_Segment ("?Hardcopy")
Note that HOOPS will re-open the file each time this sequence is called. On certain systems such as Macintosh, MS-DOS, and UNIX, re-opening a file means the previous version is overwritten.
A more sophisticated example sets all this up in advance by using:
Open_Segment ("?Hardcopy"); Include_Segment ("?Picture") Set_Visibility ("off") Close_Segment ()
Then, to take a snapshot as your program is running along, use:
Close_Segment ()Open_Segment ("?Hardcopy"); Set_Visibility ("on") Close_Segment () Update_Display () Open_Segment ("?Hardcopy"); Set_Visibility ("off")
Finally, delete "?Hardcopy" when done to properly close the file.
Delete_Segment ("?Hardcopy")
You can also open the PICT driver explicitly with segment names like "?driver/pict/picture0". You may want to save several pictures, perhaps frames in an animation. Simply give each picture a different, possibly consecutive name, like "?driver/pict/picture0", "?driver/pict/picture1", "?driver/pict/picture2", etc.
NOTE: For protected mode HOOPS users, the file "PICT.HDI" for the 80387 and the file "PICT.HDW" for the Weitek 1167 must be present at runtime either in the current directory or in the current "PATH". For faster access, these files are in a directory defined in the "HOOPS_DRIVERS" environment variable.
The "physical size" driver option is often used to set the total size of the picture. The driver writes PICT files at a resolution of 72 pixels per inch. You can use this figure in calculating the physical size if you know only the number of pixels you desire. The fixed resolution is not a problem since QuickDraw knows how to re-scale the picture for display on Macintoshes of different resolutions. If you do not specify a physical size, then the driver will assume a size of 640 by 480 pixels, which, at 72 dpi, equals a physical size of 22.578 by 16.933 centimeters.
The "subscreen" driver option may be useful to further restrict the size of the picture.
No fonts are distributed with HOOPS. The fonts distributed with the PC version of HOOPS are not used by the PICT driver. The driver uses a font encoding which is expanded when the PICT file is later displayed. Because of this, the registration of fonts is dependent on the display device, not the machine on which the picture was created.
Since no particular font is guaranteed to exist on the destination machine, only a few common fonts are available from within the PICT driver.
When you call Set_Text_Font, you can use either Macintosh-style font names, or the portable "generic" names that HOOPS provides. The following list identifies the automatic mapping between Set_Text_Font's generic names and the fonts actually available on a Macintosh:
HOOPS Generic Font Name | Macintosh Font Name |
system default | sysFont (usually Chicago) 12 pt |
roman | New York |
sans serif | Geneva |
typewriter | Monaco |
Since the PICT driver is most commonly run along with a screen driver, if you want to name a particular font you will probably want to use the multiple-choice "name=(name1, name2, ...)" style in your Set_Text_Font calls, so you can name both your PICT choice and your screen choice.
The PICT driver writes files in direct RGB (32-bit color) at a resolution of 72 dpi. Since the driver writes Extended Format Version 2 PICTs, the resolution data is encoded with the file, ensuring accurate display no matter what the target device's resolution or aspect ratio.
Assuming you wrote the file using the driver running on a machine other than a Macintosh, you'll need to transport the file to a Mac for display or inclusion in a document. You can use any suitable transport mechanism such as Kermit, FTP, etc. Remember that the file will contain special characters and therefore it must be transferred in "binary" mode.
Once the file is on the Macintosh, it should be exactly as if it were written on the Mac originally. The pertinent information is stored in the data fork, not the resource fork. In order to use the picture, you must do one of two things - either transfer the data to a resource of type `PICT'' or set the file type to `PICT''. To set the file type, you can use a utility like ResEdit or MPW SetFile. Moving the data to the resource fork is a bit more complicated and requires the use of a resource compiler such as MPW Rez. Fortunately, most programs will read PICT information from the data fork as long as the file type is set to `PICT''.
The HOOPS HPGL Driver has been verified on various host computers running Solaris, AIX, IRIX, HP-UX, Linux, and Windows, driving the HP750C. In theory, it should run from any other computer system driving HPGL-compatible plotters such as the HP 7440A, HP 7550A, 7470, 7475, 7580, 7585, and 7586. HOOPS has also been tested using E-size plots on an ENCAD SP2800 plotter.
The basic steps to plotting with HOOPS include:
1. Set the HOOPS picture
2. Determine the plotter area size
3. Set the HOOPS physical size option to match the plotter area size (and any other options desired)
Each of these steps is covered in more detail in the remaining sections of this section. The section ends with a section on known restrictions.
The HOOPS HPGL driver writes HPGL graphics commands to a user specified file on all systems. On some systems, it can write these same commands directly to the plotter if the device name is specified instead of a file name. (See Notes to MS-DOS Users that follow.)
There are two ways to use the HPGL driver from HOOPS. One method is to set the HOOPS_PICTURE variable, and the other is to set the HOOPS_HARDCOPY variable.
The simplest method is to direct the graphics output to the plotting device in place of the video screen. The advantage of this method is that the software being used does not have to be modified or recompiled. The disadvantage is that the plotter cannot respond to request for keyboard or mouse input.
To set your computer up so that the HPGL driver is the default HOOPS driver for your graphics programs, you define the environment variable HOOPS_PICTURE to be "hpgl/<file-name>".
For example, on a machine running MS-DOS, type:
set HOOPS_PICTURE=hpgl/hoops.hp
Where hoops.hp is the actual name of the file that captures the HPGL output. Please see the release notes for your particular operating system for details on how to define environment variables. Once this definition is made, HOOPS programs that refer to the HOOPS "?Picture" segment will write a new page to a file named "hoops.hp" each time they update the display.
Any valid file name can be substituted for "hoops.hp"; however, if the name contains HOOPS special characters, you should add extra quote marks as described in the system notes. (In addition, valid file names that end with ".ljp" or ".232" have special meanings - see the Known Restrictions section.) For example, to send the output to a file in another directory on a UNIX machine, you might type:
setenv HOOPS_PICTURE "hpgl/'/usr/usha/hoops.ljp'"
The extra quotes keep the file system "/" marks from being interpreted as HOOPS segment delimiters. Either single or double quotes will work.
The other method of obtaining plotter output lets you display your graphics on the screen and also send the same picture to an HPGL file; however, to do this you have to add some more code.
First specify HOOPS_PICTURE as you would normally, and then define another environment variable, HOOPS_HARDCOPY, as "hpgl/hoops.hp". From within your program use the segment alias "?Hardcopy" to refer to the plotter, and of course the segment alias "?Picture" to refer to the screen device.
To send a single snapshot of your "?Picture" scene to an HPGL file, a typical code sequence would be:
Open_Segment ("?Hardcopy")
Include_Segment ("?Picture")
Update_Display ()
Close_Segment ()
Delete_Segment ("?Hardcopy")
Note that HOOPS will open a new file each time this sequence is called. On certain systems such as MS-DOS and UNIX, opening a new file means the previous version is overwritten.
To obtain an HPGL file with each image on a new page, set things up as:
Open_Segment ("?Hardcopy")
Include_Segment ("?Picture")
Set_Visibility ("off")
Close_Segment ()
To take a snapshot as your program is running along, do:
Open_Segment ("?Hardcopy");
Set_Visibility ("on")
Close_Segment ()
Update_Display ()
Open_Segment ("?Hardcopy");
Set_Visibility ("off")
Close_Segment ()
Finally, delete "?Hardcopy" when done to properly close the file.
Delete_Segment ("?Hardcopy")
Using the "?Hardcopy" variable in the manner above is equivalent to using "?driver/hpgl/hoops.hp" as the segment name. To write to multiple hardcopy files, use segment names such as "?driver/hpgl/hoops1.hp", "?driver/hpgl/hoops2.hp", etc.
Please consult your system documentation on how to send a file to a device. On VMS, you might use the copy command. For example, to send an HPGL file called "fred.hp" to the plotter at TXA2:, you would type:
$copy fred.hp TXA2:
Be sure that the system manager has installed the plotter correctly (i.e. baud rate, hand-shaking, etc. is set correctly for your computer.)
The original version of the HOOPS HPGL driver required the user to select from 4 predefined plotter paper sizes and plot only to those sizes. All available paper sizes were not supported. The driver no longer carries that restriction.
All HPGL-compatible plotters use built-in plotter points P1 and P2. P1 is located in the lower left corner of the plotting area, and P2 is in the upper right. When necessary, HOOPS plots between these two points so that predefined plotter paper sizes are no longer hard-coded into the driver. This approach allows all available plotter paper sizes to be supported but requires that the user set points P1 and P2 (if necessary) and supplies HOOPS with the proper plotter area dimensions (in centimeters).
Since the HOOPS HPGL driver can scale its output between built-in plotter points P1 and P2, P1 and P2 must be set at the plotting area boundaries. On most plotters, these points are automatically set when a page size is selected. If this is not the case, or if a nonstandard page size is desired, refer to your plotter manual for setting points P1 and P2.
Once P1 and P2 are set, the simplest means of determining the distance between the points is to select the desired paper size on the plotter and use the pen-down key on the plotter to mark dots at P1 and P2. You can then use a ruler to measure the horizontal and vertical distances between the two points.
A second method of determining the plotting area size for a given paper size is to run any HOOPS program (with window frame on) and then measure the size of the borders (in centimeters). You can do this without specifying any physical size to HOOPS. (See next section.) With no physical size specified, it is unlikely that the aspect ratio or text size will be correct; however, the border will correctly circumscribe the available plotting area.
After the plotting area dimensions are obtained, you need to make them known to HOOPS. You do this with the HOOPS driver option.
"physical size=(width,height)".
It is important that the width and height values be accurate or the aspect ratio of plots will not be correct. It is also important that they be specified in centimeters (not inches) so that text appears at the correct size in the output. The size values are always specified as portrait (e.g. 8.5" * 2.54 by 11" * 2.54) since most people think of paper sizes (e.g. 8.5 by 11) in this fashion. HOOPS makes the translation from portrait to landscape when a landscape orientation is used.
By default, the HOOPS HPGL driver uses a physical size that corresponds to the plotting area for an 8.5 x 11 inch paper on the HP7440A (25 cm by 18 cm) -yours will very likely be different. In this case, width is larger (e.g., 25) than height (e.g., 18) since a landscape orientation (the default) is being used.
For example, to use the plotting area for C size paper on an ENCAD SP2800, the following applies. C size paper is 17 by 22 inches which equals 43.18 by 55.88 centimeters. On an ENCAD SP2800, the actual plotting area for a C size setting is 37.2 by 47.7 centimeters. The plotting area size is smaller than the paper size due to the margins. From within your program:
Open_Segment ("?Hardcopy")
Set_Driver_Options ("physical size=(37.2,47.7)")
You can specify different paper sizes using the HOOPS environment variable HOOPS_HARDCOPY_OPTIONS to avoid hard coding the paper size in your program.
For example, to use type A4 paper, type:
set HOOPS_HARDCOPY_OPTIONS=physical size:(15,21.8)
Note that you need to use the colon ":" instead of the equal sign as specified by Set_Driver_Options since MS-DOS will not accept an equal sign in an environment variable. From inside your program, use "=" as usual.
set HOOPS_HARDCOPY_OPTIONS=physical size=(15,21.8)
Please refer to the Set_Driver_Options entry in the HOOPS Reference Manual for additional information. Also please consult your plotter operating manual for how to configure the plotter for different paper types.
You can use the driver option "landscape orientation" if you want the width of the page to be greater than the height. This is the default. Otherwise, you use "no landscape orientation" to obtain portrait orientation.Regardless of the paper orientation, the paper should always be loaded into the plotter with the smaller side feeding in first.
To adjust pen speed for different carousel type or different plotting medium, use the driver option "pen speed=fff" where "fff" is the fraction of the maximum speed. Slowing down the pen's speed can produce slightly denser lines. The default value for pen speed is 1.0 which is the maximum speed (80 cm/s). Please consult your plotter operating manual for the optimal pen speed to use with a particular pen type and plotting medium.
There is one rendering option that should be set when creating HPGL plots with the painters hidden surface removal algorithm. In this case, Painter's Panelling should be disabled with:
Set_Rendering_Options( "debug = 8")
The debug driver option can be used in the following manner.
HC_Set_Driver_Options ("locater transform = -M, -N, 0, 0, 0, 0");
set HOOPS_HARDCOPY_OPTIONS=debug:8,write mask:402
The four parameters of the IW (clipping) instruction specify the X and Y coordinates of any two diagonally opposite corners of the window area. The setting of the front panel STANDARD or ENHANCED function key determines how the coordinates are interpreted as follows:
STANDARD - The coordinates are interpreted as plotter units, regardless of whether or not scaling is in effect.
ENHANCED - If scaling is not active at the time the window is defined, the coordinates are interpreted as plotter units. If scaling is active at the time the coordinates are interpreted as user units.
Normally HOOPS assumes a STANDARD setup; You can set debug to 32 for devices that support enhanced mode:
set HOOPS_HARDCOPY_OPTIONS=debug:32
Setting the output file name suffix can affect a change in the expected pen set:
Pen Number | Expected Color |
1 | black |
2 | blue |
3 | green |
4 | cyan |
5 | red |
6 | magenta |
7 | yellow |
8 | digitizing sight |
HOOPS will map up to 256 colors defined by the application program onto these 8 colors as best it can. White geometry is mapped to black since windows are white by convention.
Pen Number | Expected Color |
0 | white |
1 | black |
2 | red |
3 | green |
4 | yellow |
5 | blue |
6 | magenta |
7 | cyan |
HOOPS will map up to 256 colors defined by the application program onto these 8 colors as best it can.
setenv HOOPS_HARDCOPY_OPTIONS
title='ESC.(ESC.@:ESC.M:ESC.I80;0;17:ESC.N0;19:'
Works on an HP 7220A plotter connected to a Unix system. The HPGL driver translates the "ESC" character sequence to \033. The plotter setup string may be up to 80 characters long.
Starbase is the software interface to most of the HP Starbase hardware graphics accelerators. Starbase does not render graphics on a raw workstation screen but requires a windowing system to manage some of the drawing operations sent to the graphics device. To use HOOPS with Starbase, you must use the HOOPS SBX (StarBase on top of X11) driver 'libsbx.hdi[version].so', and you must run under X11 which means that you must have installed the X11 driver.
The SBX driver has been verified on an HP 9000/710, 712, 720, and 730 workstations running HP-UX versions 9.05. The HOOPS SBX driver provides access through Starbase to the full capabilities of the Starbase hardware graphics accelerator while maintaining an X11 screen appearance. It has been tested with and without PowerShade software; however, use of the SBX driver without 3D hardware nor PowerShade software is not recommended. For those cases, the X11 driver is faster.
The HOOPS SBX driver has been optimized to support the integrated
710, integrated 712, integrated 715, integrated 725, CRX, HCRX-8, CRX-24,
HCRX-24, HCRX-8Z, CRX-24Z, HCRX-24Z, and CRX-48Z.
Before running the SBX driver on various HP devices, there are several issues to consider: How is the graphics hardware initialized to the system? Can the device color map be shared to avoid screen flashing? Can the device double-buffer? Will PowerShade improve a device's performance?
Both the HOOPS SBX and X11 Display Drivers support HP hardware graphics devices. The HP 9000/700 series systems have been tested with and without PowerShade software.
device | with PowerShade | without PowerShade |
integrated 710 | use SBX | use X11 |
integrated 712 | use SBX | use X11 |
integrated 715 | use SBX | use X11 |
integrated 725 | use SBX | use X11 |
CRX | use SBX | use X11 |
HCRX-8 | use SBX | use X11 |
CRX-24 | use SBX | use X11 |
HCRX-24 | use SBX | use X11 |
HCRX-8Z | use SBX | use SBX |
CRX-24Z | use SBX | use SBX |
HCRX-24Z | use SBX | use SBX |
CRX-48Z | use SBX | use SBX |
Visualize-8/24 | use SBX | use SBX |
Visualize-FX2/FX4/FX6 | use OGL | use OGL |
Since Starbase is the software interface to the advanced graphics capabilities of hardware graphics accelerators, the HOOPS SBX Display Driver offers the greatest access to the enhanced graphics capabilities provided by the hardware graphics accelerators; however, using the SBX Driver without neither 3D hardware nor PowerShade assistance actually renders slower than using the X11 driver. On the other hand, with hardware or PowerShade, 3D performance is greatly improved by using SBX.
The Visualize-8/24 systems will run OpenGL in a software rasterization mode, so Starbase is still the optimal solution.
The Visualize FX systems run both OpenGL and Starbase; however, OpenGL is the more optimal path (and is recommended by HP), hence the HOOPS OpenGL driver should be used on the FX systems. See the OpenGL driver notes for more information.
Device : Integrated 705
X0screens : /dev/crt
SB_X_SHARED_CMAP : set to TRUE
Xconfig / Xsession : set as indicated
HP_VM_DOUBLE_BUFFER : set to TRUE
PowerShade : adds entry level shading
Device : Integrated 710
X0screens : /dev/crt
SB_X_SHARED_CMAP : set to TRUE
Xconfig / Xsession : set as indicated
HP_VM_DOUBLE_BUFFER : set to TRUE
PowerShade : adds entry level shading
Device : Integrated 712
X0screens : /dev/crt
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : not applicable
HP_VM_DOUBLE_BUFFER : set to TRUE
PowerShade : adds entry level shading
Device : Integrated 715
X0screens : /dev/crt
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : not applicable
HP_VM_DOUBLE_BUFFER : set to TRUE
PowerShade : adds entry level shading
Device : Integrated 725
X0screens : /dev/crt
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : Not Applicable
HP_VM_DOUBLE_BUFFER : Not Applicable
PowerShade : adds entry level shading
Device : CRX
X0screens : /dev/crt
SB_X_SHARED_CMAP : set to TRUE
Xconfig / Xsession : Set as indicated
HP_VM_DOUBLE_BUFFER : Not Applicable
PowerShade : adds dynamic shading
Device : HCRX-8
X0screens : /dev/crt_hyper depth 8
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : Not Applicable
HP_VM_DOUBLE_BUFFER : Not Applicable
PowerShade : adds dynamic shading
Device : CRX-24
X0screens : /dev/crt
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : Not Applicable
HP_VM_DOUBLE_BUFFER : Not Applicable
PowerShade : adds dynamic shading
Device : HCRX-24
X0screens : /dev/crt_hyper
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : Not Applicable
HP_VM_DOUBLE_BUFFER : Not Applicable
PowerShade : adds dynamic shading
Device : HCRX-8Z
X0screens : /dev/crt_hyper depth 8
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : Not Applicable
HP_VM_DOUBLE_BUFFER : Not Applicable
PowerShade : bundled
Device : CRX-24Z
X0screens : /dev/crt
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : Not Applicable
HP_VM_DOUBLE_BUFFER : Not Applicable
PowerShade : bundled
Device : HCRX-24Z
X0screens : /dev/crt_hyper
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : Not Applicable
HP_VM_DOUBLE_BUFFER : Not Applicable
PowerShade : bundled
Device : CRX-48Z
X0screens : /dev/crt
SB_X_SHARED_CMAP : Not Applicable
Xconfig / Xsession : Not Applicable
HP_VM_DOUBLE_BUFFER : Not Applicable
PowerShade : bundled
First of all, X11 must be running to use the SBX driver. The graphics device should have been started with the X11 server screen depth correctly set for the HP Starbase graphics hardware on your workstation. This information is contained in:
/usr/lib/X11/X0screens.
The line selectable (i.e. uncommented) from the X0screens file must include
specify the IMAGE planes. Other lines, i.e. other modes such as STACKED_SCREEN
and OVERLAY (X11 writes to the overlay planes, not Starbase), are not supported.
For older 8 bit color devices, there are two files of interest. Users of the HP Visual User Environment window manager should add a line at the end of file "/usr/vue/config/Xconfig" that reads:
Vuelogin*environment: SB_X_SHARED_CMAP=true
For users of other window managers (e.g. Motif), the environment variable:
setenv SB_X_SHARED_CMAP true
should be set (e.g. in .profile) so that sharing is requested before the window manager is activated.
As the name suggests, "shared cmap" allows the color map to be shared between X11 and Starbase so that windows do not go technicolor when the mouse is moved among them. The second file of interest to avoid technicolor windows is:
/usr/vue/config/Xsession
The color map initialization (around line 170) should be commented out:
#/usr/bin/X11/xinitcolormap
If this is not done, the X11-only color map is loaded instead of one that can be shared by X11 and SBX. The Xconfig and Xsession files must be set for low-cost integrated and CRX graphics devices.
The HP 705, HP 710, HP 712, and HP 715 (with their respective integrated graphics boards) require special processing to enable double buffering. By default, double buffering is not available on these devices. It is only available by enabling HP software via an appropriate HP environment variable.
setenv HP_VM_DOUBLE_BUFFER true
Note: If you are running on an early version of HP-UX 9.05, there are patches related to double buffering that you may need to apply.
PowerShade software is not required to use HOOPS on an HP device; however, testing at Tech Soft 3D showed that use of PowerShade improves a device's performance. In fact, the HOOPS X11 driver is actually faster than the HOOPS Starbase driver for devices that lack 3D graphics hardware and lack PowerShade software. The HCRX-8Z, CRX-24Z, HCRX-24Z, and CRX-48Z are bundled with PowerShade.
The SBX driver is layered on top of the regular X11 driver, so the driver segment names look similar. The SBX driver uses the regular X11 driver to perform all the window management tasks and uses Starbase only for drawing into the X11 window. To set up your environment so that the SBX driver is the default HOOPS driver you must define the environment variable "HOOPS_PICTURE." To do this, insert the following line in your ".cshrc" or ".login" file:
setenv HOOPS_PICTURE "SBX/unix:0.0"
Once this definition is made, all programs that refer to the HOOPS "?Picture" segment will open an X11 server window and then open Starbase within that X11 window.
If you need to open the SBX driver explicitly (because some other device is already the "picture" device) insert a call (or calls) to Open_Segment inside your program similar to the following statement:
Open_Segment ("?driver/SBX/unix:0.0")
If you need to open more than one HOOPS SBX window from the same program at the same time, use secondary segment names that look like "unix:0.0+A", "unix:0.0+B", etc. as you open the segments.
Unlike the X11 driver, the starbase driver does not across unix workstations. If you have more than one X11 screen on your workstation, substitute "SBX/unix:0.n" for "SBX/unix:0.0", where n is the number of the X11 screen you wish to use. Note: The SBX driver does not know how to be directed via the X11 screen number to the overlay planes. The regular X11 driver can be run in the overlay planes.
Since the SBX driver is layered on top of the X11 driver and X11 is a windowing system, some driver options that affect the behavior of windows in a windowing system may be of interest to you. Please see the "Special Driver Options" section of the X11 driver section regarding any driver options that affect the behavior of windows in a windowing system.
The SBX driver supports double-buffering to make animation appear smoother. This option is "off" by default. You can turn this feature "on" by specifying it in the "HOOPS_PICTURE_OPTIONS" environment variable:
setenv HOOPS_PICTURE_OPTIONS "double-buffering"
or you can turn this feature on from inside your HOOPS program(s) by using the Set_Driver_Options function. For integrated devices, the HP_VM_DOUBLE_BUFFER environment variable is required.
The debug driver option can be used to print out a list of hardware and software capabilities present on the machine. This list of capabilities is most useful when reporting HOOPS SBX driver problems.
setenv HOOPS_PICTURE_OPTIONS "debug=1"
Another debug option pertains to gamma correction. The SBX driver will attempt to honor a request to provide gamma correction if the hardware can provide it. There are instances, e.g. depending on the X11 visual being used, where the hardware will not provide this capability. In such a case, the SBX driver will allow HOOPS to provide the gamma correction. Although this brightens up scenes to make them more consistent with other HOOPS drivers, the results are not totally accurate, since gamma correction is being provided before lighting instead of after. Hence, it is likely that most user programs need do nothing related to gamma correction; however, in the event that there is a hardware device that says it can do gamma correction, but it really cannot, you can force the SBX driver to execute under the conditions where HOOPS provides the gamma correction by setting debug=4096.
setenv HOOPS_PICTURE_OPTIONS "debug=4096"
The SBX driver does its best to avoid issuing commands to 3D hardware (or PowerShade software) unless they are necessary. In cases where HOOPS is used optimally, i.e. attributes, options, and heuristics are set as high in a HOOPS tree as possible, applications need do nothing to attain optimal Starbase performance; however, for applications that use HOOPS in a less than optimal fashion, the application can activate a debug bit, debug=8192, which causes the Starbase driver to save and check more data than normal, but which could result in a more optimal Starbase performance.
setenv HOOPS_PICTURE_OPTIONS "debug=8192"
Another special consideration is color map sharing. Colormap sharing is provided by HP through the SB_X_SHARED_CMAP environment variable. As such, using the HOOPS use colormap ID driver option is not recommended. When encountered, the Starbase driver issues a warning. In the event that a colormap must be supplied to the HOOPS Starbase driver, entries 0 through 39 (inclusive) are for the window manager and 40 through 255 (inclusive) must contain a 6|6|6 color ramp for Starbase.
Please refer to the X11 driver section for other special driver options.
In addition to its own stroked font, HOOPS supports three additional generic font families: Sans Serif, Typewriter, and Roman. These font families are considered generic in that they are mapped to the closest corresponding fonts on each HOOPS platform. Starbase does not support use of X11 fonts. As such, the fonts used by the SBX driver are Adobe fonts - the same fonts used on the PC platform. Like the PC, the HP-UX version of HOOPS maps Sans Serif to Adobe Helvetica, Typewriter to Adobe Courier, and Roman to Adobe Times Roman. Six pixel sizes are available for each of the fonts. See the HOOPS/3dGS Reference Manual for more font information.
Use of the Adobe fonts requires that the following notice be included in this documentation. This notice applies solely to the Adobe font files and is not applicable to the HOOPS program files.
Copyright 1984, 1987 Adobe Systems, Inc. Portions Copyright 1988 Digital Equipment Corporation
Adobe is a registered trademark of Adobe Systems, Inc. Permission to use these trademarks is hereby granted only in association with the images described in this file.
Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notices appear in all copies and that both those copyright notices and this permission notice appear in supporting documentation, and that the names of Adobe Systems and Digital Equipment Corporation not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Adobe Systems and Digital Equipment Corporation make no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
The extension for HOOPS font files is ".HFF." The HOOPS installation script places these fonts in /usr/lib/hoops. If you wish to move these fonts, the environment variable HOOPS_FONT_DIR must identify the directory containing the font files. For example:
setenv HOOPS_FONT_DIR /home/rob/hoops/font
This is NOT the same as the HOOPS_FONT_DIRECTORY environment variable that is used for Postscript printer files and Kanji stroked font files. HOOPS_FONT_DIR tells the Starbase driver where to find its bitmap text fonts. HOOPS_FONT_DIRECTORY tells HOOPS where it can find font engine, kanji, and other Postscript printer fonts. By having two different environment variables, it is possible to use bitmapped text with Starbase while avoiding any use of the HOOPS font engine.
Please see the "Known Restrictions" section of the X11 driver section for any X11 driver restrictions. Those restrictions related to window management also affect the SBX driver. In addition, the backplane cull heuristic is only implemented for polygons. HOOPS shells and meshes get rendered in the SBX driver using the Starbase tristrip primitive. Due to a mismatch between Starbase culling and HOOPS culling, culling is not activated when drawing with the tristrip primitive.
XGL is the software interface to most of the Sun hardware graphics accelerators. It implicitly uses whatever hardware graphics acceleration is available on your Sun workstation. In particular, it uses Sun's Direct Graphics Access technology to achieve high performance graphics when an XGL application is running locally.
XGL does not render graphics on a raw screen but requires a windowing system to manage some of the drawing operations sent to the graphics device. To use HOOPS with the XGL Driver, you must run under X11 (OpenWindows) which is why the X11 driver is included in the installation.
The XGL Driver has been verified on the Creator3D, ZX, GS, GXplus, and GX Sun hardware graphics accelerators. To see what hardware graphics capabilities the XGL Driver will access, see the "XGL Driver Use of Hardware Graphics Capabilities" in the "Installation on Sun Systems" section.
First of all, for the XGL Driver to work, X11 (OpenWindows) must be running. The XGL Driver is layered on top of the regular X11 Driver so the driver segment names look similar. The XGL Driver uses the regular X11 Driver to perform all the window management tasks and uses XGL only for drawing into the window. To set up your environment so that the XGL Driver is the default HOOPS driver you must define the environment variable "HOOPS_PICTURE". To do this, insert the following line in your ".cshrc" or ".login" file:
setenv HOOPS_PICTURE "XGL/unix:0.0"
Once this definition is made, all programs that refer to the HOOPS "?Picture" segment will open an X11 (OpenWindows) server window and then open XGL within that window.
If you need to open the XGL Driver explicitly (because some other device is already the "picture" device), insert a call (or calls) to Open_Segment inside your program similar to the following statement:
Open_Segment ("?driver/XGL/unix:0.0")
If you need to open more than one HOOPS XGL window from the same program at the same time, use secondary segment names that look like "unix:0.0+A", "unix:0.0+B", etc., as you open the segments.
If you have more than one X11 server on your machine, substitute "XGL/unix:n.0" for "XGL/unix:0.0", where n is the number of the X11 server you wish to use. If you have more than one X11 screen on your workstation, substitute "XGL/unix:0.n" for "XGL/unix:0.0", where n is the number of the X11 screen you wish to use.
Please read the "Note to XGL Users" section in the "Installation on Sun
Systems" section to make sure that you have defined the necessary environment
variables for running programs with XGL.
Since the XGL Driver is layered on top of the X11 Driver, and X11 is a windowing system, some driver options that affect the behavior of windows in a windowing system may be of interest to you. Please see the "Special Driver Options" section of the X11 Driver section regarding any driver options that affect the behavior of windows in a windowing system.
XGL Device Information
Setting the debug driver option to debug=7 causes the XGL driver to print out all of the relevant information about the XGL device. Before you demonstrate a bug by submitting a small test program to Technical Support, be sure to have this information handy. Whenever sending in a bug report, please include this information. The driver has many twisty paths, all alike, and this information goes a long way in helping us solve your problem. This debug option must be set before the first update.
setenv HOOPS_DRIVER_OPTIONS "debug = 0x00007"
Double Buffering
The XGL Driver supports double-buffering to make animation appear smoother. The double-buffering feature is implemented to take advantage of any support for this feature that a hardware graphics accelerator may have on your workstation. This option is "off" by default; you can turn this feature "on" by specifying it in the "HOOPS_PICTURE_OPTIONS" environment variable:
setenv HOOPS_PICTURE_OPTIONS "double-buffering"
or you can turn this feature on from inside your HOOPS program(s) by using the Set_Driver_Options function.
Please refer to the X11 Driver section for other special driver options.
Marker Drawing Issues
The default in the XGL driver is to use XGL markers, which are much faster to draw than drawing then as a polylines, ellipses and faces; however, in certain cases on certain framebuffers, the XGL marker may not show up correctly. For example, individually colored point markers may not show up. The work around is to use slower HOOPS marker set, where HOOPS draws each marker as a point, polyline, ellipse or face. To activate HOOPS markers, specify the debug bit in the "HOOPS_DRIVER_OPTIONS" environment variable:
setenv HOOPS_DRIVER_OPTIONS "debug = 0x10000"
Text Font Names
There are a number of text fonts available for use when you are running HOOPS with the XGL Driver. Set_Text_Font provides you with some "generic" HOOPS font names: "roman", "sans serif", "typewriter", "stroked", and "system default". If one of these "generic" font names is specified as the font to use for HOOPS text, HOOPS will look through the selection of XGL stroked fonts that are available through XGL on your workstation and try to pick one that is of the appropriate style.
Alternatively, you can tell Set_Text_Font to use a specific XGL stroked font. The XGL stroked fonts available on your workstation are located in the directory:
$XGLHOME/lib/xglfonts/stroke
Please read the "Note to XGL Users" section in the "Installation on Sun Systems" section for instructions on how to define the "XGLHOME" environment variable.
The XGL Driver also provides full access to the full range of individual X11 fonts available through the X11 server on your workstation by calling the X11 Driver to draw the text for these X11 fonts. This is achieved by specifying a debug flag in the "HOOPS_DRIVER_OPTIONS" environment variable:
setenv HOOPS_DRIVER_OPTIONS "debug = 0x30000"
or you can turn this feature on from inside your HOOPS program(s) by using the Set_Driver_Options function.
Please refer to the "Specifically-Named Fonts" section of the X11 Driver section for information on how to use specific-named X11 fonts. Please note that drawing text with an XGL stroked font is much faster than drawing text with X11 fonts because the XGL Driver has access through XGL to the graphics acceleration capabilities provided by whatever Sun hardware graphics accelerator is on your Sun workstation.
Certain system font families do not provide HOOPS with correct font metric information. This results in HOOPS error messages. For example, courier, is not correct. The problem has been reported to Sun.
Window Title
Once the XGl driver is up and running in an X11 window, the title cannot be changed with the title driver option. The problem has been reported to Sun.
Concave Polygons
XGL does not support concave polygons. Therefore if the XGL driver detects that the HOOPS heuristic "concave polygons" has been set, the driver is forced to triangulate all polygons and then draw the triangles. There is a significant performance penalty for this method of rendering. The HOOPS default is "no concave polygons." Please do not set the "concave polygons" heuristic and then supply concave polygons to the XGL driver unless absolutely necessary.
Solaris Security and Accessing Direct Graphics Access (DGA):
There is a security feature in Solaris that governs frame buffer access for processes started by anyone other than the first user of the window system. As a result, non-owners of the window system do not have access to DGA.
For example, if a user starts the windowing system and then another user sits at the workstation, changes to his own environment using su, and starts an XGL application, the application will not run via DGA even though the second user is running the application locally.
To give all local users access to DGA:
1. Change directory to /etc.
2. Edit the permissions in the file logindevperm to 0666 as shown in the lines below:
/dev/console 0666 /dev/mouse; /dev/kbd /dev/console 0666 /dev/sound/* # audio devices /dev/console 0666 /dev/fbs/* # frame buffers
3. Reboot.
Direct Xlib
Direct Xlib transparently enhances graphics-rendering performance for graphics intensive Xlib applications by utilizing the DGA Drawable Interface. Performance improvement is dependent upon an application's use and mix of graphics primitives. Programs that are not graphics intensive may not see a performance gain at all. Direct Xlib software accelerates rendering on the following devices: GX, GXplus, TurboGXplus, and SX.
A typical Solaris 2.4 "End User" installation will not install Direct Xlib, so you'll have to explicitly select it before installing your OS. If can also be installed later on by using "pkgadd." Please see Sun option package installation notes or contact your system administrator about installing Direct Xlib.
To run Direct Xlib on an application-by-application basis (assuming Direct Xlib is in the default installation location, and the application is dynamically linked to libX11), type:
% /opt/SUNdxlib/bin/dxlib 'myprog'
where 'mpprog' is the name of the application. The program name may be followed with the usual command line arguments, if any. Direct Xlib activated in this manner is only active for the single application started with the dxlib script. The dxlib script must be executed with each application you want to use with Direct Xlib. For more information on Direct Xlib please see Solaris Direct Xlib Users's Guide. The performance improvements will vary from primitive to primitive, and in some cases the performance of some primitives may even decrease (such as font rendering).
Running the HOOPS demo program perftest.c showed an increase in performance of 8% for markers and up to 70% for images.
Note: Direct Xlib 3.1 is only available under Solaris. Direct Xlib 2.0 is available under Solaris 2.5 as well; however, have not done any testing on that particular version. Also Direct Xlib does not work well with HOOPS on the ZX card. Installing and using Direct Xlib will not affect your normal XGL lib performance in any way.
Please see the "Known Restrictions" section of the X11 Driver section for any X11 Driver restrictions. These may affect the XGL Driver.
NOTE: The GL Driver is no longer compiled within the HOOPS libraries.
To use this driver, the shared object (libglhdi.so) must be compiled and
linked separately.
The GL Driver requires the host platform to have a frame buffer that supports
RGBmode, a depth buffer, and either popup or overlay planes.
First of all, for the GL Driver to work, X11 must be running. The GL Driver is layered on top of the regular X11 Driver so the driver segment names look similar. The HOOPS GL Driver uses the regular X11 Driver to perform all the window management tasks including input and uses GL only for drawing into the window. To set up your environment so that the GL Driver is the default HOOPS driver you must define the environment variable HOOPS_PICTURE. To do this insert the following line in your .cshrc or .login file:
setenv HOOPS_PICTURE "gl/unix:0.0"
Once this definition is made, all programs that refer to the HOOPS "?Picture" segment will display in a window on the local Iris workstation.
Note that the unix:0.0 specification is used by HOOPS to direct the GL window to a specific display. This feature operates only on hardware that supports the Distributed GL through X11. On platforms without this extension, the redirection will be ignored and the HOOPS picture will appear on the host's display.
Once this definition is made, all programs that refer to the HOOPS "?Picture" segment will open an X11 server window on the local workstation and then open GL within that window.
If you need to open the GL Driver explicitly (because some other device is already the "?Picture" device), insert a call (or calls) to Open_Segment in your program similar to the following statement:
Open_Segment ("?driver/GL/unix:0.0")
If you need to open more than one HOOPS GL window from the same program at the same time, use secondary segment names that look like display+bar, display+baz, etc., as you open the segments.
Open_Segment ("?driver/gl/unix:0.0+foo")
Since the GL Driver is layered on top of the X11 Driver and X11 is a windowing
system, some driver options that affect the behavior of windows in a windowing
system may be of interest to you. Please see the "Special Driver Options"
section of the X11 Driver section regarding any driver options that affect
the behavior of windows in a windowing system. Please refer to the X11 Driver
section for other special driver options.
Double Buffering
The GL Driver supports double-buffering to make animation appear smoother. This option is "off" by default; you can turn this feature "on" by specifying it in the HOOPS_PICTURE_OPTIONS environment variable:
setenv HOOPS_PICTURE_OPTIONS "double-buffering"
or you can turn this feature on from inside your HOOPS program(s) by using the Set_Driver_Options function.
Use Window ID
You can create an X11 window and pass the id, or create a HOOPS Motif widget as discussed in the X11 section and demonstrated in the demo/motif/simple application.
Debug
There are two debug options: "debug = 1" will turn on device description when a GL driver is first instantiated, "debug = 2" will disable z buffer clearing upon startup.
Setting debug=1 prints out all of the relevant information about the GL device. Before you demonstrate a bug by submitting a small test program to Technical Support, be sure to have this information handy. Whenever sending in a bug report, please include thisinformationn. The driver has many twisty paths, all alike, and this information goes a long way in helping us solve your problem. This debug option must be set before the first update.
Setting debug=2 is only useful when an initial clear of the Z buffer should be avoided. This is typically the case for applications that are only using HOOPS for 2D rendering.
Gamma Correction
By setting the HOOPS driver option no gamma correction, you can disable the gamma-correction that HOOPS would otherwise perform. The use of this driver option assumes that the user will perform any necessary correction external to the running HOOPS program.
The Set_Text_Font routine may be used to set font characteristics from within a HOOPS program. You may also control them externally by setting the environment variable "HOOPS_TEXT_FONT". For example:
setenv HOOPS_TEXT_FONT "name=Courier,size=12pt"
will set the default font to be 12-point Courier for subsequent executions
of the program.
The GL Driver uses X11 fonts available through the X11 server on your IBM workstation. Set_Text_Font provides you with some "generic" built-in HOOPS font names: "roman", "san serif", "typewriter", "stroked", and "system default". If one of these "generic" font names is specified as the font to use for HOOPS text, HOOPS will look through the selection of X11 fonts that are available to the X11 server on your IBM workstation and try to pick one that is of the appropriate style and appropriate size.
The GL Driver provides access to the full range of individual X11 fonts that are available through the X11 server on your IBM workstation. Please refer to the "Specifically-Named Fonts" section of the X11 Driver section for information on how to use specific-named X11 fonts.