Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!bloom-beacon!eru!luth!sunic!kth.se!cyklop.nada.kth.se!news
From: d88-jwa@dront.nada.kth.se (Jon W{tte)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Access to hardware framebuffer (Color QD)
Message-ID: <1990Aug21.182827.19315@nada.kth.se>
Date: 21 Aug 90 18:28:27 GMT
References: <DFS.90Aug20184133@dooby.cs.brown.edu>
Distribution: comp
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 35

In article <DFS.90Aug20184133@dooby.cs.brown.edu> dfs@cs.brown.edu (David Sklar) writes:

>Let's say I want to draw a line in color 0.  I have reason to believe (but no
>proof) that it's not enough for me to simply:

>	1) Set the port's "fgColor" field to 0 
>		(manually, not using a QD routine)
>	2) Call QuickDraw to draw the line.

Actually, that is "set the ports RGBFgColor to the value of X"
fgColor is old-style color, with only 8 predefined colors available.

On a 24bit deep screen, this will work:

	RGBForeColor(&colors[index]);
	MoveTo(x1, y1);
	LineTo(x2, y1);

If you don't have a 24bit deep screen, you'll have to resort to something
called "Animated Colors" (and hope the hardware supportsit, most 8bit
h/w actually does) OR hope for the best with tolerant colors with a
tolerance of 0.

IM V should help you along.

>Of course, there's no way to for me to verify that a 0 was not placed in the
>hardware FB.  But I believe my pixel values are getting mapped to different
>numbers, because XOR'ing is not working as one would expect.  For example, 

You want to XOR into video index memory !? You'll have to blast the
bits yourself. This gets VERY complicated VERY fast (like, don't forget
to switch the computer into 32bit mode if 32bit QD is running &c)

								h+
	Jon W{tte, Stockholm, Sweden, h+@nada.kth.se