glColor

Definition:	include pGUI.e include opengl.e glColor(atom red, blue, green, alpha=1) -- or -- glColor3(atom {red,blue,green[,alpha=1]}) (actually declared as a single sequence parameter)
Description:	Deprecated, specifically not supported on WebGL. While still supported on desktop/Phix, these routines have been coloured illegal to indicate they cannot be handled by pwa/p2js. Sets the current color. red,blue,green,alpha: values in the range 0.0 (zero intensity) to 1.0 (full intensity). For the alpha value, 0.0 means completely transparent and 1.0 means completely opaque.
pwa/p2js:	Not supported.
Remarks	Note that no validation of these values occurs, either in the Phix wrapper or the C code, however all color components are clamped to the range [0,1] before they are interpolated or written into a color buffer. glColor3 implicitly sets alpha to 1.0 (full intensity), unless the single parameter has 4 elements. The GL stores both a current single-valued color index and a current four-valued RGBA color. glColor sets a new four-valued RGBA color. The C interface specifies no less than 32 entry points, whereas the pGUI interface is simplified to just two entries. The f/d variants should map directly, but take special care with any b/i/s variants, if you ever see any of those - see technicalia for details. The initial value for the current color is (1, 1, 1, 1). The current color can be updated at any time. In particular, glColor() can be called between a call to glBegin() and the corresponding call to glEnd(). Existing values can be retrieved via glGet with argument GL_CURRENT_COLOR or GL_RGBA_MODE.
See Also:	glBegin, glEnd, glGet DEV See also //glBegin //glEnd //glGetBooleanv, glGetDoublev, glGetFloatv, glGetIntegerv glIndex
Technicalia	The C interface defines 32 entry points: glColor(3\|4)((d\|f)\|[u](b\|i\|s))[v], For example glColor3b, glColor4fv - see the index for the full list, all marked incompatible, and all linked here. In light of the fact that I found no examples where they were actually used, and to simplify the wrapper, and this documentation, there is currently no support for the [u](b\|i\|s)[v] variants. It would of course be trivial to add them should they ever be needed. The original documentation said: Unsigned integer color components, when specified, are linearly mapped to floating-point values such that the largest representable value maps to 1.0 (full intensity), and 0 maps to 0.0 (zero intensity). Signed integer color components, when specified, are linearly mapped to floating-point values such that the most positive representable value maps to 1.0, and the most negative representable value maps to -1.0. (Note that this mapping does not convert 0 precisely to 0.0.) Hence any b\|i\|s values will not work with glColor, which is a wrapper for glColor4d - ask for help if needed. Floating-point values are mapped directly, and for pGUI there is no significant difference between the d and f variants, hence they have been merged (and internally use the "d" C functions). No C function name remains unscathed, all calls will require some manual translation to whichever of glColor or glColor3 is more natural. Most commonly, the C function glColor3d should be changed to glColor (rather than glColor3), whereas in some legacy Euphoria code the reverse happens to be true. Also, the [v] C functions are not currently wrapped, and are also coloured Incompatible. They would only be useful if there was some good reason why you already had your byte/double/float/integer/short triplet/quadlet poked into some allocated memory.