Compiling Hengband: "fatal error: util.h: No such file or directory"

[Gwarl]

Are you really going to leave everyone stuck with the much harder to use poschengband-style subwindow control just because that's all you need in .live?

Hengband previously had no subwindow control at whatsoever, and you can return to this behaviour with -o.

Thinking about your version: you wrote some of your own code in there instead of just going directly with code from current Angband, which means it's less code-compatible with current Angband. Is that wise? Wouldn't it be better--for future support, etc--to keep it as close as possible to vanilla unless the variant's content demands otherwise? What is gained by dropping the -- -nN suboption?

None of this code is mine, the colour fix is taken from angband 3.1.2 I usually try and take my fixes from the first version to include them.

Hengband is about to get less precise colors inflicted on it because of a problem in .live's terminal emulator?? = o

No, I'm about to add backwardseric's colour fix to the PR. I was just wondering whether to apply it to every variant and version I'm hosting or not.

[smbhax]

Ah! Thanks. : )

[backwardsEric]

Sorry for the extremely ignorant and fairly pointless question, but what determines whether or not can_change_color returns true?

Likely an entry for the terminal/terminal emulator in the terminfo data that describes the capabilities and behavior of that terminal. On a Mac, there's this in the man page for terminfo:

These are the boolean capabilities:
Variable         Cap-      TCap     Description
Booleans         Name      Code
...
can_change       ccc       cc       terminal can redefine existing colors
...

[smbhax]

For the compilation errors, your changes are fine (adding an "s" at the end of can_change_color was my typo). As for incorporating it into Gwarl's pull request, that's Gwarl's call. If I was making the decision, it would depend on whether this revision does work angband.live. It could be that can_change_color() returns true in that environment, and there's something else that causes that terminal emulator to not work well with the init_color() code.

Sorry for the extremely ignorant and fairly pointless question, but what determines whether or not can_change_color returns true?

[backwardsEric]

For the compilation errors, your changes are fine (adding an "s" at the end of can_change_color was my typo). As for incorporating it into Gwarl's pull request, that's Gwarl's call. If I was making the decision, it would depend on whether this revision does work angband.live. It could be that can_change_color() returns true in that environment, and there's something else that causes that terminal emulator to not work well with the init_color() code.

[smbhax]

smbhax, with the version of Hengband including Gwarl's color changes, bracket the color color scaling loop with an if statement:

if (!can_change_colors()) {
    /* Gwarl's loop over the color table with scaling here. */
} else {
    /* Hengband's previous color loop here. */
    for (i = 0; i < 16; ++i) {
        init_color(i, (angband_color_table[i][1] * 1000) / 255,
            (angband_color_table[i][2] * 1000) / 255,
            (angband_color_table[i][3] * 1000) / 255);
    }
}

That's the essence of the previously linked pull request for Angband. From Gwarl's description, it sounds like angband.live's terminal emulator does not support overwriting the color table (so can_change_colors() should return false) and the variants based on the Angband 2.* code didn't check for that.

Thanks! : D I tried that in my test build and it did restore the older-style, more accurate dark colors:



Of course, I can't tell if this still leaves the color fix working on Gwarl's service.

Two questions:

1) If this DOES work for .live, is it something that should just be in his PR2023 from the get-go?

2) I quite possibly did it wrong, but I found I had to make two adjustments to the code snippet you gave. What I ended up going with was...ah I'll just put the whole function in here to be clear, since I'm not even 100% sure I put your code in the right function, although this was the only loop I could see that his PR added, so it sounds like it should be the right place:

/*
 * React to changes
 */
static errr Term_xtra_gcu_react(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 scale = COLORS == 256 ? 6 : 4;
        if (!can_change_color()) {
            /* Gwarl's loop over the color table with scaling here. */
            for (int i = 0; i < 16; i++)
            {
                int fg = create_color(i, scale);
                init_pair(i + 1, fg, bg_color);
                colortable[i] = COLOR_PAIR(i + 1) | A_NORMAL;
            }
        } else {
            /* Hengband's previous color loop here. */
            for (int i = 0; i < 16; ++i) {
                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);
}

That's what compiled successfully; I'd had to make two changes:

		if (!can_change_color()) {

Your snippet had

		if (!can_change_colors()) {

which gave an error.

And I got another error:

main-gcu.cpp: In function �errr Term_xtra_gcu_react()’:
main-gcu.cpp:901:30: error: �i’ was not declared in this scope
  901 |                         for (i = 0; i < 16; ++i) {
      |                              ^

So I changed your

            for (i = 0; i < 16; ++i) {

to

            for (int i = 0; i < 16; ++i) {

and it compiled.

("int i;" had been line 852 prior to Gwarl's changes, right above a "if (!can_fix_color)" line.)

[backwardsEric]

smbhax, with the version of Hengband including Gwarl's color changes, bracket the color color scaling loop with an if statement:

if (!can_change_colors()) {
    /* Gwarl's loop over the color table with scaling here. */
} else {
    /* Hengband's previous color loop here. */
    for (i = 0; i < 16; ++i) {
        init_color(i, (angband_color_table[i][1] * 1000) / 255,
            (angband_color_table[i][2] * 1000) / 255,
            (angband_color_table[i][3] * 1000) / 255);
    }
}

That's the essence of the previously linked pull request for Angband. From Gwarl's description, it sounds like angband.live's terminal emulator does not support overwriting the color table (so can_change_colors() should return false) and the variants based on the Angband 2.* code didn't check for that.

[smbhax]

Yeah it's the code from angband's main-gcu that's allowing you to have 6 terminals. go look in hengband's main-gcu file; line 194

https://github.com/hengband/hengband/blob/develop/src/main-gcu.cpp

Then look at angband or your hack and you'll see

Like I say, Hengband isn't even parsing any mgcu subopts, never mind doing anything with them.

I know, what I'm saying is that it's not very hard to make this work. I got it working with a little accidental copy and paste.

Would you really leave everyone stuck with the much harder to use poschengband-style subwindow control? Come on man, if I can do it accidentally, you can **definitely** do it!

I've had to port the 88/256 behaviour to all the variants on .live because if I don't, white shows up as red and every other colour is also off. They work fine on my local terminal so it probably is .live's terminal emulator's fault.

Hengband is about to get less precise colors inflicted on it because of a problem in .live's terminal emulator?? = o

This is probably a side affect of the colour fix. It comes straight from mainstream angband though.

I know, I got the same thing with my second hack of main-gcu.cpp, using Angband's main-gcu.c as a base.

Just did a clean build and I can confirm that Hengband develop has its darker colors brightened when your color change, PR2023, is added to it:

[smbhax]

Yeah it's the code from angband's main-gcu that's allowing you to have 6 terminals. go look in hengband's main-gcu file; line 194

https://github.com/hengband/hengband/blob/develop/src/main-gcu.cpp

Then look at angband or your hack and you'll see

Like I say, Hengband isn't even parsing any mgcu subopts, never mind doing anything with them.

I know, what I'm saying is that it's not very hard to make this work. I got it working with a little accidental copy and paste.

Are you really going to leave everyone stuck with the much harder to use poschengband-style subwindow control just because that's all you need in .live?

Thinking about your version: you wrote some of your own code in there instead of just going directly with code from current Angband, which means it's less code-compatible with current Angband. Is that wise? Wouldn't it be better--for future support, etc--to keep it as close as possible to vanilla unless the variant's content demands otherwise? What is gained by dropping the -- -nN suboption?

I've had to port the 88/256 behaviour to all the variants on .live because if I don't, white shows up as red and every other colour is also off. They work fine on my local terminal so it probably is .live's terminal emulator's fault.

Hengband is about to get less precise colors inflicted on it because of a problem in .live's terminal emulator?? = o

[Gwarl]

I've had to port the 88/256 behaviour to all the variants on .live because if I don't, white shows up as red and every other colour is also off. They work fine on my local terminal so it probably is .live's terminal emulator's fault.

Thinking about this I'm not sure it's worth changing, I'd have 30+ versions needing patching and would probably also want to use a command line switch with a new field in the game launch menu to switch between them, since people are used to what they have and might not like change, plus nobody has ever complained. I have my work cut out now fixing 2.8.3 and 3 versions of Z so I think I'll just let this one slide.

[backwardsEric]

Wow I was going to suggest we ask you to take a look at this. I'll have to include it in the hengband PR so I don't mess their colours up. Thankfully I don't think I have to go back and apply it to every variant hosted on .live? Does this work with 256 colour terminals or is it just applying the old behaviour to 16 colours?

It works with 256 colour terminals doesn't it? I have to go back and apply it to the entire 30 odd versions and variants I'm hosting don't I?

It works in the 256-color xterm I tried. For other terminal emulators and angband.live, I don't know. Essentially it's using the pre 256/88 color change behavior (overwriting the color table with init_color()) unless curses says changing the color table doesn't work (can_change_color() returns false) or the user requests that the existing color table be preserved.

If the terminal emulator that angband.live uses causes all sessions to share a color table, then it wouldn't make sense to port that change to the variants where the 256/88 color change was applied. Even if each session has it's own color table, I'd only port that change if there was a specific request to do so (the variant's default color scheme doesn't work well when mapped to the 6 x 6 x 6 color cube or someone wants the highest fidelity to a custom color scheme).

[Gwarl]

I did a clean build to current develop branch and you are absolutely correct, the -- -nN command line suboption does nothing there.

But here is the game fully rebuilt from habu's cursor fix PR2024--note visible cursor--and my first main-gcu.cpp hack -- the cpp file is attached to this post two pages back in this thread http://angband.oook.cz/forum/showpos...1&postcount=20 -- with large dungeon display and six working subwindows, launched with "./hengband -- -n6" (the composband command line stuff works too, as far as I can tell--I'm not very good at it):



(And the older colors.)

Yeah it's the code from angband's main-gcu that's allowing you to have 6 terminals. go look in hengband's main-gcu file; line 194

https://github.com/hengband/hengband/blob/develop/src/main-gcu.cpp

#define MAX_TERM_DATA 4

Then look at angband or your hack and you'll see

#define MAX_TERM_DATA 6

Like I say, Hengband isn't even parsing any mgcu subopts, never mind doing anything with them.

[Gwarl]

You might interpolate between the changes this pull request, https://github.com/angband/angband/pull/5286/files , makes to Angband and Gwarl's changes to Hengband for 256/88 color curses windows. That should get back the close matching to the specified colors, at least when the terminal supports changing the color table.

Wow I was going to suggest we ask you to take a look at this. I'll have to include it in the hengband PR so I don't mess their colours up. Thankfully I don't think I have to go back and apply it to every variant hosted on .live? Does this work with 256 colour terminals or is it just applying the old behaviour to 16 colours?

It works with 256 colour terminals doesn't it? I have to go back and apply it to the entire 30 odd versions and variants I'm hosting don't I?

[smbhax]

hengband never supported that. it didn't support any mgcu subopts at all. -o will give you the old behaviour. Porting modern angband's behaviour would be more work and I'm not motivated to do it.

I did a clean build to current develop branch and you are absolutely correct, the -- -nN command line suboption does nothing there.

But here is the game fully rebuilt from habu's cursor fix PR2024--note visible cursor--and my first main-gcu.cpp hack -- the cpp file is attached to this post two pages back in this thread http://angband.oook.cz/forum/showpos...1&postcount=20 -- with large dungeon display and six working subwindows, launched with "./hengband -- -n6" (the composband command line stuff works too, as far as I can tell--I'm not very good at it):



(And the older colors.)

[smbhax]

You might interpolate between the changes this pull request, https://github.com/angband/angband/pull/5286/files , makes to Angband and Gwarl's changes to Hengband for 256/88 color curses windows. That should get back the close matching to the specified colors, at least when the terminal supports changing the color table.

So PR5286 after Gwarl's two PRs should get back to being fairly close to the term/gameterm.cpp color table colors?

Oh wait PR5286 is in Angband, not Hengband. Oh heck.