We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 391 - A note of variable "pitch" of SDL_Surface estructure
Summary: A note of variable "pitch" of SDL_Surface estructure
Status: RESOLVED WONTFIX
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 1.2.9
Hardware: x86 Windows (XP)
: P2 trivial
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-08 10:28 UTC by Jordi Espada Brau
Modified: 2007-02-09 11:40 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jordi Espada Brau 2007-02-08 10:28:11 UTC
Hello,

My name's Jordi Espada Brau. I live in Spain, Barcelona.

I detect that when I create surfaces (as SDL_CreateRGBSurface()) that width not
multiple of 2 the value of variable "pitch" is incorrect.

I founded this error, when I was created a 16 bit surface of 15 width and 24 of height. The variable "pitch" result would to be 30 (w*BytesPerPixel = 15*2 = 30)
but was 32.

Regards all team SDL ;)
Comment 1 Patrice Mandin 2007-02-09 11:40:26 UTC
If you have a look at SDL_CalculatePitch() in SDL_pixels.c, you'll find that comment:
/* Surface should be 4-byte aligned for speed */

'pitch' is the number of bytes per line allocated for the surface. It is not the width*bytesPerPixel. Also if you check most video surfaces returned by SDL_SetVideoMode, you'll see that pitch value is even higher than width (sometimes 512 for a 400 pixel width, or 1024 for 800 pixel width). This is because video hardware don't always have finer granularity.

For software surfaces, it's easier for the cpu to deal with at least 4 bytes (32 bits) minimum granularity.

There is a good reason that 'pitch' value is present in SDL_Surface structure, in that it's most likely will be different than 'width'*'bytesPerPixel', or it would be useless to have it in the first place.