> *p++ = (((uint16)(_r & 0xF8) << 8) | // 1111100000000000 > ((uint16)(_g & 0xFC) << 3) | // 0000011111100000 > ((uint16)(_b & 0xF8) >> 3)); // 0000000000011111 > 5-6-5 display > > looks like your endianess is the issue ;)
Thanks a lot. At least on my machine (Zire 71) an additional byte swap is required on a UInt16 received from the screen bitmap prior to decoding the 5-6-5 fields (I was going the other direction from the example above -- generating RGB from a 16-bit word). For the example above a byte swap would presumably have to be applied to the resulting uint16 before placing it in the frame buffer. I suppose conditionally applying the byte swap based on checking whether the pixel format is 565 or 565LE would be the right way to do it (as is shown in the BmpRsrc.c sample). btw, accessing the bits directly in a bitmap received from WinCreateOffScreenWindow is a big no-no according to the docs, but in this case my app will only run on this one machine with this version of the OS and I need the speed compared to WinGetPixelRGB and its brethren. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
