OS_ReadPoint

[Christian Ludlam]

On 16 Jan Tony van der Hoff wrote:

> Christian Ludlam <chris at recoil.org> wrote in message
> <bf5b53714c.christian at venice.lab>

> > os_read_point claims to return an os_gcol, which is a byte wide. This may
> > have been true on RISC OS 3.1, but it seems that later versions return
> > the actual 15 / 24 bit colour in appropriate screen modes.

> > I don't know if there's already a type for this - it's not an os_colour.

> Thanks, Christian. First, despite some fairly extensive searching, I have
> not been able to find any authoritative reference to corroborate this. Have
> you got any (apart from pragmatic observation)?

No, I haven't. I did trawl through the PRMs to find an update, since there
apparently isn't another way to read the pixel colour. Try this:

REPEAT:MOUSE X%,Y%,Z%:SYS "OS_ReadPoint",X%,Y% TO ,,C%,T%:P. ~C%,T%;:VDU
13:UNTIL 0

> Secondly, if not an os_colour, what is the format? Are you suggesting that
> we define a new type for this, which will entail defining a new swi call -
> say os_read_pointw?

In a 32bpp mode, it's &00BBGGRR. In 16bpp mode, %0BBB BBGG GGGR RRRR. I've
just realaised that there already is a type for this - os_colour_number,
which is what ColourTrans_ReturnColourNumber returns.

However, in the bizarre world of a 256 colour mode, this call instead returns
a GCOL number and a tint, as the current implementation.

> Whilst I'd be quite happy to add this call, I'm not entirely sure on how to
> implement it. Does anyone else have any suggestions?

I'd suggest it probably would be better to add os_read_pointw as you suggest,
returning an os_colour_numer. It needn't bother about the tint, which is
always 0.

-- 
Christian Ludlam
chris at recoil.org