When I allocate a bitmap which is smaller, ie 150*20 pixels, the pitch is
452 !?!?, it should be 450!
In the exact same place in my code, all bitmaps allocated (temp bitmaps)
become 8r8g8b, but the smaller ones get 2bytes extra in each line. Why is
this?
I alloc a 24bit 0xff0000, 0x00ff00… bitmap each time, no difference, just
the size.
Oscar Campbell
When I allocate a bitmap which is smaller, ie 150*20 pixels, the pitch is
452 !?!?, it should be 450!
The pitch is word-aligned at 4-byte boundaries.
This results in faster memory accesses when doing memory copies
on some systems.
In general, you should never assume that the pitch is equal to widthbpp,
because under many circumstances, the video memory is not always set up
that way. Often the pitch will be much larger than widthbpp.
See ya!
-Sam Lantinga (slouken at devolution.com)
When I allocate a bitmap which is smaller, ie 150*20 pixels, the pitch is
452 !?!?, it should be 450!
Many systems require pitch or “row bytes” to be an even multiple of 4 or 16,
to keep memory accesses aligned on the bus. That’s why the measure exists
separately from the image width.
Matt
/* Matt Slot, Bitwise Operator * One box, two box, yellow box, blue box. *
Hi there…
Sam Lantinga wrote:
When I allocate a bitmap which is smaller, ie 150*20 pixels, the pitch is
452 !?!?, it should be 450!The pitch is word-aligned at 4-byte boundaries.
This results in faster memory accesses when doing memory copies
on some systems.In general, you should never assume that the pitch is equal to widthbpp,
because under many circumstances, the video memory is not always set up
that way. Often the pitch will be much larger than widthbpp.
Sam, since you’re obviously experienced in X programming, can you explain why
in crystal space (which doesn’t use the SDL), the engine frametime varies up
and down depending on whether the X window is placed on a byte which is a
multiple of 4? Is this a problem you encountered with the SDL? How did you fix
it?
Peter
Sam, since you’re obviously experienced in X programming, can you explain why
in crystal space (which doesn’t use the SDL), the engine frametime varies up
and down depending on whether the X window is placed on a byte which is a
multiple of 4? Is this a problem you encountered with the SDL? How did you fix
it?
That sounds like the alignment problem within the X server itself.
I’m pretty sure that if you test SDL on the same system it would
have a similar problem.
Try a newer server.
See ya!
-Sam Lantinga (slouken at devolution.com)
The pitch is word-aligned at 4-byte boundaries.
This results in faster memory accesses when doing memory copies
on some systems.
In general, you should never assume that the pitch is equal to width*bpp,
Well, I have actually not used bitmap->w3, I used the pitch as i should,
but then the image was ‘skewed’ like 2bytes each row… So I tried to do it
the ‘wrong’ way, by using b->w3 and THAT WORKED! Veeery strange, the pitch
still shows 452 but I have to use a pitch of 450 for it to work, however,
sometimes the RGB order is wrong (the pointer starts to point to the byte
right after/before the intended one)
But I can’t see anyway of getting pass this, using pitch should be the right
way, but that, as I said, does’nt work at all it seems 
I’m using 0.8.6 with VC5++ (w98 screwed my linux installation )
Oscar Campbell
Well, I have actually not used bitmap->w3, I used the pitch as i should,
but then the image was ‘skewed’ like 2bytes each row… So I tried to do it
the ‘wrong’ way, by using b->w3 and THAT WORKED! Veeery strange, the pitch
still shows 452 but I have to use a pitch of 450 for it to work, however,
sometimes the RGB order is wrong (the pointer starts to point to the byte
right after/before the intended one)
Very strange. Can you send me example code with an image that exhibits
this problem, via private e-mail to slouken at devolution.com ?
See ya!
-Sam Lantinga (slouken at devolution.com)