Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!sgi!shinobu!odin!cashew.asd.sgi.com!kurt
From: kurt@cashew.asd.sgi.com (Kurt Akeley)
Newsgroups: comp.sys.sgi
Subject: Re: putting and retrieving colours...help!
Message-ID: <1990Aug28.191700.7829@odin.corp.sgi.com>
Date: 28 Aug 90 19:17:00 GMT
References: <10335@pt.cs.cmu.edu> <1990Aug28.174521.5752@odin.corp.sgi.com>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: kurt@cashew.asd.sgi.com (Kurt Akeley)
Organization: sgi
Lines: 29

In article <1990Aug28.174521.5752@odin.corp.sgi.com>, bennett@sgi.com
(Jim Bennett) writes:
|> In article <10335@pt.cs.cmu.edu> cycy@isl1.ri.cmu.edu (Scum) writes:
|> >I'm having a very vexxing problem right now. I'm in doublebuffer, RGB mode.
|> >In the backbuffer, I draw an object in 3-space with 0x01f as it's colour.
|> >Just before this, I turn off lighting mode by binding the material to 0,
|> >set the shademodel to FLAT, and even turn off zbuffering. What I get
immediately
|> >back, however, is 0x11 ! To get the colour of the pixel, I cmov to a
position
|> >where I drew the object, and use readRGB.
|> 
|> In the example you gave, the RGBrange command will override the color
|> command, so the color will be determined by the Z value.
|> 
|> Jim Bennett			(bennett@esd.sgi.com)

it's true that the RGBrange command will override the cpack command, but
it does so with the same value, because it is specified with near and far
colors equal, based on the same values passed to cpack.  thus the RGBrange
command is not the problem.  more likely, you are using a machine (such as
a Personal Iris) that stores only 4 bits per color component when in
doublebuffer RGB mode.  such machines store only the 4 MSBs of each component,
and replicate this nibble into the 4 LSBs when read back.  this would nicely
explain why 0x1f became 0x11.

	0x1f is stored as 0x1x, then returned as 0x11

-- kurt