Pixel location in 16-bpp

SDL Development
1

I am new to SDL. I’ve just read the introduction part and have a question here:

In the example of drawing pixels on the screen, I found the code as given below:

{
Uint16 *bufp;

        bufp = (Uint16 *)screen->pixels + y*screen->pitch/2 + x;
        *bufp = color;

}

Why do we divide screen->pitch by 2?

Any other information?

Thanks a lot!

2

Because screen->pitch is in bytes, whereas the ‘+’ operator here
translates into array indexing. That is, the statement is equivalent
to

bufp = (Uint16 *)screen->pixels[y*screen->pitch/2 + x];

In C, pointers are indexed by elements of the pointer type. (Thank God
it’s not that close to asm!) Here you cast the pointer to Uint16
before the indexing operation, and since sizeof(Uint16) == 2, the
index expression is muliplied by 2 to generate the actual offset.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 16 May 2004 15.38, wangxiaohu wrote:

I am new to SDL. I’ve just read the introduction part and have a
question here:

In the example of drawing pixels on the screen, I found the code as
given below:

{
Uint16 *bufp;

bufp = (Uint16 )screen->pixels + yscreen->pitch/2 + x;
*bufp = color;
}

Why do we divide screen->pitch by 2?

3

Cool. Thanks.

Another question:

I am currently doing a video streaming from some source and I’d like to use SDL
for it. Say if I have a frame of image just arrived in RGB format, can just copy
it to *bufp and do an SDL_UpdateRect? If not, what is the best way to do that?

4

Cool. Thanks.

Another question:

I am currently doing a video streaming from some source and I’d
like to use SDL for it. Say if I have a frame of image just arrived
in RGB format, can just copy it to *bufp and do an SDL_UpdateRect?

Yes, that should work, though you should probably use SDL_Flip() and a
double buffered h/w surface whenever you can.

Either way, make sure the data is actually in the pixel format used by
the display surface! (16 bpp can be 5:6:5 or 5:5:5, for example, and
there’s a risk of seeing BGR instead of RGB.)

If not, what is the best way to do that?

Sometimes, it can be faster to stuff the data in a s/w surface first
and then blit that to the screen. However, even when DMA transfers
are possible, they’re so slow that they only make sense if you can
have them in progress while the CPU is doing something else… The
only real use for this is when you’re doing substantial amounts of
alpha blending or other unaccelerated operations that involve reading
from the display surface.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 16 May 2004 16.09, wangxiaohu wrote: