[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:
>> p = 10101010
>> p = 11110000
>> p = 00001111
>> This becomes
>> which is
>> 00001111 11110000 10101010
>> (ordered with p on the left through to p 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<< a | p << b | p 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