# Doubts about screen Pitch and things related to it

Hello,

I don’t understand PITCH.
1) The pitch in SDL is the length of a surface scanline in bytes, since the
code assumes 4 bytes per int, it divides by 4 to get the number of integers
per scanline.

• But even in DirectX there is pitch (as in lots of books). And it is
larged used.

it divides by 4 to get the number of integers per scanline
Example: resolution is 800x600, 32-bit color and the pitch is exactly
3.200(800 x 4 bytes). Dividing by four, I get 800 again. So, if I want
the pixel
(1,2) I will have to do:

offset = 2 * (pitch / 4) + 1;
this means that offset = 1601; what is very confusing.

• This means that “offset” is an integer number to a pixel?
• But if the integers aren’t 4 bytes, imagine 2 bytes or even 8 bytes?
• How does the offset would be correct to the position?
• I am still very lost with this thing and unfortunately I havent found any
good article / tutorial / chapter that explains this.
• Does you know where find this / which book? I really want to understand
this principles, and if there is a good book on it, would be great.
subject. All the information goes straight to the code and doesn’t say what
it means or why. =(

A) I found another way of pitching:
http://www3.telus.net/alexander_russell/course_dx/chapter_2_dx.htm
But it stills unclear. It uses another way:

offset= (xpixelWidth) + (ysurface.lPitch);

Now it doesn’t divides Y, it multiplies X. More confusing.

B) Gamedev’s dictionary says: “The width of a drawable surface multiplied
by the number of bytes per pixel. For instance an 800x600 screen at 16-bit
color would have a pitch of 1600.”.

If pitch is always divided by the number of the bytes, I will be always the
same as width. So, why use pitch? I just can use the width, no? Even if it
is 8, 16 or 32 bit color, because there is always a division to these number
of bytes, so on calculating offset, pitch = width.

C) This Mailing list: Code snipped in places above, but basically pitch is
measured in bytes, width is measured in pixels. Because he wants the offset
in pixels (which are 2 bytes, as he has set 16 bit colour) he divides it by
2 (e.g. 32 bytes = 16 pixels).

The same as B above.

Any help would be great.
Thanks,
Alfred R. Baudisch

El lun, 19-06-2006 a las 10:47 -0300, Alfred Reinold Baudisch
escribi?:
Hello,
I don’t understand PITCH.

You have a 2D dataset (the screen or window) which you want to represent
as a linear dataset (an array, given by a pointer).

The easiest way to arrange the screen into a linear array is to take all
the pixels of the first row, then all the pixels of the second row, and
so on. For a 6x3 screen like this one

000000
111111
222222

you get an array like this

000000111111222222

Row 0 starts at index 0, row 1 starts at index 6 (16), row 2 starts at
index 12 (2
6). 6 is the WIDTH of the surface.

However, assume that for some obscure, hardware-related issue, it’s
better for the video card to have rows start at indexes which are
multiples of 8 instead of 6. So you take your 6x3 screen and waste some
bytes at the end of each row to make each row 8 spaces wide, like this :

000000xx
111111xx
222222xx

When you put that in a linear array, you now get

000000xx111111xx222222xx

Row 0 starts at index 0, row 1 starts at index 8 (18), row 2 starts at
index 16 (2
8) and the video card is happy. The WIDTH of the surface is
still 6, but the PITCH is 8 - the “distance” between consecutive rows,
which as you see not always matches the width of a row.

Hope this helps!

–Gabriel________________________________________________________________________
Gabriel Gambetta
Mystery Studio - http://www.mysterystudio.com
Gabriel on Graphics - http://gabrielongraphics.blogspot.com

Hope this helps!

Great description, Gabriel!

``-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment``

Hello Gabriel,

Thanks a lot for your explanation and help!
Now I understand all this stuff.

Regards,
Alfred----------------------------

Row 0 starts at index 0, row 1 starts at index 8 (18), row 2 starts at
index 16 (2
8) and the video card is happy. The WIDTH of the surface is
still 6, but the PITCH is 8 - the “distance” between consecutive rows,
which as you see not always matches the width of a row.

Hope this helps!

–Gabriel

Good description, Gabriel. But can you validate some values I’m getting?

I’ve been throwing random sets of images at SDL_LoadBMP. I seem to be
getting a consistent pattern of
pitch=3*(width_rounded_up_to_closest_multiple_of_4).

So for example, I have an image with width=300 and height=150. Loading
it through SDL_LoadBMP, the pitch is reported as 900. (This seems
rather high to me.) The pitch is 3*300.

For images with widths that are not evenly divisible by 4, the
relationship works if I round the width up to the next multiple of 4.

For example, if my width=499 and height is 750, the pitch is reported at 1500.

Do these values seem correct? I was really expecting pitch to be the
width rounded up to the closest multiple of 4, not 3 times that value.

Thanks,
Eric

Good description, Gabriel. But can you validate some values I’m getting?

I’ve been throwing random sets of images at SDL_LoadBMP. I seem to be
getting a consistent pattern of
pitch=3*(width_rounded_up_to_closest_multiple_of_4).

So for example, I have an image with width=300 and height=150. Loading
it through SDL_LoadBMP, the pitch is reported as 900. (This seems
rather high to me.) The pitch is 3*300.

For images with widths that are not evenly divisible by 4, the
relationship works if I round the width up to the next multiple of 4.

For example, if my width=499 and height is 750, the pitch is reported at
1500.

Do these values seem correct? I was really expecting pitch to be the
width rounded up to the closest multiple of 4, not 3 times that value.

That seems right, if each color of red, green and blue take a byte.

BrunoOn Fri, 23 Jun 2006 07:34:46 -0300, E. Wing wrote: