[SDL] Get pixel value ...more in details

John R. Hall overcode at lokigames.com
Sun Aug 26 08:41:01 PDT 2001

On Sunday, August 26, 2001, at 02:35 AM, sragno at libero.it wrote:

>> Example:
>> p[0] = 10101010
>> p[1] = 11110000
>> p[2] = 00001111
>> This becomes
>> 000011111111000010101010
>> which is
>> 00001111 11110000 10101010
>> (ordered with p[2] on the left through to p[0] on the right).
>> This is returned as a Uint32, so there will be leading zeros... the
>> result for this example therefore would be:
>> 00000000000011111111000010101010 (with 8 leading zeros added)
>  I understand a little more...but:
>  - shifting one bite by 16 or even 8 bits doesn't always gives
>    a zero value ?

Not necessarily. Compilers sometimes take the liberty of extending the 
field to accommodate the new value. I don't know what the C standard says 
on this, but it doesn't seem to be guaranteed, as I've had it fail on some 
platforms. The SDL code seems to make this assumption a lot.

>  - we are returning p[2]<< a | p[1] << b | p[0] that is not*
>    a Uint32 (also *p or *(Uint16 *)p are not) , so how and where
>    happens this conversion ??

Again, it's a bad assumption that seems to work on most platforms. It will 
probably fail on platforms where sizeof(int) != 4 or (possibly) the 
compiler isn't gcc. I had big problems with this when I tried to port SDL 
to PalmOS (finally did get it to compile without warnings after adding a 
bunch of Uint32 casts to this kind of code).


More information about the SDL mailing list