Bounty proposal: Paint

A pixel translation table is an array with one entry for each source colour.

Except going to 32K modes where it is a guard word, a pointer to a table held elsewhere, and another guard word, and even more messy going to 16M modes.
There’s a table and description in PRM 5a on page 5a-120 (or p134 in the document).

but I wrongly thought a transfer function gets used in addition to the table lookup (for rendering)

This seems to imply that it can… https://www.riscosopen.org/wiki/documentation/show/Colour%20Mapping%20Descriptor

but I wrongly thought a transfer function gets used in addition to the table lookup (for rendering)

This seems to imply that it can… https://www.riscosopen.org/wiki/documentation/show/Colour%20Mapping%20Descriptor

When calling OS_SpriteOp, you can supply a transfer function or a lookup table, not both.

If you want to render using both a transfer function and a lookup table, you need to supply the transfer function to ColourTrans when it’s generating the table. This will generate a lookup table with the effects of the transfer function “baked in”. The generated table doesn’t contain any references to the original transfer function, so changing the properties of the transfer function after the table’s been generated will have no effect on that table.

I think there is one edge case to be aware of, which is that sometimes ColourTrans will decide not to return a translation table (e.g. if the source and dest are identical modes & palettes, or the source and dest are both true-colour), and that decision is made without looking at the transfer function. So if you pass a transfer function into ColourTrans, and ColourTrans doesn’t return a translation table, then you’ll have to instead pass the transfer function into each OS_SpriteOp call.

Here’s a new test build for the Brush Tool Enhancements.

As before:

It’s an ArcFS archive. The !Paint program is inside Paint.debug, built for IOMD (Risc PC / RPCEmu) but you can build from source if you want to. My code’s still a little messy as I haven’t ironed out all the issues yet.

• I’ve fixed the issue where Shape / Stamp / Tint wasn’t working correctly with > 256 colour sprites (a Colour Mapping Descriptor is now used when necessary).
• There should now be less flicker over the tools window when selecting a different brush (it no longer forces a redraw of the whole window).
• Previously you could drag the mouse past the end of the opacity slider bar, making it hard to select full Opacity. This is now fixed.
  

By the way, sorry for putting these builds on a site that needs Javascript for you to download them!

sorry for putting these builds on a site that needs Javascript for you to download them!

Oh my god.

Firefox that makes it easy to look at every fetch that was made, so it’s usually possible to extract the actual download links (useful for Github, Drive, etc).
This one is https://public.boxcloud.com/d/1/[...]./download where the ‘…’ is about a thousand characters of random gibberish that probably encodes the filename, owner, your IP address, the time, the time in Martian, the Julian date, the phase of the moon, and the current number of people known to be infected by the modern plague.
Jeez.

I just got brush painting with the transparent colour working again.

I’ve noticed one downside of making use of blend tables / inverse tables for brush opacity. Draw some transparent strokes on the image. Then choose a solid colour and, with Opacity turned down, paint bands of it across the transparent strokes. When the temporary layer is merged down, the intersecting areas are the wrong colour. It’s obviously blending with the RGB colour of the bottom sprite, ignoring the fact that those pixels are masked as transparent. I don’t think there’s any easy way around that. To minimise the effect it might be worth seeing if we can paint the RGB colour in a neutral grey when painting areas with the transparent colour (at the moment Paint doesn’t care what colour it ends up).

I’ve noticed one downside of making use of blend tables / inverse tables for brush opacity. Draw some transparent strokes on the image. Then choose a solid colour and, with Opacity turned down, paint bands of it across the transparent strokes. When the temporary layer is merged down, the intersecting areas are the wrong colour. It’s obviously blending with the RGB colour of the bottom sprite, ignoring the fact that those pixels are masked as transparent. I don’t think there’s any easy way around that.

Talking to myself, there’s one way around it, but it adds a few extra steps to the merge which may introduce a delay.

The flood fill tool, when filling from transparent to a solid colour, works by temporarily inverting the sprite’s mask so it can then plot the transparent parts of the mask onto the sprite in the solid colour (afterwards it inverts the mask back to its normal state). We could do the same thing here to make sure any transparent pixels that are being painted over will be in the currently selected RGB colour. It would introduce two CLG operations and an extra plot. Maybe I can make use of OS_ChangedBox to cut down the size of the sprite being updated.

I think even this fix will have a side effect. Suppose the sprite has a white background, and you paint a green translucent line across the white background and across a transparent region. When the blending happens, the above fix would make the region that was transparent come out in a more saturated green than the area that was white. Still, when we’re not using alpha masks or channels I don’t think there’s a single right answer for this.