🚀 go-pugleaf

In article <1992Oct6.163937.9771@cs.kuleuven.ac.be> ericl@cs.kuleuven.ac.be (Eric Lafortune) writes:
(on bahalf of tytgat@esat.kuleuven.ac.be)
>
>A WIMP problem this time :
>
>On page 1257 in the PRM we can read about the Message_PaletteChange :
>
>I am particulary interested in the sentence : "Note though that the
>palette utility automatically forces a redraw of the whole screen if
>any of the Wimp's standard colours change their logical mapping, so
>applications don't have to take further action."
>
>Does this mean that when a Wimp program changes a colour in a 16 colour
>mode using "VDU 19, <colour number>, 16, <red>, <green>, <blue>", the
>palette utility automatically issues a redraw of the screen ???
>

I would guess not.

My understanding of this sentence, and from noticong what happans, I
would guess that this only applies to non-16 colour modes.

I have noticed, in 256 colour modes - but I would guess that the same
is true for 4 and 2 colour modes as well - that when changing colours
with !Palette the screen does get redrawn. I would guess that the
sentence means, precicly what it says, that when a logical mapping for
a wimp colour changes the screen is redrawn. This will never happen in
16 colour modes as there is only direct mapping os colours in this
mode (16 wimp colours, 16 totally definable colours available). Only
in 256 colours modes (256 colours from a very restricted palette), and
4 and 2 colours modes is there any logical mapping of colours.

For example, in the standard 256 mode palette and standard wimp
palette, wimp colour 0 (white) will be mapped to screen colour 255 (I
think), but if you make wimp colour 0, say, black - then it will be
mapped to screen colour 0 - needing a total redraw rather than a
simply change to the rgb values the VIDC outputs to the monitor.

This does rather suggest that the palette file, which someone has
already mentioned in a different thread, being simply a series of VDU
19 calls is a little messy. O.K. fine, in a 16 colour mode all you
need to do is treat is as such, but in all other screen types more
complex things need to go on, which will totally ignore half of the
file (ie. the 19,c,16 part) - a bit wasteful.

Ian

Of course this is totally based on my simple understanding, built up
without the help of PRMs - due to a lack of said item for RO3. Ho
Hum.


-- 
                            E-mail : ijp@doc.ic.ac.uk
 ___           __       Snail mail : Department of Computing, Huxley Building,
  /  _   _    /_/ _   / _ _   _  _   Imperial College, 180 Queens Gate,
_/_ (_|_| )  /   (_|_(_| ) )_|/_)    London. SW7 2BZ. England.

ericl@cs.kuleuven.ac.be (Eric Lafortune) writes:

>On page 1257 in the PRM we can read about the Message_PaletteChange :
[...]

>Does this mean that when a Wimp program changes a colour in a 16 colour
>mode using "VDU 19, <colour number>, 16, <red>, <green>, <blue>", the
>palette utility automatically issues a redraw of the screen ???

NO. You should only use the WIMP calls to set the palette when running
on the desktop, I think... I don't think the WIMP traps VDU 19's...

[...]

[...make a red sprite ...]
[...change palette for red colour...]
>Your red sprite will change into a white one.  As you can see there has
>been *no* redraw.  To be sure of that last fact we will issue a
>broadcast message ourselves by :

If you use Wimp colour-setting calls, this shouldn't be a problem.

If not:
  * If you call ColourTrans_InvalidateCache any subsequent redraws should
    do their best to get the colour right given the new palette.
  * Issue your own redraw broadcast
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)