Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!mhuxo!mhuxt!mhuxi!mhuxh!mhuxu!att!pacbell!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: bitmaps with intuition...
Message-ID: <56628@sun.uucp>
Date: 15 Jun 88 16:59:11 GMT
References: <4370@gryphon.CTS.COM> <3170@charon.unm.edu> <56215@sun.uucp> <6261@well.UUCP>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 53

In article <6261@well.UUCP> (Leo 'Bols Ewhac' Schwab) writes:
->In article <56215@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
->>[ Chuck McManis attempts to help. ]
->
->	Hans specifically said 'window'.  Chuck's dissertation is correct
->for screens and BitMap structures.  However, a window is a superset of a
->layer, and layers can be anywhere on the screen.  Layers can also be
->obscured.  There is severe voodoo involved in figuring out what the status
->of a window's position and visibility is.  For an example of what you're
->looking at, check out 'DropShadow'.

Well clearly the workaround is to call WindowToFront, wait for it, then
LockIBase and play with the bitmap pointers :-). 

>	What precisely are you trying to accomplish?  
>Leo L. Schwab -- The Guy in The Cape  ihnp4!pacbell -\

The best part of his response was the ultimate question. 

But then Berry chimes in with :
In article <211@hor-res.UUCP> berry@hor-res.UUCP (No comment) writes:
>Given: a 320x200 screen by 3 planes deep.
>Ok now, for each plane in memory there are 320 bits by 200 bits or
>64,000 bits. In bytes that is 8,000. For three planes that's 24,000. ...

This part is correct.

> ...you would start at bitmap[0] combine it with the pixel 8,000 bytes
> away at bitmap[8000] and then finally with bitmap[16000]. This would
> get you the Value of the color register that will be displayed as the
> pixel color when the Amiga displays this pixel.  Whew, a mouthfull
> that was.
>-Steve Berry- ...!bunny!hor-res!berry

This part is terribly flawed. Allocation of bitmap memory goes something
like :
	for (i=0; i<Depth; i++) {
	    bitmap.Planes[i] = (PLANEPTR)AllocMem(RASSIZE(x,y),MEMF_CHIP);
	    if (!bitmap.Planes[i]) barf_on_error("No chip RAM");
	}
Which can allocate the bitmap data areas *anywhere* in chip RAM where there
is room. Using Berry's technique of adding 8000 to the first plane pointer
is *not* reccomended. [Side note the RASSIZE macro is a nice thing and can
be used to determine the number of bytes per line with RASSIZE(x,y)/y .]

The rest of his posting was similar to mine in that it ignored the effects
of layers on where the window contents really were. These techniques do
work on screens an SuperBitmap windows but not on obscured 'regular' 
windows.

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.