Transparency index v rgb
Hi, I've suspected this for some time, but just confirmed it, after it came up in Dev chats.
The global transparency colour is applied as an 8bit RGB value by the hardware when combining layers.
However sprites, and the next basic tile and layer copy functions, apply transparency using the same global transparency value but use it as a palette index. The RGB value of an index has no effect on its transparency.
So if you set pallete index 227 (default transparency) to be, say green, those green pixels won't be rendered, even though global transparency is set to a shade of magenta (454 9bit). On the other hand, if you set palette index 0 to 454 (the 9 bit transparency rgb value), any pixels with pallete index 0 will be rendered over any existing pixels, and then be transparent rather than magenta, allowing under layers to show through.
I'm not sure if this is by intent or not, or indeed, if it's realistically changeable anyway, without breaking stuff, but the different behaviour probably needs documenting, if it's not an issue.
It seems to me it is an issue because any pixels which use the same palette index as the global transparency rgb value will not render. And changing it to avoid that will instantly effect the RGB based merging of layers until it is changed back.
It seems to me that these 2 transparencies should have separate values as they have two separate incompatible meanings. One by RGB for hardware layer rendering, and one by palette index for tiling, blitting, and sprites.
The latter could be set in the same way the random flag is set, and default to a value which says to use the RGB value, unless changed. This would resolve the incompatibility without breaking changes, in basic. There's might still be an issue with sprites, so maybe it should be a new nextreg value.