Bounty proposal: Paint
Pages: 1 ... 14 15 16 17 18 19 20 21 22 23 24
|
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.
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) 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:
By the way, 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). |
|
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. |
|
I’m taking another look at the alpha mask / alpha channel stuff. I know I said I’d probably leave it to the end but I think it’s about time I at least enabled the UI to create these sprites. As it’s been years since we discussed this, I’m refreshing my memory and I’ll paste a few relevant comments from Jeffrey here.
The main point to take away from my earlier discussions with Jeffrey is there’s no in-built support for alpha blending that takes the destination pixel’s alpha value into account. This matters especially where I want to support soft brushes that have their own alpha masks (so the brushes have translucent edges). At the moment, as I understand it, relying on the built-in routines would mean there’d be no good way to calculate appropriate alpha values where the translucent edges of those brushes touch the sprite. We certainly don’t want such a brush turning opaque destination pixels translucent (well, except when using the Transparent colour) and conversely, particularly at low opacity selections, we don’t really want transparent areas of the sprite turned completely opaque. I’m therefore convinced that the only way to support soft brushes in a meaningful way is for Paint to have its own pixel by pixel alpha blending routine. |
Pages: 1 ... 14 15 16 17 18 19 20 21 22 23 24