Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!teehee.dallas.sgi.com!fouts
From: fouts@teehee.dallas.sgi.com (Chris Fouts)
Newsgroups: comp.sys.sgi
Subject: Re: getmcolor() on VGX's
Message-ID: <1991Jun25.191922.7763@odin.corp.sgi.com>
Date: 25 Jun 91 19:19:22 GMT
References: <1991Jun24.142930.29853@ux1.cso.uiuc.edu>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: fouts@teehee.dallas.sgi.com (Chris Fouts)
Organization: Silicon Graphics, Inc. (Dallas)
Lines: 87

In article <1991Jun24.142930.29853@ux1.cso.uiuc.edu>, marcc@yoyodyne.ncsa.uiuc.edu (Marc Cooper) writes:
|> 
|> 
|> 
|> Here's an interesting little problem:
|> 
|> 
|> It was recently my pleasure (right) to convert an 8 bit GL program to 24 bit.
|> Wanting to take the path of least resistence, thus freeing me from redoing
|> all the nifty pallette manipulation stuff that was already there, I 
|> simply wrote a routine I called rbgcolor() that took the place of color()
|> 
|> 
|> It looks something like the following:
|> 
|> rbgcolor(int index)
|> {
|> 	short r,g,b;
|> 
|> 	getmcolor(index,&r,&g,&b);
|> 	RGBcolor(r,g,b);
|> }
|> 
|> 
|> wallah!  24 bit color! (This was madified to do lighting and depthcuing and 
|> other stuff, so it isn't quite as pointless as it looks..)
|> 
|> Anyway, it works just fine on my PI.  But when I go run it on a VGX, the
|> r,g, and b values all come back 0.  There was something in the manual about the
|> last 256 entries in the map being used for gamma corrections, but I'm starting
|> my map at 512 (just after the system colors).  And again, this works just fine
|> on a PI.  It fails on VGX machines.
|> 
|> Any hints, clues, etc?

If you try to read the colormap from an RGB window on a VGX it will fail (after
all, it's an RGB window--not a colormap window).  You can get around this with
something like (untested code follows :^):

in_your_graphics_initialization_routine()
{
        extern long map_id ;
        ....
	noport();
	map_id = winopen( "noshow");
        ....
        /* open your other windows */
        ....
}

rbgcolor(int index)
{
	short r,g,b;
        extern long map_id ;
        long prev_id;

        prev_id = winget() ;     	/* save previous window ID */
        winset( map_id ) ;		/* set to noport colormap window */
	getmcolor(index,&r,&g,&b);	/* read the colormap */
        winset( prev_id ) ;		/* restore previous window ID */
	RGBcolor(r,g,b);
}


This should work since the map_id window is a colormap window (even though
it isn't mapped).  Of course, you'll take a slight performance hit with the
extra calls.

Alternatively, you could write your own routines that store the map color
values in your own local table, and reference the colors from that.

-- 

Chris Fouts				Email:  fouts@dallas.sgi.com
Systems Engineer			Phone:  (214)-788-4122
Silicon Graphics Computer Systems	Vmail:	8714
Dallas, TX

'The GFX-100 looks like an outdoor satellite "dish," but works indoors
 like ordinary "rabbit ears." You pay NO cable fees because you're NOT
 getting cable!!!  You pay NO satellite fees because you're NOT using
 satellite technology or service!!! Works entirely via proven "RF"
 technology--actually pulls signals right out of the air....Not
 technical razzle-dazzle but the sheer aesthetic superiority of its
 elegant parabolic design make the GFX-100 a marketing breakthrough.'

			-- Ad for GFX-100 Indoor TV "Dish" Antenna.