cycy@isl1.ri.cmu.edu (Scum) (08/28/90)
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.
Can somebody help me? I'm getting quite frustrated....
-- Chris.
(cycy@ri.cmu.edu)
printf statements have been removed. ptr->on_colour is an unsigned long.
...
...
...
...
if (flag & PCOLOURS) {
unsigned short red, green, blue;
czclear(0x00000000, 0xffffff);
zbuffer(FALSE);
shademodel(FLAT);
lmbind(MATERIAL, 0);
for (ptr= obj_inst; ptr != NULL; ptr = ptr->next) {
short r,b,g;
unsigned char cr, cg, cb;
green = (short) ((ptr->on_colour>>8) & 0x0ff);
blue = (short) ((ptr->on_colour>>16) & 0x0ff);
red = (short) (ptr->on_colour & 0x0ff);
fprintf(stderr, "red = %d, green = %d, blue = %d\n", red, green, blue);
RGBrange(red, green, blue, red, green, blue, -1023, 0);
cpack(ptr->on_colour);
(ptr->d_funct) (ptr);
cmov(ptr->params[0].arg,ptr->params[1].arg,ptr->params[2].arg);
readRGB(1,&cr,&cg,&cb);
}
RGBrange(0, 0, 0, 255, 255, 255, -1023, 0);
zbuffer(TRUE);
shademodel(GOURAUD);
}
}
--
-- Chris. (cycy@isl1.ri.cmu.edu)
"People make me pro-nuclear." -- Margarette Smithbennett@sgi.com (Jim Bennett) (08/29/90)
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)
kurt@cashew.asd.sgi.com (Kurt Akeley) (08/29/90)
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
cycy@isl1.ri.cmu.edu (Scum) (08/30/90)
Well, Kurt and Martin (who sent me e-mail... thanks) got it right.
Gavin Bell refered me to David Ligon, who explained the problem and its
solution very well as follows:
->If Chris is using cpack(0x01f) on a PI in double buffer here is what he gets:
->-----------------
->| A | 0 |
->----------- BLUE
->| B | 0 |
->-----------------
->| A | 0 |
->----------- GREEN
->| B | 0 |
->-----------------
->| A | 1 |
->----------- RED
->| B | f |
->-----------------
->
->Where only the higb nibbles (A) are used. The syntax for cpack is:
->cpack(0xAABBGGRR) where alphs, blue, green, and red are byte sized portions.:^)
->
->Now when the readRGB call is made (I assume Chris packs the RGB data which is
->not necessary if the lrectread command is used) he gets 0 for blue, 0 for green
->and 11 for red as the high order bit is duplicated on read.
->
->I believe that if Chris picks colors that have high order bits and compares
->them to duplicated nibble colors his scheme will work. cpack(0x00102030)
->compare the packed readRGB on the PI to 0x00112233. Or return the lrectread
->value to 0x00112233 (this also replicates high nibbles).
-> || ||
-> || ||
-> || ||
-> () ()
-> || ||
-> || ||
-> xx| |xx
-> (__=_) (_=__)
->--dbl@legman.esd
->
->
So thanks again for the responses!
-- Chris.
--
-- Chris. (cycy@isl1.ri.cmu.edu)
"People make me pro-nuclear." -- Margarette Smith