GL_UNPACK_* problems (driver bugs?)

Hello!

Short: I’m trying to “blit” a 2D image to the screen by uploading it as textures and drawing quads. For instance, I blit a 320x200 image partitioned into (whole or partial) 128x128 textures.

Since the original image is stored “straight off” in memory (320 colums x 200 lines, no interleaving etc), I want to use the OpenGL PixelStore parameters GL_UNPACK_ROW_LENGTH, GL_UNPACK_SKIP_ROWS and GL_UNPACK_SKIP_PIXELS to “cut out” a desired part of the image to upload as a texture (e.g. I set GL_UNPACK_ROW_LENGTH to 320, but the texture width is 128, which hopefully results in GL skipping 320-128=192 pixels after each line when uploading the texture image).

This works fine on my GeForce Ti4200 (I get >100 Mpixels/s effective transfer rate, by the way), but with the Microsoft software GL implementation I get memory access errors (=crash), and on a Linux machine with Intel i810 I get “shuffling errors” (pixels are not sent to the right place on the screen).

Now, my question is: Is it possible that these UNPACK parameters can give problems on some drivers/cards? Are they commonly used (the mentioned UNPACK parameters)? (I suspect not)

I have pinpointed the problem to using these parameters, but it could of course be another bug in my code which is only visible when I use the UNPACK parameters. Anyway, I wanted to check if someone else has had similar problems.

UNPACK_ROW_LENGTH is always used. The skipping of rows and pixels is not all that commonly used, as you can easily accomplish the same thing by doing simple pointer math on the pointer you pass into OpenGL.

I would suggest setting your stride (pitch) using UNPACK_ROW_LENGTH, but point at the bottom-left of the image yourself using pointer arithmetic.

Originally posted by jwatte:
UNPACK_ROW_LENGTH is always used.

Really? By setting UNPACK_ROW_LENGTH to zero (the default), the row length is taken from the ‘width’ parameter for glTexImage2D (for instance). It’s not the same thing as setting UNPACK_ROW_LENGTH to the width of the texture (I mean, it is probably a different code path for the GL implementation, and hence a potential bug source).

I would suggest setting your stride (pitch) using UNPACK_ROW_LENGTH, but point at the bottom-left of the image yourself using pointer arithmetic.

I will try that…

[This message has been edited by marcus256 (edited 11-09-2002).]

When I said “is always used” I mean that almost every application I know of has reason to use it, so I’d be VERY surprised if it had bugs. The offsets are very seldomly used, by contrast, and thus are much less likely to be well tested.

I’m wondering whether glPixelZoom(1,-1) (to turn the image upside down on upload) is more or less frequently used than the offsets…