glDrawPixels (or how to lose your time infinitely)

[jorge1774]

Hi all.

I have been for 2 days working with glDrawPixels + nvidia 53.36 with no LOGIC results. Obviously, there can be an explanation, but none of what I tried to do was nice.

My conclusions about glDrawPixels are:

1) It's affected by COMBINER and VERTEX_PROGRAM , so they must be disabled (NOT EXPLAINED IN ANY PLACE)

2) It's affected by the MODELVIEW and PROJECTION matrix (as it is explained in the MDSN doc)

3) It's affected in an unexpected way by the glRasterPos. Using glGet(GL_CURRENT_RASTER_POSITION,...) and setting again the SAME value with glRasterPos makes DIFFERENT results

4) It's affected in an unexpected way THAT MAYBE NO ONE IN THE WORLD KNOWS by the glDrawBuffer function. Setting glDrawBuffer to GL_BACK sometimes worked when doing glSwapBuffer and sometimes not (depen on the context), and setting it to GL_FRONT_AND_BACK, DOES NOT PAINT NOTHING MOST OF THE TIME except if you use later glSwapBuffer

5) It's affected by VBO, in a way in which you cannot set VBO, and disable it, and expect to paint on the screen nothing more with glDrawPixels

6) It's a ****. Full of bugs. Maybe no one uses it.

7) It SHOULD BE REMOVED FROM the drivers, because it just simply DOESN'T WORK, and it's not properly documented and it's, of course, only a way to make developers lose their time.

That's all.

[Mazy]

well, its not the best supported function, but not that bad, or?

1. I dont know about combiners, but a vertexprogram replaces the modelview and projection matrix calculations, so if its affected but those, then its affected by vertexprograms.

3. since the set should be affected by the matrices, i suppose that get->set will result in yet another multiplication with the matrices, so anything else than identity in those should chance the value, correct?

the rest i dont know anything about..

/Mikael

[SeskaPeel]

I played a bit with it, and had the same problem with RasterPos. Impossible to make it work correctly ...
What's more, I suspect it could be the reason I have an asynchronous result with ReadPixels (see my thread on stroke based rendering).

I agree, maybe less violently, with jorge.

SeskaPeel.

[Relic]

I disagree, it's working fine if you know what you're doing.

You have to understand
- what glRasterPos does and how and when it's transformed(!), lit, clipped in 3D (zNear, zFar!).
- what states affect glDrawPixels and it's fragments. It's lit, textured, logic op'ed, depth buffered(!), etc.

Vertex programs affect the rasterpos transformation, combiners affect the fragments, the draw buffer affects where it's painted.
It is depth buffered, so don't forget to disable depth test or clear the depth buffer. Make sure your raster doesn't fall outside the 3D view frustum or you get nothing.

[SeskaPeel]

Still,

if (ILikeJuice) {
rp = GetRasterPos()
SetRasterPos(rp)
}
DrawPixels()

If I like juice, DrawPixel won't draw, if I don't it will. Maybe I don't know what I'm doing and I don't know if I like juice ...

Is it a driver problem ? As the superb NVidia april fool ? Does it work only with version 4x and before ?

SeskaPeel.

[jorge1774]

Hi relic.

I agree with you in that openGL is sometimes complex because of the many states that can affect an operation, but if you can explain that two pieces of code, please, let me know:

This code works correctly at my program startup:

glClear(GL_DEPTH_BUFFER_BIT);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glDrawBuffer(GL_FRONT_AND_BACK);
glDrawPixels(ANCHOIMAGEN, ALTOIMAGEN, GL_RGB,GL_UNSIGNED_BYTE, (GLvoid *)imagen);
glDrawBuffer(GL_BACK);
SwapBuffers(hDC);

This not:

glClear(GL_DEPTH_BUFFER_BIT);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glDrawBuffer(GL_BACK);
glDrawPixels(ANCHOIMAGEN, ALTOIMAGEN, GL_RGB,GL_UNSIGNED_BYTE, (GLvoid *)imagen);
SwapBuffers(hDC);

Maybe there is an explanation, but I can't notice it.

Another question is that if I use glRasterPos AFTER setting my matrices, it doesn't paints anything (and I'm using rasterpos with the glGet(GL_CURRENT_RASTER_POS).

P.D. - None of these two pieces of code works if I bind an VBO buffer and unbind it. (only binding, nothing more)

See you!

[zeckensack]

I don't know what the problem is ...
Try this for a start:

glClear(GL_DEPTH_BUFFER_BIT); 
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
//this one's new
glDisable(GL_TEXTURE_2D);  //if you have more enabled, disable them all
glDisable(GL_LIGHTING);
glDisable(GL_DEPTH_TEST);
glRasterPos3f(-1.0f,-1.0f,0.0f);
 
glDrawBuffer(GL_BACK);
glDrawPixels(ANCHOIMAGEN, ALTOIMAGEN, GL_RGB,GL_UNSIGNED_BYTE, (GLvoid *)imagen);
SwapBuffers(hDC);

Work from there.

Don't use MSDN as your source of information for OpenGL. It sucks, it's wrong in a lot of places and generally outdated. Microsoft has a proven track record of suckage concerning documentation quality, and on top of that, they don't exactly show a firm commitment to OpenGL.
*cough*

If you want to know exactly what's going on, go to the OpenGL front page, head to documentation for developers and download the specification. The whole truth is in there.

Concerning VBOs, congratulations, you have found a bug in NVIDIA's drivers. You're now supposed to write a minimum repro case and email it to them. Or maybe they've already seen this thread.

Concerning your issues with getting the current raster position, well, what values do you get, and how do you attempt to get them? glGet(GL_CURRENT_RASTER_POSITION,whatever) is definitely not a valid way to get a vector of floating point values from OpenGL, in fact it won't even compile. So do tell.

Otherwise the pixel path is well documented. If you don't see that, you need to look harder.
Raster pos is transformed in exactly the same way as vertices are. Fragments produced by glDrawPixels are textured, colored, lit, whatever, exactly the same way as all other fragments are. That's it.

[jwatte]

DrawPixels generates fragments from pixels, that are affected by fragment processing. That's why COMBINE affects the pixels drawn.

Regarding the result of 4), did you check glGetError() after each GL call you issued? It feels to me as if there might be a usage problem hidden in there.

What I do (because I never get it all right on the first try :-) is to pepper my code with:

assert(!glGetError());

This gets compiled out in release mode, and catches problems while I'm working on it (in debug mode).

[Relic]

Originally posted by SeskaPeel:
Still,

if (ILikeJuice) {
rp = GetRasterPos()
SetRasterPos(rp)
}
DrawPixels()

If I like juice, DrawPixel won't draw, if I don't it will. Maybe I don't know what I'm doing and I don't know if I like juice ...

Is it a driver problem ? As the superb NVidia april fool ? Does it work only with version 4x and before ?

SeskaPeel.

If your GetRasterPos() reads the GL_CURRENT_RASTER_POSITION then you get window coordinates back.
If your modelview-projection matrix is not a pixel aligned 2D ortho the glRasterPos will transform it to somewhere else.

If you suspect a driver error, there are newer drivers than 53.36 you use.

[jorge1774]

Hi all.

I have texture_2d disabled for all units, lighting disabled and GL_DEPTH_TEST enabled (but the zbuffer is cleared).

I tried glRasterPos3f(-1,-1,0) before, but not worked.

Obviously I was talking about glGetfv or glGetv (well, I can't remember how I did).

My problem is that it works sometimes, and when I use VBO it never succeed again...

See you!

P.D. - Thanks for all your answers.

//this one's newglDisable(GL_TEXTURE_2D); //if you have more enabled, disable them allglDisable(GL_LIGHTING);glDisable(GL_DEPTH_TEST) ;glRasterPos3f(-1.0f,-1.0f,0.0f);