4

I am reading the OpenGL SuperBible for OpenGL 3.x. I am having a hard time understanding the whole "pixel packing concept." I get that typically a 199px wide image would require 597 bytes [(199 * 3)3 for each color channel RGB]. My first question is why would this only sometimes be right, the author says this only woks with a 4byte alignment system. He goes on to say that an extra three bytes will be added to make it divisible by four easily, which I don't understand either. So really my question is what is the significance of a 4 byte alignment -- what does that actually mean?? The author then says the alternative is 1-byte alignment, which I don't understand either.

The author says that .TGA is 1 byte aligned or "tight" and .bmp is 4 byte aligned.

What is a 4 byte alignment, a 1 byte alignment, and why should I use one over the other? When should I use .tga or .bmp for texturing?

Massimiliano
  • 16,770
  • 10
  • 69
  • 112
foobar5512
  • 2,470
  • 5
  • 36
  • 52

2 Answers2

3

Well it is about data alignment. It differs on different architectures and memory management. For example when you code a in 32-bit processor the default padding on a structure / int is 4-byte. In 64-bit is 8-byte. When you want to override the default padding on a code structure you can use #pragma pack (on visual studio), attribute((packed)) (gcc).

Look here for additional reference:

Community
  • 1
  • 1
Ed Abucay
  • 483
  • 7
  • 20
2

To make matters worse, your description doesn't differentiate pixel alignment vs scan line alignment.

A 199 pixel image with 24-bit color indeed requires 597 bytes. But the second scan line will start at offset 600, because it has to be aligned to a 4 byte boundary, and 600 is the first 4 byte boundary that doesn't overlap the first scan line.

This means that instead of each pixel starting at byte

(x + y * width) * 3

Each row will start at byte

y * 600

and each pixel at byte

y * 600 + x * 3

But why not just make your textures a power of 2, which is supported on all cards in all OpenGL versions and doesn't cause alignment questions? You use texture coordinates to make sure that the padding isn't ever processed or rendered.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • What do you mean by padding? I have no idea about any memory topics, this is my first low level API – foobar5512 May 18 '13 at 01:44
  • 2
    If you have a 199 pixel wide image and put that into a 256-wide texture (which is the nearest power-of-2), you will have 57 extra pixels next to your image. I called that padding, an artist would call it matting. The nice thing about power-of-2 textures, is that the fractional numbers which represent pixels in your image will have a power-of-2 denominator, which makes them exactly representable in floating point (and fixed point) binary. – Ben Voigt May 18 '13 at 01:48
  • Ah...ok I get the padding thing now. But why wouldn't just use something that is one byte aligned so I don't have to deal with the issue of padding? Thanks! – foobar5512 May 18 '13 at 01:55
  • @Blakeasd: It's because of how the wires connect the memory. I wrote [another answer](http://stackoverflow.com/a/3903577/103167) that explains why aligned accesses are faster. As to why scan lines need to be aligned but individual pixels don't, I'm not quite sure. In my work I use either R8G8B8A8 or A8 textures, and then individual pixels are well aligned also. – Ben Voigt May 18 '13 at 02:00