Sign in to follow this  
ICUP

[sdl] What is Pitch?

Recommended Posts

ICUP    140
I don't understand pitch. SDL doc defines it as "The length of a surface scanline in bytes." So, I understand that pixels aren't stored like a 2d array but a continuous row. So, what is pitch then? I also saw that is was defined as, "the number of pixels to get to the pixel below it." If it is this definition, isn't pitch the same thing as the depth * bytesperpixel? For example if I had a depth of 32 and the bytes were 4 wouldn't I be at the first pixel of the next row?

Share this post


Link to post
Share on other sites
rip-off    10979
It is the number of bytes between lines.

It won't always be equal to width * bytesPerPixel, that is my understanding. I assume that you was what you meant when you said "depth".

I am not sure why, I would guess that it has something to do with hardware surfaces. It is possible that one some platforms each hardware scanline is aligned to some known offset, e.g. 4 byte boundaries.

Share this post


Link to post
Share on other sites
ICUP    140
Oh, ok. So what is pitch usually used for?

Isn't width * bytesperpixel to get to the next line? When you say width do you mean depth or the width of the screen? When I said depth I meant bits. Like 16 bits, 32 bits, etc.

Share this post


Link to post
Share on other sites
Sijmen    231
As previously mentioned, sometimes it's more efficient to the system to pad every scanline (row of pixels) with a few bytes before starting a new line. So when trying to locate a pixel in memory, you should use y * pitch + x.

Share this post


Link to post
Share on other sites
It used to be that most video cards only supported textures/images that were power-of-twos. (IE: 32, 64, 128, etc...)

SDL supports old technology as well as new technology, so it must support old video cards as well. Because SDL allows for it's SDL_Surfaces to be created in hardware, it must make them power-of-twos in some situations.

Here is a example image that is not a power of two:

The above image is only 150 by 150 pixels.

Here would be a (theoretical) example of the same image 'padded' with extra data for older hardware:

The above image is now 256 by 256 pixels; a power-of-two value. (256 is 2 to the 8th power)

The 'pitch' is (I believe, but I might've gotten this wrong) the width of the image after being padded.

To find a specific pixel in the padded image, you go like this:
Pixel = (y * pitch) + x;

You'd still use the width of your image before it was padded, to know when to stop drawing each line, and the height of your old image, to know when you reached the bottom of your image.

Share this post


Link to post
Share on other sites
ICUP    140
Thanks, Servant.

Ok...so let's say I have 50 by 50 image. If I wanted to find the pixel at (10,20). I would just do (20 * pitch) + 10?

Share this post


Link to post
Share on other sites
Quote:
Original post by ICUP
Thanks, Servant.

Ok...so let's say I have 50 by 50 image. If I wanted to find the pixel at (10,20). I would just do (20 * pitch) + 10?

Actually, (20 * (pitch/4)) + 10.

I don't do per-pixel manipulation enough, so I forgot that 'pitch' is the padded-width in bytes and not in pixels. If you are using normal SDL_Surfaces, your pixels are 32 bits (which is 4 bytes) each. So we divide by 4 to make the pitch be the image's width in pixels.

You might find this tutorial helpful.

Share this post


Link to post
Share on other sites
rip-off    10979
Quote:
Original post by Servant of the Lord
Quote:
Original post by ICUP
Thanks, Servant.

Ok...so let's say I have 50 by 50 image. If I wanted to find the pixel at (10,20). I would just do (20 * pitch) + 10?

Actually, (20 * (pitch/4)) + 10.

I don't do per-pixel manipulation enough, so I forgot that 'pitch' is the padded-width in bytes and not in pixels. If you are using normal SDL_Surfaces, your pixels are 32 bits (which is 4 bytes) each. So we divide by 4 to make the pitch be the image's width in pixels.

You might find this tutorial helpful.


I would use this source. That link makes quite a few assumptions about the pixel format of the surface it manipulates.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this