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