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. |
|
Oh yes! :D 3. There’s a very strange bug, when Opacity < 255, where the first click of the brush results in the brush sprite being plotted 8 pixels (usually) offset to the right. Subsequent plots always work normally (e.g. drag the mouse 1 pixel over and it will plot correctly, regardless of zoom level). I’m working on a test program to try and isolate the cause of this bug. I’ve finally figured out the cause of the above bug. Some experimentation revealed that swapping output between my layer sprite and the screen multiple times gave slightly different values for the start of screen memory (reading the VDU variable). Specifically, the first time output was switched to my sprite, the address was off by a small amount. Every time after that, the address was correct. I noticed the amount of the sprite’s misalignment seemed to vary according to the number of colours of the brush sprite. I wondered if a palette or translation table was overflowing its memory and corrupting my sprite pointer (I couldn’t find anything obvious). I even began to wonder about a bug in the VDU code. It turned out in the end that I got bitten by the flex memory management. I figured it out when I finally noticed the address of my sprite itself was changing inside the brush plot function. The change seemed to happen when the brush translation tables were being recreated. I confirmed it for sure by adding a Watchpoint to my sprite file struct in DDT and it alerted me that the pointers changed the moment one of the translation tables was flex-freed. I’ll bear this in mind when I’m looking at the rest of the code as it could possibly have been a source of other crashes in Paint in the past. Phew, onto the next issue! =) |
|
Excellent! Is this also likely to be the source of the longstanding crashes when using brush sprites in general? |
|
Is this also likely to be the source of the longstanding crashes when using brush sprites in general? This particular bug isn’t the source of those crashes because it was caused by code I wrote. It’s certainly possible that a similar set of circumstances could have made Paint crash in the past when painting with the brush, however so far I’ve not seen evidence of that in the code. For flex to move the sprite far enough in memory for a plot to fall outside the sprite’s bounds and cause a crash, I suspect something large (like another sprite) would need to be deleted, unless you’re working with a small sprite when the crash happens or painting right at the edge of the sprite. In the latter case, it’s likely we’d have seen misaligned brush plots as well. Are you still experiencing the crash? |
|
Yes, although (as ever) it’s not clear exactly what circumstances provoke it. It’s only with the brush tool. From memory, sometimes pressing OK in the toolbox (to select the new brush sprite) crashes it, sometimes attempting to paint with the new sprite brings everything down. I’ll try to look into this, and see if I can narrow down when it’s happening. |
|
Are you still experiencing the crash? At the risk of sounding like a broken record, when you catch it happening, please could you get me the output of the following commands?: *where *showregs *memoryi pc -40 +80 *modules The first two are the most important. If the machine’s unresponsive of course, at least writing down the error message would give some clue what’s going on. |
Pages: 1 ... 14 15 16 17 18 19 20 21 22 23 24