I was looking over Brackeen.com's bitmap-loading
tutorial, and he says this:
Something interesting to note about the BMP file
format is that each scan line is padded to the
nearest 4-byte boundry. So, if the image read
has a width that is not divisible by four, say,
21 bytes, there would be 3 bytes of padding at
the end of every scan line.
What exactly does this mean? Scan line? Padded
to the nearest 4-byte boundry? Will someone
please explain this to me in idiot-terms?
Thank you,
static
Staying away from General.
I'll try to answer
Imagine a bitmap as a lot of "rows" (rows of pixels) lying on top of each other to from a picture. One of these rows is called a scanline. The length of this scanline is the width of the picture.
To speed up mathematical operations with bitmaps, these scanlines must be divisible by 4 (4, 8, 12... 40... etc). Why? Because it is way faster to multiply a number with 4 than say 3. It has to do with bit-shifting, but I'm not going to explain that here.
If you have a bitmap with the width 9, the scanline is actually 12 pixels long. the last 3 bytes (pixels) is not in the actual bitmap. So when you read the bitmap into the memory, you have to have a function to skip these bytes, otherwise the bitmap will look "angled" (which is a pretty cool effect by the way).
I don't have time to make up some code for that now. Perhaps someone else can, or you might try it on your own (I did
Good luck
MagosX.com
Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime.
The reason that the bitmaps are aligned to 4-byte boundaries is because Intel processors only can read data at a 4-byte boundary. If values aren't aligned, Intels can't work with them as fast as if they were aligned because it will have to read more data to get the actual value. That's the only reason.
None of the above answers is completely accurate. Here is the CORRECT answer:
The reason you read/write data in/out from RAM and the CPU 4-bytes at a time, is because this is the current _native word length_ of the processor-- 32 bits. aka "unsigned long".
Because it is the native on-the-bus word-size of most processors today (any processor, whether it's Motorola 680x0 or Intel P XX, or AMD whatever) it doesn't have to be masked or shifted by the processor in order to worked with odd-numbers of bits.
This is called _performance_ code. Whenever you allocate a bitmap or a pixmap, you allocate each scanline (ie. "row") so it rounds up to the next nearest boundary.
This is why I am always preaching about 'working with the machine"--- if you code such that the CPU has to do less work to execute your code, it runs lots faster.
enjoy.
That was what I was trying to say. If the processor tries to read a DWORD from a non-aligned memory, it has to read both the DWORD in front and the DWORD behind and combine the results.
// Gliptic
