glPixelStore results when drawing pixel array

[ekfcipher]

Hi all. I am just getting started in OpenGL. I am running Fedora Core 5 and have an ATI 9800. I wrote a simple program to draw a PixMap to the screen using an 3d array of pixel data.

The following code is used to draw the pixels

void Draw()
{
	glClear(GL_COLOR_BUFFER_BIT);
	glRasterPos2f(-0.5, -.7);
	glPixelZoom(0.6, 0.6);
	glDrawPixels(1201, 1201, GL_RGB, GL_UNSIGNED_BYTE, checkImage);
}
 
void SetupRC(void)
{
	glClearColor(0.0f, 0.0f, 1.0f, 1.0f);	
	glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
}

Before I added the line glPixelStorei(GL_UNPACK_ALIGNMENT, 1) I got the the following result.

There is a “triangle” worth of pixels (from the lower right corner up about a third of the way over at the top) drawn in the wrong place. Almost like the Pixel row data is being wrapping in some strange way progressively more per row as they get to the top of the image. I learned that glPixelStore handles the alignment of pixel data in memory. What I don't get is why I would get results like this with every GL_UNPACK_ALIGNMENT setting except 1. I haven't got to test it on an NVIDIA card yet. I can't tell if this is specific to ATI or graphics card memory. Would this still happen if it was software rendered? If someone would be so kind as to educate me as to the reason this occurs I would appreciate it.

If my description doesn't help let me know, I'll have to try and find a place to put screen shots.

[Relic]

The default for the unpack alignments is 4 bytes. Any pixel data where a scanline * bytes per pixel is not a multiple of 4 will skew then.
Yours is (1201 * 3) % 4 = 3 but should be 0, so it skews.

This also is a common error when downloading mipmaps of GL_RGB8 data. Down to the level of 4x4 everything works, but 2x2 goes wrong!

Check out more cases in issue 7 of http://www.opengl.org/resources/feat...es/oglpitfall/

BTW, be aware that glDrawPixels also generates depth values. Make sure depth test, lighting, texturing etc. are off if you want to render pure pixel data with glDrawPixels.

[ekfcipher]

Ok, that makes sense. Would I be correct in the understanding that if I used RGBA instead of RBA (1201 * 4) % 4 = 0 thus unpack alignments of 2, 4, and 1 would work but not 8.

It also seems like from case 7 of the link that, the norm would be to generally set an alignment of 1, in order to not run into a situation of an image size not a multiple of 4, thus being safer code as well as being cross system safe (little vs big endian). Thanks a bunch!

[Relic]

Correct, GL_RGBA8 matches the size of the default pack and unpack alignment and wouldn't run into these issues.
Yes, using 1 will always match the size of tightly packed data.
Little vs big endian is only handled per component with the swap bytes pixelstore parameter. It doesn't affect types where components are byte sized.