Seite 119 (3.6. PIXEL RECTANGLES):



Table 3.4: Color table names. Regular tables have associated image data. Proxy
tables have no image data, and are used only to determine if an image can be loaded
into the corresponding regular table.



target must be a regular color table name. pname is one of COLOR TABLE SCALE
or COLOR TABLE BIAS. params points to an array of four values: red, green, blue,
and alpha, in that order.

A GL implementation may vary its allocation of internal component resolution
based on any ColorTable parameter, but the allocation must not be a function of
any other factor, and cannot be changed once it is established. Allocations must
be invariant; the same allocation must be made each time a color table is specified
with the same parameter values. These allocation rules also apply to proxy color
tables, which are described later in this section.

Alternate Color Table Specification Commands

Color tables may also be specified using image data taken directly from the frame-
buffer, and portions of existing tables may be respecified.

The command

defines a color table in exactly the manner of ColorTable, except that table data
are taken from the framebuffer, rather than from client memory. target must be a
regular color table name. x, y, and width correspond precisely to the corresponding
arguments of CopyPixels (refer to section 4.3.3); they specify the image’s width
and the lower left (x, y ) coordinates of the framebuffer region to be copied. The

Seite 120 (3.6. PIXEL RECTANGLES):

image is taken from the framebuffer exactly as if these arguments were passed to
CopyPixels with argument type set to COLOR and height set to 1, stopping after the
final expansion to RGBA.

Subsequent processing is identical to that described for ColorTable, beginning
with scaling by COLOR TABLE SCALE. Parameters target, internalformat and width
are specified using the same values, with the same meanings, as the equivalent
arguments of ColorTable. format is taken to be RGBA.

Two additional commands,



respecify only a portion of an existing color table. No change is made to the inter-
nalformat or width parameters of the specified color table, nor is any change made
to table entries outside the specified portion. target must be a regular color table
name.

ColorSubTable arguments format, type, and data match the corresponding ar-
guments to ColorTable, meaning that they are specified using the same values,
and have the same meanings. Likewise, CopyColorSubTable arguments x, y, and
count match the x, y, and width arguments of CopyColorTable. Both of the Color-
SubTable commands interpret and process pixel groups in exactly the manner of
their ColorTable counterparts, except that the assignment of R, G, B, and A pixel
group values to the color table components is controlled by the internalformat of
the table, not by an argument to the command.

Arguments start and count of ColorSubTable and CopyColorSubTable spec-
ify a subregion of the color table starting at index start and ending at index
start + count − 1. Counting from zero, the nth pixel group is assigned to the
table entry with index count + n. The error INVALID VALUE is generated if
start + count > width.

Color Table State and Proxy State

The state necessary for color tables can be divided into two categories. For each
of the three tables, there is an array of values. Each array has associated with it
a width, an integer describing the internal format of the table, six integer values
describing the resolutions of each of the red, green, blue, alpha, luminance, and
intensity components of the table, and two groups of four floating-point numbers to
store the table scale and bias. Each initial array is null (zero width, internal format

- Wir benutzen die Parameterbezeichnungen wie sie in der DGLOpenGL.pas sind (war auch in der Funk.Vorlage so geschrieben glaub ich)

- Wir erklären noch was width ist, und wo man das herbekommt (wenn man das irgendwo herbekommt).