Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!rutgers!princeton!allegra!ulysses!faline!joevax!sdh
From: sdh@joevax.UUCP (Retief of the CDT)
Newsgroups: comp.sys.mac
Subject: Re: Macintosh programming.  Help!
Message-ID: <372@joevax.UUCP>
Date: Fri, 5-Dec-86 10:05:41 EST
Article-I.D.: joevax.372
Posted: Fri Dec  5 10:05:41 1986
Date-Received: Sun, 7-Dec-86 02:52:54 EST
References: <4501@reed.UUCP> <8419DMB@PSUVMA> 324@apple.UUCP <8718DMB@PSUVMA>
Organization: Bell Communications Research Inc., Morristown, NJ
Lines: 72

> 
>      In 324@apple.UUCP Larry Rosenstein writes ............
> 
>      [Stuff about bit alignment and using a second copybits to handle
>       bit shifting.....]
> 
>      What exactly does this mean? I thought that if the offscreen bitmap was
>  the same size as the original window's bitmap then you wouldn't have any bit
> shifting problems, but maybe i'm not understanding the concept.
> 
>                                              dave
Here's what it means, dave.   In the below examples, I'll use # for bitmap
borders and * for the bitmap bounds rectangle.
Suppose you have a bitmap that looks like this:
		****************################
		* X  X  X      *               #
		* XXXX  X      *	       #
		* X  X  X      *	       #
		****************################
and you want to copy it onto the screen's bitmap using the same size bounds
rectangle, but in a different place.
		###############################...
		#
		#	****************
		#	*	       *
		#	*	       *
		#	*	       *
		#	****************
		#
		.
		.
		.
Well, that's just fine.  CopyBits will do it for you, but it is not an
optimal transfer.  Notice that the destination rectangle is 9 bits further
to the right than the source.  This means that in order to get the bits
to coincide, the source bits will have to be either shifted 9 bits to the
right or 1 bit to the left (equivalent operations for bytes). 
The problem is that CopyBits with have to do a number of shifts for each
byte transferred.  Worst case (4 shifts), it will take about 6-10 times as
long to move each byte [the will be cases requiring shifting out one byte and
into another more often than not], if there were no shifts.  Better yet,
if things line up on byte boundries, the whole block can be moved by word,
instead of by byte (ever wonder why your RowBytes always has to be even?).
So, what you can do is:
1) draw 8 images of your object and have them in their own bitmaps.
2) draw 1 image of your object and let quickdraw generate the other 7
   for you off screen at startup in separate bitmaps.
3) use one bitmap with all the images and change the bounds Rect
   (this will save memory)
How do you know which bitmap to use?  Simple.
you will have 8 bitmaps and you want to refer to them so that the 0th
one will always align on multiples of 8, the 1st on multiples of 8 plus one,
the 2nd on multiples of 8 plus two etc.
The most basic way to do this is to use the MOD function (% in C).

	{ Pascal version: }
	which_map_to_use := destination_horizontal MOD 8;
	/* C version */
	which_map_to_use = destination_horizontal % 8;

This method works fine, but it is faster to do a logical and with 7,
as it is equivalent to MOD 8.
I don't recall how this is done in Pascal (I think the Macintosh Pascals
have a BitAnd function).  In C the process is:

	which_map_to_use = destination_horizontal & 0x7;
	/* I always put constants for logical operations in hex */

Hope this clarifies things.

Steve Hawley
bellcore!sdh