OpenGL 1.5 specification corrections

Here are a list of corrections to the OpenGL 1.5 specification:

Page 290: There is no PointParameters command. Should be PointParameter.

Page 315: Index version of page 290 issue. Should be PointParameter.

Page 73: glPointParameter{if} should be PointParameter.

Page 74: glPointParameter{if}v should be PointParameter.

Page 312: Index version of pages 73 and 74 issue. Should be PointParameter.

Page 190: “If there is a multisample buffer (SAMPLE_BUFFERS is 1)” -> “If there is a multisample buffer (the framebuffer’s value of SAMPLE_BUFFERS is 1)”. SAMPLE_BUFFERS is an enum that is not 1; what’s important is the framebuffer’s value of SAMPLE_BUFFERS.

Page 160: Table 3.22: Change “Cf” to “Cp” in these tables to reflect multitexture behavior. Cf is the interpolated color; Cp is the previous color which is Cf for texture unit 0.

Page 161: Table 3.23: Same change as above for this table too.

Page 121: “(The definition of closely is left up to the implementation.” -> “(The definition of closely is left up to the implementation. However, a number of bits greater than zero are required for if a non-zero number of bits is listed for a given component resolution in table 3.16; likewise, if no (zero) bits are listed in table 3.16 for a given component resolution, zero bits must be allocated.” This keeps implementations, for example, from providing a GL_INTENSITY format for a GL_LUMINANCE format or vice versa. Basically, implementations are not given leeway to violate the spirit of base formats.

Page 136: “for TEXTURE_BORDER_COLOR are” -> “for TEXTURE_BORDER_COLOR or the value of TEXTURE_PRIORITY are”. This matches how the sample implementation handles TEXTURE_PRIORITY. Brian Paul changed Mesa to match the sample implementation. The type of the TEXTURE_PRIORITY is clear listed as a R[0,1] value in table 6.16 and so the integer value specified should be converted to the [0,1] range as usual practice.

Page 136: Similar to above: “Each of the four values set by TEXTURE_BORDER_COLOR is” -> “Each of the four values set by TEXTURE_BORDER_COLOR or the value of TEXTURE_PRIORITY is”.

Page 37: Delete the sentence “The active texture unit selector may be queried by calling GetIntegerv with pname set to ACTIVE_TEXTURE.” Explanation of state queries is deferred to Chapter 6 and fully explained there. There’s no need to treat the ACTIVE_TEXTURE state specially and it is confusing to introduce GetIntegerv and mention one of its parameter names with a prototype.

Page 149: Delete the statement “(if the warp mode for a coordinate is CLAMP or CLAMP_TO_EDGE)” because section 3.8.7 also explains the clamping for CLAMP_TO_BORDER and MIRRORED_REPEAT as well as how REPEAT is handled. This statement dates to when REPEAT, CLAMP, and CLAMP_TO_EDGE were the only wrap modes and no longer makes sense given the two additional wrap modes and the way the specification reads today.

Page 155: Add to the end of the first incomplete paragraph: “The initial value of GENERATE_MIPMAP is false.”

Page 203: Change “In selection mode, no fragments are rendered into the framebuffer.” to “When the GL is in selection mode, the GL generates no updates to the framebuffer.” Based on Ken Dyke’s concerns. This resolves the question of whether glClear and glAccum operate in selection mode (they are nops in selection mode). Also, glReadPixels does operate normally without regard to the render mode.

Page 204: Change “When the GL is in feedback mode, fragments are written to the framebuffer.” to “When the GL is in feedback mode, the GL generates no updates to the framebuffer.” The phrase “writing fragments” is something of a mismatched phrase. Color, depth, and stencil values are written to the framebuffer, not fragments. This resolves the question of whether glClear and glAccum operate in feedback mode (they are nops in feedback mode). Also, glReadPixels does operate normally without regard to the render mode.

The PDF for the OpenGL 1.5 specification that the above page numbers reference is found here:

http://www.opengl.org/developers/documentation/version1_5/glspec15.pdf

  • Mark

Hi Mark,

I believe your references to page 136 of the spec should actually be page 143.

FYI: I’ve updated Mesa so that glAccum is a no-op if we’re in selection or feedback mode. Thanks for highlighting that.

-Brian

Is a corrected PDF going to be published at some point?

Originally posted by MikeC:
Is a corrected PDF going to be published at some point?

Despite my submitting most of these corrections many months ago for inclusion in OpenGL 1.5, these corrections were never integrated.

I’m not in a position to know if these corrections will be made to an updated PDF, but it seems unlikely in the OpenGL 1.5 timeframe for reasons that have nothing to do with the timeliness or validity of the corrections.

It’s an unfortunate situation.

My rationale for posting the corrections is to archive them so they can, hopefully, be integrated in the next OpenGL revision.

  • Mark