Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!TMASL.EXXON.COM!FERGUSON
From: FERGUSON@TMASL.EXXON.COM
Newsgroups: comp.sys.apollo
Subject: RE: GPR Colour Maps
Message-ID: <8907051320.AA03260@umix.cc.umich.edu>
Date: 5 Jul 89 13:15:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 25


My experience with GPR and color maps is as follows:

     I know that changing a color map requires that the display is
     acquired. Otherwise, you'll get a status error back.

     The arguments for gpr_$set_color_map(start,num_entries,map,status);
     are kind of funny. The 'start' is a long (or 4-byte) integer, the
     'num_entries' is a short (16-bit) integer, the 'map' is an array
     of long integers, and status is finally a status_$t, or 4-bytes.

     These calls were all built back when the 68010 had only a 16-bit
     data bus, so two-byte integers were used whenever possible to save
     time (this is my theory, not gospel). Since then, for compatibility,
     the two-byte/four-byte conflict has continued. With FORTRAN code,
     it creates a problem in keeping code standard, because fortran
     doesn't know about integer*2 or *4.

Anyway, those have been my common problems with gpr_$set_color_map.
The only other thing I can think of is not including the insert file,
but that would give access violations in everything you try.

Scott Ferguson
ferguson@erevax.bitnetr
                      minus the 'r' -- VMS doesn't have a .signature ;-(