void draw_3d_polygon (
    HT_Rendition const &       hr,
    HT_Polygon &               polygon
)

polygon->count() and polygon->points() specify an array of vertices that define the polygon, which may have arbitrary complexity. Specifically, the face boundary is a closed, connected polyline. It may enclose a non-convex region, but may not intersect itself.

The polygon is filled with a constant color, determined by the face color attribute in the rendition, possibly overlaid with a pattern given by the face pattern and contrast color attributes.

This routine does not draw a polygon edge distinct from the face color. An application which wants edged polygons must explicitly draw the edge with a call to draw_3d_polyline.

void draw_3d_polyline (
    HT_Rendition const &       hr,
    HT_Polyline const &        polyline // Polyline descriptor
)

polyline->points() points to an array of points giving the polyline vertices in order.
 
 

void draw_3d_polymarker (
    HT_Rendition const & hr,
    HT_Polymarker & polymarker
)

polyline->count() is the number of polymarkers to draw.

polyline->points() points to an array of points giving the polymarker vertices.

void draw_3d_polytriangle (
    HT_Rendition const &       hr,
    HT_Polytriangle &          polytriangle
)

polytriangle->points() points to an array of polytriangle->count() points, forming polytriangle->count()-2 triangles. Each triple of successive points are the vertices of one triangle of the strip.

This routine does not draw a triangle edge distinct from the face color. An application which needs edged polygons must explicitly draw in the edge with a call to draw_3d_polyline.

void draw_3d_shell (
    HT_Rendition const &       hr,
    HT_Shell const &           shell // Shell descriptor
)

shell->points(), if not null, points to an array of HT_Point that contains the vertices referenced in all the triangle strips.

shell->points_d(), if not null, points to an array of HT_Point_D that contains the vertices referenced in all the triangle strips.

shell->strips() gives the number of strips.

shell->lengths() is an array of strip lengths.

shell->set_indices(num_strips, lengths, vertex_indices) defines the sequences of vertices and faces defining the tristrips. The first parameter specifies the number of strips. The second parameter gives an array of integers specifying the number of vertices in each strip. The last parameter gives an array of lists specifying the connectivity of each strip.

int num_strips = 2;
int * lengths[] = {5, 6};
int * connectivities[] = {4, 2, 3, 1, 0, 0, 5, 3, 6, 4, 7};
HT_Point points[] = {v0, v1, v2, v3, v4, v5, v6, v7};
HT_Shell shell(8, points);
shell.set_indices (num_strips, lengths, connectivities);
 
shell.strips() = 2
shell.lengths() = {5, 6}
shell.total_length() = 11

shell->vertex_normals(), if not null, points to a vector normal array. The normal of a particular vertex is indexed by shell->vertex_normal_indices().

shell->vertex_parameters(), if not null, points to texture mapping coordinates associated with vertices. When texture mapping is in effect, it points to an array of HT_Parameter. An HT_Parameter consists of a triplet of floats per vertex, containing the u, v, and w parameters. The interface now allows for "n" triplets of texture vertex parameter data to be associated with each vertex.  The first place this is seen is in the set_vertex_parameters() member function. For more information see HT_Vertex_Set::set_vertex_parameters.  The parameter of a particular vertex is indexed by shell->vertex_parameter_indices().

shell->face_normals(), if not null, points to an array of normal vectors associated with faces. The normal of a particular face is indexed by shell->face_normal_indices(). 

shell->face_colors(), if not null, points to an array of HT_RGB32 colors associated with faces. The color for a particular face is by the indexed by shell->face_color_indices().

For more information see class HT_Shell.
 

void draw_3d_text (HT_Rendition const & hr,
                           HT_Text const & txt) const

This new scheme allows a renderer to replace the text actions and treat text as just another piece of geometry.  For example, a renderer that stores geometry and replays it back later (that is, sorted by position, or multiple times for banded plotting) no longer needs to have special code to deal with text or force tessellation of text into "simple" geometry for storage.

HT_Text is a new class with a different constructor to handle a single or double precision position, and either normal chars, with optional length, or wide chars ¾ unsigned short.

For more information, see draw_2d_text and HT_Font_Engine.
 

void draw_3d_tristrip (
    HT_Rendition const &       hr,
    HT_Tristrip const &        tristrip   // Triangle strip descriptor
)

The tristrip->points() array points to the first of an array of 3D points that contain the vertices of all the triangle strips in the list.

tristrip->connectivity(), if not null, defines the sequences of vertices and faces defining the tristrips. The format of the connectivity list is described in the following steps:

Sample list = { 0,1,3,0,2,1,~4,2,0,5,3,3,6,4,4,5,~7,~6 }

tristrip->vertex_normals(), if not null, points to the beginning of a vector normal array.

tristrip->vertex_parameters(), if not null, points to texture mapping coordinates associated with vertices. When texture mapping is in effect, it points to an array of HT_Parameter. An HT_Parameter consists of a triplet of floats per vertex, containing the u, v, and w parameters. The interface now allows for "n" triplets of texture vertex parameter data to be associated with each vertex of  tristrips.  The first place this is seen is in the set_vertex_parameters() member function. For more information see HT_Vertex_Set::set_vertex_parameters.

tristrip->face_normals(), if not null, points to the first of an array of normal vectors associated with faces.

tristrip->face_colors(), if not null, points to the first of an array of HT_RGB32 colors associated with faces. The color for a particular face has the same index in this array as its normal in tristrip->face_normals().

For more information see class HT_Tristrip.
 

void draw_dc_bitonal_image (
    HT_Rendition const & hr,
    HT_DC_Point const & ul,
    HT_DC_Point const & lr,
    int rb,
    HT_Packed_Bits const * pixels,
    HT_Bitonal_Format const & bitonal_format) const

void draw_dc_bitonal_image (
    HT_Rendition const & hr,
    HT_DCI_Point const & ul,
    HT_DCI_Point const & lr,
    int rb,
    HT_Packed_Bits const * pixels,
    HT_Bitonal_Format const & bitonal_format) const

void draw_dc_depth16_image (
    HT_Rendition const & hr,
    HT_DC_Point const & ul,
    HT_DC_Point const & lr,
    int rb,
    HT_Depth16 const * pixels) 
void draw_dc_depth16_image (
    HT_Rendition const & hr,
    HT_DCI_Point const & ul,
    HT_DCI_Point const & lr,
    int rb,
    HT_Depth16 const * pixels) const 
void draw_dc_depth32_image (
    HT_Rendition const & hr,
    HT_DC_Point const & ul,
    HT_DC_Point const & lr,
    int rb,
    HT_Depth32 const * pixels) const 
void draw_dc_depth32_image (
    HT_Rendition const & hr,
    HT_DCI_Point const & ul,
    HT_DCI_Point const & lr,
    int rb,
    HT_Depth32 const * pixels) const

ul and lr are device coordinates for the corner pixels of the Z-buffer block to be filled.

pixels points to the memory location for the upper left pixel data.

rb is the number of bytes in a row of the memory data.
 
 

void draw_dc_index8_image (
    HT_Rendition const & hr,
    HT_DC_Point const & ul,
    HT_DC_Point const & lr,
    int rb,
    HT_Index8 const * pixels) const 
void draw_dc_index8_image (
    HT_Rendition const & hr,
    HT_DCI_Point const & ul,
    HT_DCI_Point const & lr,
    int rb,
    HT_Index8 const * pixels) const

pixels + n*rb up to n = ul.y - rl.y.

This method applies Z-buffer testing when Z buffering is in effect and the scan is one pixel high. The depth value of each pixel is inferred from the z values of ul and lr interpolating across.

void end_picture (void)

This method is a message from the application to the driver that a sequence of drawing commands has ended.

void end_picture_all (void) alter

int establish ()

int establish_all (void) alter

int establish_configuration (void) alter

int establish_configuration( ) is called from HT_Renderer::establish ( ) after the current option table has been updated in accordance with the configured options as set by the application. The function of establish_configuration is to bring the internal state of the driver into consonance with the options that have been set by the application.

For more information, see the section, "establish_configuration" in chapter 3, "Implementing a New Driver."

HT_Byte const * face_pattern_bits (
    HT_Face_Pattern         pattern) const

The function accepts a face pattern index and returns a pointer to the bitmap.

The format for the bit patterns is an 8x8 monochromatic bitmap stored in eight sequential bytes. They are the bits of the pattern in row-major order (top row first), with the most significant bit of each byte representing the left-most pixel. The bitmap should be tiled across the face you are drawing. For more information see the section "Face Patterns" in chapter 2, "Heidi Architecture."

HT_Renderer    first_child (HT_Position & pos) const

HT_Module_Info   get_module_info ()

HT_Renderer ()

HT_Renderer (HT_Pointer<HT_Renderer_Data> const & in)

HT_Renderer (HT_Renderer_Data const * in)

~HT_Renderer ()

HT_Option_Table const & inherited_option_table() const

HT_Renderer_Options const & inherited_renderer_options() const

short const * line_pattern_lengths (HT_Line_Pattern pattern) const

The first element in the array is a scaling factor for adaptive patterns. It is the total of the lengths of dashes, spaces, dots and so forth in the pattern. This equals 50 in the example following. The second element in the array is a count of spans. This is followed by a set of numbers terminated by -1. The driver should alternate drawing styles for the percentage of pixels given by each successive span number. For the first number in the pair, draw the face color. For the next number in the pair, draw nothing if the pattern mode is Hollow or draw the contrast color if the pattern mode is Filled. Then, alternate with another pair. When the end of the span array has been reached, you should start again at the beginning of the array.

For example the span array for dash_dot looks like this:

dash_dot[] = {50, 4,     26, 12, 0, 12,                 -1}

pattern_scale = dc->requirements().m_pattern_scale;

where dc is a pointer to a HT_Renderer or HT_Device.

The HT_Device_Requirements method m_pattern_scale represents 100% of a normal line pattern for video desplays. This defaults to 50 pixels. For hardcopy devices, it is recommended that the pattern_scale device requirements be set to a number of pixels corresponding to 1/2 inch.

The span value is then multiplied by another line scale parameter, line_pattern_scale, which is set at the rendition.
 

HT_Renderer next_child (HT_Position & pos) const

int number_of_children () const

HT_Renderer const & operator= (HT_Renderer_Data * input) alter {
    m_data = input;
    return *this;
}

HT_Renderer const & operator= (HT_Renderer const & input) alter {
    m_data = input.m_data;
    return *this;
}

HT_Boolean operator== (void * test) {return m_data == test;}

HT_Boolean operator== (HT_Renderer const & other) const {
    return m_data == other.m_data;
}

HT_Boolean operator!= (void * test) {return m_data != test;}

HT_Boolean operator!= (HT_Renderer const & other) const {
    return m_data != other.m_data;
}

HT_Renderer parent (void) const

HT_Option_Table & query_user_configuration (void)

We caution using this function because Heidi applications have to be prepared for the driver's response. For example, the driver may bring up a separate window which obscures part of the application window. In other words, the effect is driver dependent and may not be what the application expects. Furthermore, the driver may not fill in the action all together.
 
 

void read_dc_color_image (HT_Rendition const & hr,
        HT_DC_Point const & ul,
        HT_DC_Point const & lr,
        HT_Image_Format const & format,
        HT_Shared_Image alter & image) const {
    m_data->read_dc_color_image (hr, ul, lr, format, image);
}

void read_dc_depth_image (HT_Rendition const & hr,

        HT_DC_Point const & ul,
        HT_DC_Point const & lr,
        HT_Image_Format const & format,
        HT_Shared_Image alter & image) const {
    m_data->read_dc_depth_image (hr, ul, lr, format, image);
}

This method allocates storage for an HT_Shared_Image object with image format determined from format. Then the method copies depth data from the depth buffer to image. Note that HT_Image_Format now takes a reference or pointer according to the situation, that is, it can use the any method which reads the image from any format; or device_splecific which makes use of its own internal format.
 
 

For example, you set a particular option name on a particular renderer *rend using three or more function calls:

rend->set_configure("Window Origin", HT_Option_Value (x, y));

void update(HT_Int_Rectangle const & bounds)alter

void update(void)alter

All drivers must provide a method for the virtual function update(HT_Int_Rectangle & bounds).

The first form tells this renderer that the effects of the update action do not extend beyond the rectangle bounds, which specifies a region of the device surface in device coordinates. The second form is equivalent to the first with bounds equal to the entire window as defined in the current option table. The benefit in using the first form, when bounds is smaller than the entire window, depends on the renderer.
 

HT_Update_Status is an abstract base class defining the interface to support update progress or cancel functionality. It provides a mechanism to monitor the progress of potentially lengthy update() operations and to cancel update(), if necessary to save time.

void update_all (HT_Int_Rectangle const & bounds) alter

void update_all (void) alter