Can get a nice dark brown text color in Zangband, but not in Angband

[smbhax]

Was messing with a Curses build of Zangband in an xterm256 Cygwin terminal and noticed that when I compiled it with the colors from a color scheme I'd cooked up in Angband's color editor popped into its src/variable.c color table

	{0x00, 0x00, 0x00, 0x00},	/* TERM_DARK */
	{0x00, 0xDD, 0xDC, 0xAD},	/* TERM_WHITE */
	{0x00, 0x84, 0x57, 0x2C},	/* TERM_SLATE */
	{0x00, 0xFF, 0x80, 0x00},	/* TERM_ORANGE */
	{0x00, 0xC0, 0x00, 0x00},	/* TERM_RED */
	{0x00, 0x00, 0x80, 0x40},	/* TERM_GREEN */
	{0x00, 0x00, 0x40, 0xFF},	/* TERM_BLUE */
	{0x00, 0x80, 0x40, 0x00},	/* TERM_UMBER */
	{0x00, 0x5E, 0x3D, 0x06},	/* TERM_L_DARK */
	{0x00, 0xE7, 0xC3, 0x43},	/* TERM_L_WHITE */
	{0x00, 0xFF, 0x00, 0xFF},	/* TERM_VIOLET */
	{0x00, 0xFF, 0xFF, 0x00},	/* TERM_YELLOW */
	{0x00, 0xFF, 0x40, 0x40},	/* TERM_L_RED */
	{0x00, 0x00, 0xFF, 0x00},	/* TERM_L_GREEN */
	{0x00, 0x00, 0xD6, 0xDF},	/* TERM_L_BLUE */
	{0x00, 0xC0, 0x80, 0x40}	/* TERM_L_UMBER */

the colors came out much richer than in Angband. Even if I similarly compile them into Angband's src/z-color.c color table, whereas they come out in these nice dark browns in Zangband



they come out in much less saturated browns in Angband



And messing with them in Angband's color editor, I just plain can't get it to give me a nice rich brown color: it jumps between rather icky dark green-brown, or weirdly dark yellow brown, and so forth.

There seems to be some kind of severe color rounding-off going on in Angband. I wonder if this is absolutely necessary? Ie, would it be possible to have, in Angband, what appears to be possible in Zangband, namely access to full 24-bit color values, without them being approximated to some much more limited palette instead?

[Nick]

The get_color() function in z-color.c has a comment:

 * TODO: Honour the attribute for the term (full color, mono, 16 color) but
 * ensure that e.g. the lighter version of yellow becomes white in a 16 color
 * term, but light yellow in a full colour term.

which may be relevant. I note too that the curses port doesn't use gamma correction (where x11 and Windows do), but it doesn't in Z either.

Worth noting also that I know next to nothing about colors

[Pete Mack]

What nick said. Depending on the screen, i sometimes set TERM_BLUE to royal blue for visibility. Blue on black or vice versa is notoriously hard to perceive.

[smbhax]

The get_color() function in z-color.c has a comment:

 * TODO: Honour the attribute for the term (full color, mono, 16 color) but
 * ensure that e.g. the lighter version of yellow becomes white in a 16 color
 * term, but light yellow in a full colour term.

which may be relevant. I note too that the curses port doesn't use gamma correction (where x11 and Windows do), but it doesn't in Z either.

Worth noting also that I know next to nothing about colors

What nick said. Depending on the screen, i sometimes set TERM_BLUE to royal blue for visibility. Blue on black or vice versa is notoriously hard to perceive.

The colors behave much differently in a 16-color xterm console--the editor doesn't work at all, but you can get exact 24-bit color values by setting them in your console emulator's options--so I think this is a different thing. For instance, in an xterm256 console, a very dark color like 0x19 0x19 0x19 comes out straight black in the Angband color editor--so this is actually significantly worse in that regard.

[backwardsEric]

Angband's main-gcu.c isn't using curses' init_color() to override the default color table; Zangband's is. That's likely the main cause.

As a side effect of that, Angband's main-gcu.c is, for the 256 color case, dividing the full range for each color component (0 - 255) into 6 bins but the first and last of those bins cover about one half of the range that the others do. Changing scale_color() to be

static int scale_color(int i, int j, int scale) {
        return (angband_color_table[i][j] * scale) / 256;
}

would give each bin roughly equal weight.

[smbhax]

(^ Didn't see backwardsEric's reply before I posted this.)

Angband's src/main-gcu.c has this section

static int scale_color(int i, int j, int scale) {
	return (angband_color_table[i][j] * (scale - 1) + 127) / 255;
}

static int create_color(int i, int scale) {
	int r = scale_color(i, 1, scale);
	int g = scale_color(i, 2, scale);
	int b = scale_color(i, 3, scale);
	int rgb = 16 + scale * scale * r + scale * g + b;

	/* In the case of white and black we need to use the ANSI colors */
	if (r == g && g == b) {
		if (b == 0) rgb = 0;
		if (b == scale) rgb = 15;
	}

	return rgb;
}


/**
 * Adjust the color tables if there's more than 16 available.
 */
static void handle_extended_color_tables(void) {
#ifdef A_COLOR
	if (COLORS == 256 || COLORS == 88) {
		/* If we have more than 16 colors, find the best matches. These numbers
		 * correspond to xterm/rxvt's builtin color numbers--they do not
		 * correspond to curses' constants OR with curses' color pairs.
		 *
		 * XTerm has 216 (6*6*6) RGB colors, with each RGB setting 0-5.
		 * RXVT has 64 (4*4*4) RGB colors, with each RGB setting 0-3.
		 *
		 * Both also have the basic 16 ANSI colors, plus some extra grayscale
		 * colors which we do not use.
		 */
		int i;
		int scale = COLORS == 256 ? 6 : 4;

		bg_color = create_color(COLOUR_DARK, scale);
		for (i = 0; i < BASIC_COLORS; i++) {
			int fg = create_color(i, scale);
			int isbold = bold_extended ? A_BRIGHT : A_NORMAL;
			init_pair(i + 1, fg, bg_color);
			colortable[i] = COLOR_PAIR(i + 1) | isbold;
			init_pair(BASIC_COLORS + i, fg, fg);
			same_colortable[i] = COLOR_PAIR(BASIC_COLORS + i) | isbold;
		}

		for (i = 0; i < term_count; ++i) {
			if (data[i].win) {
				wbkgdset(data[i].win, ' ' |
					colortable[COLOUR_DARK]);
			}
		}
		if (data[0].win) {
			/*
			 * Adjust the background color on the standard screen
			 * as well so separators between the terminals have
			 * the same background as the rest.
			 */
			chtype term0_bkg = getbkgd(data[0].win);

			if (getbkgd(stdscr) != term0_bkg) {
				wbkgd(stdscr, term0_bkg);
				wrefresh(stdscr);
			}
		}
	}
#endif
}

Zangband has this in about the same place:

static errr Term_xtra_gcu_react(void)
{
#ifdef A_COLOR

	int i;

	/* Cannot handle color redefinition */
	if (!can_fix_color) return (0);

	/* Set the colors */
	for (i = 0; i < 16; i++)
	{
		/* Set one color (note scaling) */
		init_color(i, angband_color_table[i][1] * 1000 / 255,
		              angband_color_table[i][2] * 1000 / 255,
		              angband_color_table[i][3] * 1000 / 255);
	}

#endif

	/* Success */
	return (0);
}

So it looks like there's a lot of color scaling going on that wasn't in Zangband. There are no doubt good reasons for it, but it does seem to be making it hard to get true colors in Angband's terminal.

[smbhax]

Angband's main-gcu.c isn't using curses' init_color() to override the default color table; Zangband's is. That's likely the main cause.

As a side effect of that, Angband's main-gcu.c is, for the 256 color case, dividing the full range for each color component (0 - 255) into 6 bins but the first and last of those bins cover about one half of the range that the others do. Changing scale_color() to be

static int scale_color(int i, int j, int scale) {
        return (angband_color_table[i][j] * scale) / 256;
}

would give each bin roughly equal weight.

I tried that but wasn't able to notice a difference in the colors available.

[smbhax]

Out of curiosity, I tried swapping the three color-handling sections from Zangband's main-gcu.c into Angband's...which got me Angband reduced to 16 colors, which doesn't work too well with modern Angband. ; ) Ah well.

[Bill Peterson]

Using the Windows version I find that umber text is virtually illegible. I switch it light umber.

[smbhax]

Using the Windows version I find that umber text is virtually illegible. I switch it light umber.

Yeah recall text doesn't usually use Umber in Vanilla as far as I've seen, so it caught me a bit by surprise in Zangband.

[smbhax]

This is fixed with backwardsEric's pull request #5286.