Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!jade!ucbvax!nutmeg.Berkeley.EDU!deboor From: deboor@nutmeg.Berkeley.EDU.berkeley.edu (Adam R de Boor) Newsgroups: comp.windows.x Subject: Re: (none) Message-ID: <22182@ucbvax.BERKELEY.EDU> Date: 16 Dec 87 00:27:57 GMT References: <8712151835.AA12160@blackstone> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: deboor@nutmeg.Berkeley.EDU.UUCP (Adam R de Boor) Organization: University of California, Berkeley Lines: 36 In-Reply-To: <8712151835.AA12160@blackstone> the byte_order of LSBFirst means that the image is presented with the least-significant byte lowest in memory. This is the order VAXes use and the order in which 'bitmap' outputs its bitmaps. If you are running on a 68000-order machine, you would have to swap all the bytes (in longword units, I believe) in order to get integers you could then manipulate using your favorite bit-manipulation constructs in your favorite language. the bitmap_bit_order of LSBFirst means that the leftmost pixel is in the least significant bit. Thus (these are for the bitmap_scanline_unit of 16, not 32 (32 won't fit on the screen 8)): byte_order/bitmap_bit_order L/L 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Pixel # 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Bit # 0 1 Byte # L/M 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Pixel # 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Bit # 0 1 Byte # M/L 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Pixel # 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Bit # 0 1 Byte # M/M 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Pixel # 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Bit # 0 1 Byte # Leastways, this is how I understand it. a