Closed dscorbett closed 1 year ago
Thanks for reporting this!
At a quick glance, the bug seems pretty obvious. The code in os_set_text_color()
in osglk.c
always sets the current zcolor to whatever value of fg
and bg
that is passed into it when it does not know how to handle it. Apparently, these "parameterized" values will look red when interpreted as Glk colours.
I never noticed this when implementing text colour in TADS all those years ago, as I couldn't find a game that used other parameters than OS_COLOR_P_TRANSPARENT and OS_COLOR_P_TEXT to test it with.
It should be an easy fix, but it is tempting to try to implement some of these other parameterized colours using the same hacks that I use for Hugo. Do you know of a TADS game that would benefit from it?
Thanks. I’m using <font color=bgcolor bgcolor=text>
in my in-development game to highlight some text by inverting the colors, which Spatterlight rendered as an unreadable rectangle of red. I don’t know any published games that use parameterized colors.
Just let me know when your game is released, and I'll see if I can work out a way to support this effect without breaking anything else.
TADS 3’s parameterized colors are interpreted as red instead of their correct values. The exception is
text
, which is interpreted correctly as the foreground text color. Here is a demo. An interpreter is not required to support parameterized colors, but it should either interpret them as specified or ignore them, not map them to red.