CODEWITHSUNDEEP
copengl
I hate stackoverflow
I hate stackoverflow

Reputation: 65

Questions about glPixelStorei() alignment

Every 2 values in this array represent 16 pixels. (8 binary values per element)

GLubyte character[24] = {
    0xc0, 0x00, 0xc0, 0x00, 0xc0, 0x00, 0xc0, 0x00, 0xc0, 0x00,
    0xff, 0x00, 0xff, 0x00, 0xc0, 0x00, 0xc0, 0x00, 0xc0, 0x00,
    0xff, 0xc0, 0xff, 0xc0
};

and this is my code to render my bitmap.

void init(){
    glPixelStorei(GL_UNPACK_ALIGNMENT, 2);
}

void render(){
    glBitmap(8, 12, 0.0, 11.0, 0.0, 0.0, character);
}

but when I change glBitmap(8, etc.) to glBitmap(10, etc.) , it doesn't work.

to make it work, I need to change,

glPixelStorei(GL_UNPACK_ALIGNMENT, 2);

to

glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

My problem is, I have no idea why this works...

I just know that 

GL_UNPACK_ALIGNMENT, 1

tells OpenGL to just go to next address without alignment.

I don't see any relationship between setting ALGINMENT to 1 and my bitmap's length.

Could somebody explain what's going on?

Upvotes: 0

Views: 915

Answers (1)

Reto Koradi
Reto Koradi

Reputation: 54642

After going back to some historical spec documents (glBitmap() is a very obsolete call), the alignment rule for bitmaps is (page 136 of the OpenGL 2.1 spec):

k = a * ceiling(w / (8 * a))

Where:

  • w is the width, under the assumption that GL_UNPACK_ROW_LENGTH is not set.
  • a is the value of GL_UNPACK_ALIGNMENT.
  • k is the number of bytes used per row. Note that each row will always start on at least a byte boundary, no matter how the parameters are set.

Substituting the values from your example, for w = 8, we get:

  • 1 byte per row with GL_UNPACK_ALIGNMENT of 1.
  • 2 bytes per row with GL_UNPACK_ALIGNMENT of 2.

and for w = 10, we get:

  • 2 bytes per row with GL_UNPACK_ALIGNMENT of 1.
  • 2 bytes per row with GL_UNPACK_ALIGNMENT of 2.

Based on this, unless you also have other GL_UNPACK_* parameters set, you should get the same output for width 10 no matter if GL_UNPACK_ALIGNMENT is 1 or 2. If this is not the case, this looks like a bug in the OpenGL implementation.

Upvotes: 1

Related Questions