I have seen this pitfall in the book OpenGL: A PRIMER. If it’s not in common 16 pitfalls, it’s not bad to add this condition to the pitfalls;-) Here’s the pitfall:
The present raster color is locked by the use of glRasterPos*(). Thus, in the following code, the bitmap is drawn in red because the raster color is the color that was in effect the last time the function glRasterPos2i() was executed:
glColor3f( 1.0f, 0.0f, 0.0f );
glRasterPos2i( x, y );
glColor3f( 0.0f, 1.0f, 0.0f );
glBitmap(…);
To my point of view Ehsan, this is an error from GL. Any ‘interrested’ programmer should freely and obviously with a pertinent manner, expect the bitmap to be paint in green. Or may have I misunderstood a thing ??
I don’t know if it’s an lack in the GL specs, but I guess, really, important notes should be said about this.
No, thats no error in GL. You have to see the glRasterPos command as some sort of glVertex command, with it you submit the position, color, normal, … to the pipeline for further calculation.
This way, for example the lighting calculation will only be triggered by the glRasterPos command (assuming lighting is turned on), and it will only happen once. Otherwise it would have to happen with each glBitmap command, which would be redundant.
Ah okay. Thank you for that point Overmind. So from the code from Ehsan and what you said I could expect that the next RasterPos command will bring the color to green, won’t it ?