ECF oddity

After being annoyed/confused by it for quite a while, I’ve finally got to the bottom of why the background pattern Paint draws behind masked sprites looks so funny in 32K and 16M colour modes.

The problem is that in 32K modes Paint assumes that ECF patterns are 1 pixel wide and 4 pixels tall, and in 16M colour modes it assumes it’s 1 pixel wide and 2 pixels tall (see psprite_set_default_translations). This would make sense when you consider that you’ve only got 8 bytes to define the pattern in. But after checking the PRM, there’s no mention of how ECF patterns have been updated for 32K/16M colour modes. And after tracking down the relevant bit of the kernel source it looks like there’s no mention of how ECFs were updated because ECFs weren’t updated! Each byte of the 8 byte ECF block is treated as a separate row of the ECF pattern, and the byte is simply replicated four times to fill a word (and each word will then later be transformed into two words to create the OR-EOR block pattern that’s actually used for rendering). Replicating bytes to fill a word works great for <=8bpp screen modes, but for 32K and 16M colour modes it’s less than ideal. So in Paint’s case where it’s trying to draw alternating black and white lines, in 32K colour modes you end up with two black lines followed by a whilte line followed by a pinkish line, and in 16M colour modes you end up with five black lines followed by three white lines. And if the OS should ever need to run on hardware that always performs alpha blending for the desktop overlay this ECF configuration would be useless, as in 16M colour modes you’d need to set all the ECF bytes to 255 to make sure the alpha channel is set correctly.

So unless anyone has any complaints, I’m planning on fixing the kernel to treat the ECF block how Paint expects – so that in 16bpp modes it’s treated as a 1×4 image and in 32bpp modes it’s treated as a 1×2 image.

I wondered why the mask was so strange-looking! Sounds like a very useful fix.

Fix now checked in.