In a comment to the previous log, @de∫hipu suggested relaxing the requirement that the userdata bits have no influence on the visible color, in exchange for getting more colors for smooth gradients. In other words, going from the left palette to something like the right one in the picture below (rearranged to show the periodicities more clearly).

The bitwise interpretation then becomes

where the lower bits of darkness and hue may be used as userdata.

I gave this a try and tested it both with a dedicated program that blinks the userdata bits on all colors of the palette and with the Sokoban game. The results were: A shift of 8 (the higher userdata bit) is visible everywhere. A shift of 4 (the lower userdata bit) is hardly visible in the brighter colors, more so in the darker ones. In the Sokoban game, the difference is not noticeable in the red/green, green, and red color schemes. It is noticeable in the yellow and orange schemes. (In the red scheme, there is still strictly no difference, the colors are still repeated. This is because I want a color scheme that is full red, but it can’t start at the very end of the hue spectrum, because there still needs to be room for the userdata shifts.)

This looks promising, but the decision is not entirely clear. It becomes a question of priority – what is more important, better gradients or strictly invisible userdata? Thinking about it, I now tend towards the former. The gradients may come in handy e.g. in the Maze3D game, where I want to show depth as darkness, whereas using the frame buffer for userdata storage was a bit of a hack anyway – a nice trick to simplify a tutorial, but not a model to follow in more complex projects.

Let’s keep this change for now and see how far we get. As a side effect, there are now 13 instead of 4 single-hue schemes, more finely granulated by hue. I didn’t update the tint.py scheme selector though.

(To explain the title, there are now 197 distinct colors in the default palette. In the previous one, there were 145.)