OS_SpriteOp and 32bpp sprites

[Kevin Bracey]

In message <f75f46974b.Tony at mk-net.demon.co.uk>
          Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:

> On 17 Nov 2002, in message <4b96e1f336jdclark at argonet.co.uk>,
> John Clark <jdclark at argonet.co.uk> wrote:
> 
> > When using OS_SpriteOP with reason codes 41 and 42 to read and write
> > pixel colours in a 32 bpp sprite it seems that R5 contains the 24 bit RGB
> > value and R6 (tint) is not used, though I can't find this clearly stated
> > in the PRMs.
> > 
> > The OSLib calls for these reason codes, osspriteop_read_pixel_colour and
> > osspriteop_write_pixel_colour take an os_gcol type for the colour value
> > to go in R5.  However, this is a byte value and so will not take the 24
> > bit RGB value.
> > 
> > Have I missed something, or does OSLib need extending to cover 32 bpp
> > (and 16 bpp?) sprite colour reads and writes?
> 
> It certainly looks as if you're correct. I guess it never got updated when
> deep sprites were introduced. 
> 
> So, at the next update, I'll add osspriteop_read_pixel_colour_deep and
> osspriteop_write_pixel_colour_deep taking an unsigned int type for R5 as
> alternatives to these calls.

There should be no need to make an alternate call, as with the current
callee-narrowing argument passing conventions, the compiler would always have
just passed a word-wide value anyway, regardless of the fact that the
function took a char. It would have expected the callee to do any required
narrowing.

So, there should be no problem with just changing the prototype.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/