GLRASTERPOS(3G)
π GLRASTERPOS π β from the 3G manual
okay bestie, gather round π«Ά today's episode of "your girl explains OpenGL" is about glRasterPos, aka the function that tells GL where to plop down your pixels and bitmaps. it's giving "I know where I'm going in life" energy. β¨
πΈ NAME πΈ
the whole girlband, together, in one lineup:
glRasterPos2d, glRasterPos2f, glRasterPos2i, glRasterPos2s,
glRasterPos3d, glRasterPos3f, glRasterPos3i, glRasterPos3s,
glRasterPos4d, glRasterPos4f, glRasterPos4i, glRasterPos4s,
glRasterPos2dv, glRasterPos2fv, glRasterPos2iv, glRasterPos2sv,
glRasterPos3dv, glRasterPos3fv, glRasterPos3iv, glRasterPos3sv,
glRasterPos4dv, glRasterPos4fv, glRasterPos4iv, glRasterPos4sv
and what do they all do? they specify the raster position for pixel operations. that's it. that's the job. no cap. π
β¨ C SPECIFICATION β¨ (the scalar besties)
the non-vector versions, where you hand over each coordinate yourself:
void glRasterPos2d( GLdouble x,
GLdouble y )
void glRasterPos2f( GLfloat x,
GLfloat y )
void glRasterPos2i( GLint x,
GLint y )
void glRasterPos2s( GLshort x,
GLshort y )
void glRasterPos3d( GLdouble x,
GLdouble y,
GLdouble z )
void glRasterPos3f( GLfloat x,
GLfloat y,
GLfloat z )
void glRasterPos3i( GLint x,
GLint y,
GLint z )
void glRasterPos3s( GLshort x,
GLshort y,
GLshort z )
void glRasterPos4d( GLdouble x,
GLdouble y,
GLdouble z,
GLdouble w )
void glRasterPos4f( GLfloat x,
GLfloat y,
GLfloat z,
GLfloat w )
void glRasterPos4i( GLint x,
GLint y,
GLint z,
GLint w )
void glRasterPos4s( GLshort x,
GLshort y,
GLshort z,
GLshort w )
and then the original page drops this little formatting incantation, which we are keeping exactly as-is because rules are rules:
delim $$
π PARAMETERS π
x,y,z,wβ these specify the$x$,$y$,$z$, and$w$object coordinates (if present) for the raster position. note the "if present" bestie β the2versions don't take all four, the3versions take three, the4versions take the whole squad. π
π¦ C SPECIFICATION π¦ (the vector versions, iykyk)
same energy, but you pass a pointer to an array instead. so efficient. so slay.
void glRasterPos2dv( const GLdouble *v )
void glRasterPos2fv( const GLfloat *v )
void glRasterPos2iv( const GLint *v )
void glRasterPos2sv( const GLshort *v )
void glRasterPos3dv( const GLdouble *v )
void glRasterPos3fv( const GLfloat *v )
void glRasterPos3iv( const GLint *v )
void glRasterPos3sv( const GLshort *v )
void glRasterPos4dv( const GLdouble *v )
void glRasterPos4fv( const GLfloat *v )
void glRasterPos4iv( const GLint *v )
void glRasterPos4sv( const GLshort *v )
π PARAMETERS π (again, but for the pointer girlies)
vβ a pointer to an array of two, three, or four elements, specifying$x$,$y$,$z$, and$w$coordinates, respectively. π«
π DESCRIPTION π
so. GL keeps track of a 3D position in window coordinates. this position is called the raster position, and it's the thing that decides where pixel and bitmap write operations go down. it's maintained with subpixel accuracy, which is lowkey iconic. see glBitmap, glDrawPixels, and glCopyPixels.
the current raster position is literally a whole bundle, not just a point. it consists of:
- three window coordinates (
$x$,$y$,$z$), - a clip coordinate value (
$w$), - an eye coordinate distance,
- a valid bit,
- and associated color data and texture coordinates.
the $w$ coordinate is a clip coordinate, because $w$ is not projected to window coordinates. important. don't forget it. π§
here's how the family splits up:
glRasterPos4specifies object coordinates$x$,$y$,$z$, and$w$explicitly.glRasterPos3specifies object coordinate$x$,$y$, and$z$explicitly, while$w$is implicitly set to 1.glRasterPos2uses the argument values for$x$and$y$while implicitly setting$zand$w$to 0 and 1.
the object coordinates you hand to glRasterPos get treated just like the ones from a glVertex command π«’: they're transformed by the current modelview and projection matrices and passed to the clipping stage. then:
- if the vertex is not culled, it gets projected and scaled to window coordinates, those become the new current raster position, and the
GL_CURRENT_RASTER_POSITION_VALIDflag is set. β - if the vertex is culled, the valid bit is cleared and the current raster position and its associated color and texture coordinates are undefined. π (dramatic but true, that's the spec's word, not mine)
the current raster position also carries around some associated color data and texture coordinates:
- if lighting is enabled, then
GL_CURRENT_RASTER_COLOR(in RGBA mode) orGL_CURRENT_RASTER_INDEX(in color index mode) is set to the color produced by the lighting calculation β seeglLight,glLightModel, andglShadeModel. - if lighting is disabled, the current color (in RGBA mode, state variable
GL_CURRENT_COLOR) or color index (in color index mode, state variableGL_CURRENT_INDEX) is used to update the current raster color.
likewise, GL_CURRENT_RASTER_TEXTURE_COORDS is updated as a function of GL_CURRENT_TEXTURE_COORDS, based on the texture matrix and the texture generation functions (see glTexGen). and finally, the distance from the origin of the eye coordinate system to the vertex β as transformed by only the modelview matrix β replaces GL_CURRENT_RASTER_DISTANCE. the way this function updates so many state variables?? main character behavior fr fr. π
now, the initial values, because we love a clean slate:
- current raster position is
(0, 0, 0, 1) - current raster distance is
0 - the valid bit is set
- the associated RGBA color is
(1, 1, 1, 1) - the associated color index is
1 - the associated texture coordinates are
(0, 0, 0, 1)
and a lil quirk: in RGBA mode, GL_CURRENT_RASTER_INDEX is always 1. in color index mode, the current raster RGBA color always maintains its initial value. it just does. that's the vibe. πΈ
π NOTES π
- the raster position is modified both by
glRasterPosand byglBitmap. two queens sharing the throne. - when the raster position coordinates are invalid, drawing commands that are based on the raster position are ignored (that is, they do not result in changes to GL state).
- calling
glDrawElements, orglDrawRangeElementsmay leave the current color or index indeterminate. and ifglRasterPosis executed while the current color or index is indeterminate, the current raster color or current raster index remains indeterminate. π - to set a valid raster position outside the viewport, first set a valid raster position, then call
glBitmapwithNULLas the bitmap parameter. that's the trick, bestie, write it down. π - when the
GL_ARB_imagingextension is supported, there are distinct raster texture coordinates for each texture unit. each texture unit's current raster texture coordinates are updated byglRasterPos. β¨
π ERRORS π
GL_INVALID_OPERATION is generated if glRasterPos is executed between the execution of glBegin and the corresponding execution of glEnd.
bestie. do NOT callglRasterPosinside aglBegin/glEndblock. the GL will simply not allow it and will throwGL_INVALID_OPERATIONat you. periodt. π«
π₯ ASSOCIATED GETS π₯
glGet with argument:
GL_CURRENT_RASTER_POSITIONGL_CURRENT_RASTER_POSITION_VALIDGL_CURRENT_RASTER_DISTANCEGL_CURRENT_RASTER_COLORGL_CURRENT_RASTER_INDEXGL_CURRENT_RASTER_TEXTURE_COORDS
π SEE ALSO π
glBitmap(3G), glCopyPixels(3G), glDrawArrays(3G), glDrawElements(3G), glDrawRangeElements(3G), glDrawPixels(3G), glTexCoord(3G), glTexGen(3G), glVertex(3G)
okay that's the whole page, you ate it up, no crumbs left πβ¨ it's all from the GLRASTERPOS(3G) page β the header said GLRASTERPOS(3G) and the footer said GLRASTERPOS(3G) again, so she really said "my name is my name" π
go forth and position your rasters, bestie π«Άπ
π¦ where this page comes from
- opensuse-leap 16.0: Mesa-libGL-devel 24.1.7-160000.3.1 Β· MIT
- opensuse-leap 16.0: Mesa-libGL-devel 24.3.3-160000.3.1 Β· MIT
- opensuse-leap 16.0: Mesa-libGL-devel 24.3.3-160000.3.1 Β· MIT
- opensuse-leap 16.0: Mesa-libGL-devel 24.3.3-160000.3.1 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms