putting and retrieving colours...help!
Kurt Akeley
kurt at cashew.asd.sgi.com
Wed Aug 29 05:17:00 AEST 1990
In article <1990Aug28.174521.5752 at odin.corp.sgi.com>, bennett at sgi.com
(Jim Bennett) writes:
|> In article <10335 at pt.cs.cmu.edu> cycy at 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 at 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
More information about the Comp.sys.sgi
mailing list