On 16/04/2013 20:59, Dilwyn Jones wrote:
Wolfgang Lenerz wrote:
100 COLOUR_24
110 WM_PAPER #0,$FFFFFF : REM trying to set white
120 WM_INK #0,$0000FF : REM trying to set blue
In these lines, the top word will be ignored, even though he won't get
blue but some kind of stippled colour in line 120.
Most likely that's incorrect memory on my part - have asked him for the
actual values used.
(the $ffffff will be trated as $ffff, i.e. a 15 bit rgb colour and the
code for that will, in the end ignore the upper word.
Even though it's a WM_xxxx command? Would they still use the 16 or 24
bit values even though it should have a system palette colour reference
$02xx?
The definitions for the colour word are set out in the documentation
%00000000cccccccc exactly as before
%00000001pppppppp palette
%00000010pppppppp system palette
%00000011gggggggg gray scale
%00000100cc00tttd 3d border (border calls only!).
%01ssxxxxxxyyyyyy palette stipple. see below
%1rrrrrgggggbbbbb 15 bit RGB
As you san see, since in $ffffff bit 15 is set, this will be treaated as
a 15 bit RGB value. I've looked at the code, this will ignore any value
in the upper word.
The $00ff will be treated as a normal Ql colour since the the upper byte
of the lower word is 0).
Which is the "exactly as before" above.
If you look at the code (in ee_wman_trap3_asm) you will see that first a
test is made whether this is a 15 bit rgb colour, then whether this is a
palette stipple, then whether this is an "old" colour, then a palette
colour, then a system palette, then gray colour, then 3d border colour.
Have had problems with some 3d borders before (and discussed it with
Marcel some time ago) - usual sympton drawing triangles from top and
bottom which overlap in the centre of the window and freeze the program
instead of just drawing the 3d border.
Well, the format is well-explained.
Without knowing what colour is passed, we can't know happens...
Wolfgang
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
