   Doubts about screen Pitch.
PLEASE, READ THE 6TH REPLY TO THIS TOPIC (it starts with a "HERE" in green), THERE ARE MY DOUBTS. THE QUESTION BELOW (IN THIS SAME POST) HAS BEEN ANSWERED. THANKS!=============================Hello,I am studying game development reading the "Tricks of the Windows Game Programming Gurus". I am confused with the "pitch" thing of the screen.A SDL's tutorial shown this:void putpixel(int x, int y, int color){  unsigned int *ptr = (unsigned int*)screen->pixels;  int lineoffset = y * (screen->pitch / 4);  ptr[lineoffset + x] = color;}In this case the author says that the color is 32-bit, so I understand 4 bytes per pixel. a) But why when getting the offset the divide for 4 is necessary?The same on Lamothe's book, but he uses bit shift. In this case, the colors are 2 bytes. b) Why >> 1 = / 2?about.com says: "First, a right shift is equivalent to dividing by 2.". Thats ok. The hard thing is understand why >> 1 is the same as / 2.video_buffer16[x + y*(memory_pitchB >> 1)] = pixel_color_16;Thanks.[Edited by - Maquiavel on June 19, 2006 8:34:45 AM]
  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.2) Think about it, if you have 110b (which is 6) and you shift it right 1 bit, what do you have? 110b >> 1 == 11b, which is 3. As its basically an division by 2, you truncate the last bit. So, 7 >> 1 == 111b >> 1 would be 3 as well.   ;  Here is how look at number two:Lets say you have a base ten number:12440And you wanted to divide it by ten. Well, since you have using base ten since you were in kindergarten, you know that to divide be ten, you just lob off the last zero, to get:1244.It's similar in base two (binary) which the computer uses:1100101010100101010If we want to divide taht by two (which is what base it is in), we can just lob the last zero off. This is accomplished by bit shifting it to the right one place.As to using shifts, don't. It is simply dumb to use bit shifts because the compiler "automatically" takes / 2 and turns it into bit shifts.   ;Quote:Original post by ender7771As to using shifts, don't. It is simply dumb to use bit shifts because the compiler "automatically" takes / 2 and turns it into bit shifts.There are times (the OPs example not withstanding) where I think bitshifts can really help, at least to make your code easier to read. For example, if writting a packer for networking packets or doing some other compression/decompression/encryption, looking at data >> 4;makes a lot more sense thandata = (int)data / 16;   ;Quote:Original post by Driv3MeFarQuote:Original post by ender7771As to using shifts, don't. It is simply dumb to use bit shifts because the compiler "automatically" takes / 2 and turns it into bit shifts.There are times (the OPs example not withstanding) where I think bitshifts can really help, at least to make your code easier to read. For example, if writting a packer for networking packets or doing some other compression/decompression/encryption, looking at data >> 4;makes a lot more sense thandata = (int)data / 16;In that situations, I agree that bitshifting has its merits, as well as when you are trying to manipulate indiviual bits when passing flags or doing console programming.But just trying to by fancy about dividing by two is just lame.;  Always be as clear as possible. If you're shifting bits to move them to different locations in a larger block of bits, then use bitshift operators. If you're doing division, use the division operator. Any decent compiler will optimize the division into the most suitable operation anyways; worrying about the performance is not useful in this day and age.   ;HERE - NEW DOUBTSThanks for the answers. I have understood about shift. You said that uses clearly, but shift is in all Lamothe's book where there is divisions.I still don't understanding 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 Lamothe's book). And it is larged used. it divides by 4 to get the number of integers per scanlineExample: 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;// offset = 1601; - 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.- I "googled" and "wikipeded" and haven't found a good material about this subject. All the information goes straight to the code and doesn't say what it means or why. =(EDIT:A) I found another way of pitching: LINK.But it stills unclear. It uses another way:offset= (x*pixelWidth) + (y*surface.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) 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. Strange and boring thing to understand!!! [Edited by - Maquiavel on June 19, 2006 8:54:04 AM];  Pitch and width cannot be used interchangabley since the pitch must always be an exact multiple of four or something whereas width does not. Can't remember exactly how this works to be honest. Perhaps someone else can clarify.Pixel (1,2) is, counting from zero, the second pixel on the third line which on an 800x600 screen would indeed be the 1,601th pixel if the screen is viewed as one long line of pixels, regardless of the colour depth.In your edit, a) seems to be giving the byte offset rather than the pixel offset which is why the equation is different.   ;  A great tutorial that helped me understand pitch (picture included) can be found here (check about halfway down the page).  And, since this tutorial (20 pages) is completely written using the SDL library, it might be another good resource for you.   ;Quote:Original post by godricshollowA great tutorial that helped me understand pitch (picture included) can be found here (check about halfway down the page).  And, since this tutorial (20 pages) is completely written using the SDL library, it might be another good resource for you.Thanks, but this is the exactly tutorial I start reading =DIt started my doubt on this item with the function:void putpixel(int x, int y, int color){  unsigned int *ptr = (unsigned int*)screen->pixels;  int lineoffset = y * (screen->pitch / 4);  ptr[lineoffset + x] = color;}Thanks, anyway!