🚀 go-pugleaf

In a previous article koster@cory.berkeley.edu writes:
> Why don't I just modify the copper list to change the color tables?

Ok, I got a lot of advice telling me this was wrong, and some of it from
C-A officials. So I worked around it by living with the LoadRGB4 and only
displaying the View it works on while I am changing color tables.

The way LoadRGB4 seems to work is:

It is given a viewport structure as input. It looks into the
vp_dspins field to find a CopList. Then it looks into the
cl_CopLstart field to find the LOFlist that is also duplicated in the
LOF field of the View structure.

Since I effectively have three Loflists, and Loadrgb4 takes a viewport as
input, it only does its magic on the last mrgcop or makevport call.

Perhaps if I update the cl_CopLstart field in the viewport's vp_dspins
coplist, THEN call Loadrgb4, I would be able to modify an arbitrary View's
color map. However, this is just as bad as modifying the copper list myself.

It would be nice to have a command like COPLoadRGB4(cprlist,table,count)
Which would take a cprlist and modify its colortable registers.
This wouldn't cost anything extra, as the existing LoadRGB4 could just call
it.

Are screens viewports? And is the intuition/workbench display a view?
Why are there two blank lines between screens, when the RKM #1 says there
only needs to be one between viewports?