Slug fonts don't display all colors specified by SetColor.

[DewiMorgan]

Using SetColor() on a Label sets the color as it always has.
Using GetColor() gets the exact same color values as were set.

PROBLEM

When you look at the image, there are hues which are displayed incorrectly, even though GetColor() claims they're the correct color. For example:

0x000000 to 0x060606 all display as 0x000000
0x070707 to 0x111111 all display as 0x0d0d0d
... etc.

I count about 75 hues on each color channel as unavailable, for about a half million unavailable hues.



The above image shows three blocks of X, which have two of the color channels (R, G, B) set to 0x7F, and the remaining channel progressing from 0 to 255.

The left block varies Red, middle varies Green, and right varies Blue.

I've marked up the Red block to show the X glyphs that have the exact same RGB values.

Grayscale behaves the same way:



CAUSE

This is likely to be a side-effect of Slug fonts, since the issue started in that update, so may not be easily resolvable.

It is not an antialiasing effect, as I chose the X characters specifically as they have a 4x5 area in the center of all the same color.

It is not a compression artifact, as it's viewable on the game screen in realtime by using a color picker tool. I've saved the screenshot as PNG to avoid compression artifacts.

WHY IT MATTERS

It doesn't. The unavailable colors probably can't be distinguished from the available ones with the naked eye.

I'd written a script to switch between characters using hotkeys, with an addon displaying the current character ID (1 thru 20) as the red channel of a label showing "." (period). But even for that use case, I can just work around the problem by adding 0x80 to the character ID.

CODE TO REPRODUCE

This code produces the above image.

XML: https://pastebin.com/mFSKUhM9

LUA: https://pastebin.com/UtF24x1z

I tried to make this as minimal as possible and still demonstrate the issue.

The code looks spammy, but it's all just the same line repeated 768 times with the different RGB values.

In both files, you can delete all repetitions except the first for a truly minimal test case, though then you'll need to vary the color manually, with a /reloadui for each change. Probably easier to leave it as it is, displaying the whole matrix.

[DewiMorgan]

Oooh.

75 colors unavailable means 256-75=181 colors available per channel.

181*181 = 32761. That's a suggestive looking number!

So with this limitation, they can store two channels in 7 bits instead of 8.

If they needed to reserve two bits out of the RGBA colors as flags, and still wanted to leave as many colors in each channel as possible, that would be one way to do it.

I haven't figured out the algorithm they used to reduce the colors, but since they mostly culled the lower, less-distinguishable hues, it does look kinda deliberate.

[DakJaniels]

Originally Posted by DewiMorgan I haven't figured out the algorithm they used to reduce the colors, but since they mostly culled the lower, less-distinguishable hues, it does look kinda deliberate.

Get black book browser and extract the shader folder, it has the things you are seeking.

also see https://sluglibrary.com/SlugManual.pdf page 247. there's other things in there too that are interesting.

[DewiMorgan]

The manual page 247 section "Color Layers" appears to be talking about emojis, but the section on rendering was useful. It looks like you're right that shaders can be a thing with Slug text, so this could be an effect from whatever new shaders they added for Slug.

Another interesting bit there is on pg 44: "The color output by the Slug shaders is linear RGB color. This color must be converted to sRGB for proper display, and this is typically done by enabling hardware sRGB conversion for the render target." So it might be that color conversion that's losing a third of the hue space.