Paint won't accept a palette file

I’m fairly certain it only looks at the primary colours.

OK, there’s something seriously weird going on with the translation table in Paint then. It’s annoyingly hard to pin down, as it’s only apparent as an after-effect of this bug where Edit Palette was changing two of the colours.

For example:

• I make a 256 colour sprite with the full 256 colour palette.
• Initially sprite→transtab→table[ 255] = 16777215, the RGB colour in the palette is (&psprite_address (sprite)→mode + 1) [2*255] = -240 (that’s supposed to be white).
• I edit colour 255 to be black. The palette gets rearranged to be artist-friendly, but the colour picker changes the new colour 255 to black as well (the bug mentioned earlier).
• However, after Paint regenerates the translation table from the updated palette:
  sprite→transtab→table[ 255] = 16777147 (that’s the turquoise colour in the bottom right, 215 before the remap) (&psprite_address (sprite)→mode + 1) [2*255] = 0 (so the palette value is now black and doesn’t match the translation table entry!).
• If I change the desktop screen resolution to force the translation table to be generated again:
  sprite→transtab→table[ 255] = 0 (black! Why’s it behaving itself all of a sudden?) (&psprite_address (sprite)→mode + 1) [2*255] = 0 (black so the palette and translation table finally match up).

This all seems to go away when I fix the bug that changes two colours in the palette instead of one. It’s just weird and annoying that the translation table should end up with different colours at index 255 when the palette shouldn’t have changed between calls. I’ll stop obsessing about it too much. There are more important things to do.

P.S. the forum seems to screw with square bracketed indices even inside a “pre” tag!

Edit: Just corrected the first translation table value. I wrote this post in a hurry!

It’s just weird and annoying that the translation table should end up with different colours at index 255 when the palette shouldn’t have changed between calls.

Causality is no longer being violated and the spacetime continuum is safe! It makes perfect sense now. RISC_OSLib’s dboxtcol colour picker calls the supplied event handler, Paint’s Apply_Colour() function, before RISC_OSLib alters the value at the colour pointer. So the palette did change between calls. Another case of insufficient coffee. :)

Another case of insufficient coffee. :)

That’s where you’re going wrong. Everything is better with tea. ;)

Original size: https://i.imgur.com/Ei324Fp.jpg

That’s where you’re going wrong. Everything is better with tea. ;)

Er, no. I discovered 30-odd years ago that the stuff makes me ill. I’ve been fuelled by coffee ever since.

Aldershot…

Aldershot…

Naturally.