[SDL] Pixel byte manipulation question.

[Paul Duffy]

On Wed, 2007-10-03 at 13:49 -0500, matt hull wrote: 
> >
> >> Anyway, it is possible to have a pixel laid out with the RGB masks
> >> you
> >> listed. Not common, but possible.
> >
> > Gack. I'll have to see if the screen blitting functions would accept
> > such a format, I'd rather avoid having to check the dest/source masks
> > every time. If the format is reasonably predictable then the worst I
> > have to do is use some ifdefs to use the appropriate formatting per
> > platform rather than having to use runtime detection. I'm mainly  
> > trying
> > to avoid doing anything unnecessary that would slow things down.
> >
> 
> ifdef's should be avoided.  those are only for compile time.

Yep. and when I use them they will be for compile time and sorting the
code appropriate for the architecture.

Anyway, found the answer in that << will actually push in bits from the
left to the right on a little endian system and right to left on a big
endian system (I make it sound like the hardware abstraction in C is a
bad thing) so:

a Uint32 is given the values 15 << 16 | 235 << 8 | 124

If passed to a 4 byte array as *(Uint32 *)arr = i, the values in the
array will be 124, 235, 15, 0 in a little-endian system whereas in a
big-endian system they will be 0, 15, 235, 124.

So, assuming the RGBmask and colorkey are of the appropriate values (and
they should be) all that's required to pass the complete value in this
way on a big-endian system is << 8 whereas a little endian system will
require some byte-swapping too.

Of course, I could just use bit-shifting to pass the appropriate values
one at a time but that would require a lot of checking (at least with 16
bit values) of the RGB masks which I'm trying to avoid.


		
___________________________________________________________ 
Yahoo! Messenger - with free PC-PC calling and photo sharing. http://uk.messenger.yahoo.com