CODEWITHSUNDEEP
c++openglopengl-4
Weber Lin
Weber Lin

Reputation: 31

Why did glGet with GL_POLYGON_MODE returns two values?

When getting the mode of GL_POLYGON_MODE, glGetIntergerv(GL_POLYGON_MODE, data), I'll have to make data an integer array of size 2. because I've read somewhere that:

params returns two values: symbolic constants indicating whether front-facing and back-facing polygons are rasterized as points, lines, or filled polygons. The initial value is GL_FILL. See glPolygonMode.

So one is for GL_FRONT (data[0]), the other for GL_BACK (data[1]).

But since OpenGL3.2, PolygonMode face values of GL_FRONT and GL_BACK are deprecated, polygons are always drawn in the same mode, no matter which face is being rasterized.(https://stackoverflow.com/a/19672297/9629055)

Meaning you can only use GL_FRONT_AND_BACK in glPolygonMode, no longer can you use glPolygonMode(GL_FRONT, GL_LINE) nor glPolygonMode(GL_BACK, GL_LINE).

So my questions are:

  1. Why did glGet still returns two values for GL_POLYGON_MODE, while you can only use GL_FRONT_AND_BACK, I'm expecting only one value since front and back are always in the same mode.
  2. Is it safe to assume that when I write this glGetIntegerv(GL_POLYGON_MODE, data), data[0] always equals data[1]?
  3. also, why can't I find the description of GL_POLYGON_MODE in OpenGL4 reference pages as of now(2024 April 29), is it still under construction?

Upvotes: 3

Views: 149

Answers (1)

Nicol Bolas
Nicol Bolas

Reputation: 473174

GL_FRONT_AND_BACK is still setting two values: the front value and the back value. The inability to set these to different values doesn't change the fact that there are functionally two separate values.

Now, the main reason they're two separate values is compatibility with compatibility profiles. Core profile code (where front and back are always the same) ought to be able to work in compatibility contexts (where front and back can be different). So if glGetIntegerv returned 2 values in compatibility, but only one in core, core-based code running in a compatibility context could cause a buffer overrun because they would only be sending a single integer to something that's going to fill in an array of 2.

That's bad.

But since OpenGL3.2, PolygonMode face values of GL_FRONT and GL_BACK are deprecated

Just FYI: they are removed; it is an error to use those enums. "Deprecated" and "removed" aren't the same thing.

Upvotes: 0

Related Questions