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

[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]

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]

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]

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]

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]

Ah! Thanks. : )

[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]

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

I understand that, but the previous behavior is not nearly as useful as simple subwindow command line control with large viewport support would be. If given the choice I don't think anyone would want -- -o over -- -n4, and certainly not over -- -nN.

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.

Wouldn't that risk missing fixes to the fixes? Anyway I was thinking more of the subwindow code, some of it in your version looks a lot different than the stuff from current Angband, and from a support and I guess feature point of view it seems like keeping it close to current Angband would be more advantageous.

No, I'm about to add backwardseric's colour fix to the PR.

Nice!!

[Gwarl]

I understand that, but the previous behavior is not nearly as useful as simple subwindow command line control with large viewport support would be. If given the choice I don't think anyone would want -- -o over -- -n4, and certainly not over -- -nN.

There's nothing stopping anyone from implementing that as well, and nothing in my code changes prevents current vanilla behaviour from overriding the classic hengband behaviour, it's simply not part of what I'm trying to achieve here. My goal is to allow to hengband to work as it did before while also improving its capabilities to work with .live, not to change its ordinary behaviour (I would have kept the default if launching without parameters if I could, the -o switch is a bit of a compromise to allow the customiseable layouts to work)

Wouldn't that risk missing fixes to the fixes? Anyway I was thinking more of the subwindow code, some of it in your version looks a lot different than the stuff from current Angband, and from a support and I guess feature point of view it seems like keeping it close to current Angband would be more advantageous.

The last common ancestor of both variants is 2.8.1; it's totally unreasonable to expect parity, especially given that both variants have been massively refactored after they were already decades of changes apart. in this case there is a fix to the fix (a very recent one at that), and I'll be applying it presently.

[smbhax]

There's nothing stopping anyone from implementing that as well, and nothing in my code changes prevents current vanilla behaviour from overriding the classic hengband behaviour, it's simply not part of what I'm trying to achieve here. My goal is to allow to hengband to work as it did before while also improving its capabilities to work with .live, not to change its ordinary behaviour (I would have kept the default if launching without parameters if I could, the -o switch is a bit of a compromise to allow the customiseable layouts to work)



The last common ancestor of both variants is 2.8.1; it's totally unreasonable to expect parity, especially given that both variants have been massively refactored after they were already decades of changes apart. in this case there is a fix to the fix (a very recent one at that), and I'll be applying it presently.

nothing in my code changes prevents current vanilla behaviour from overriding the classic hengband behaviour

I'm not sure about that. In current Angband code, the poschengband and -- -nN subwindow stuff is somewhat tied together. I pasted current vanilla's subwindow code over Hengband's and everything just worked up to modern vanilla spec; it would probably have been easier for you to do that than to put in a poschengband system without -nN functionality and add a new wrapper around Hengband's old, extremely limited pseudo -nN function, which nobody would have been using anyway given that GCU Hengband had been non-working up until a few weeks ago.

Someone who was looking at this now with an eye to bringing it up to current Angband spec would have to figure out this unique and functionally limited hybrid subwindow system in your version.

In that regard and in terms of keeping things compatible for later maintainers, replacing Hengband's subwindow system with modern Angband's would have been far preferable as far as I can see. It also would have been more functional for users. And it probably would have been easier to implement, considering that I did it with pretty much zero experience.

it's totally unreasonable to expect parity

As far as the color system goes I wouldn't expect or even want parity. The modern Angband subwindow system on the other hand turned out to be pretty much drag and drop.

[smbhax]

nothing in my code changes prevents current vanilla behaviour from overriding the classic hengband behaviour

Wait, you don't mean there's a way to use -- -nN coupled with large viewports with your code, do you? That's what springs to mind when I think of current vanilla behavior.

[smbhax]

My goal is to allow to hengband to work as it did before while also improving its capabilities to work with .live, not to change its ordinary behaviour (I would have kept the default if launching without parameters if I could, the -o switch is a bit of a compromise to allow the customiseable layouts to work)

Say, if -- -nN support was there, wouldn't it be possible to default to essentially a "-- -n4" input--which as far as I was able to see is what Hengband's old behavior was imitating, aside from its limited screen size--if no other layout input was received at launch?

[Gwarl]

Wait, you don't mean there's a way to use -- -nN coupled with large viewports with your code, do you? That's what springs to mind when I think of current vanilla behavior.

No I mean classic hengband doesn't have a way to do it either.

Look, after this PR goes through, we can look at implementing the -nN syntax (again I have not removed this from hengband, it was never there in the first place). In the meantime you can use your own main-gcu to play locally.

wouldn't it be possible to default to essentially a "-- -n4" input--which as far as I was able to see is what Hengband's old behavior was imitating, aside from its limited screen size--if no other layout input was received at launch?

Hengband's old behaviour was not imitating anything, it was the only behaviour for Zangband and 2.9ish angband version and hasn't changed.

Default would end up being bigscreen (no subwindows) if no parameters were supplied but we could potentially have -nN

[smbhax]

Hengband's old behaviour was not imitating anything, it was the only behaviour for Zangband and 2.9ish angband version and hasn't changed.

Interesting! So I went digging for the history of -nN. : ) It looks like -nN came along in Angband in May 2013, by myshkin: https://github.com/angband/angband/pull/241

And there were various tweaks and fixes to it by myshkin over the course of that year. The next Angband official release, 3.5.0 in December of that year https://rephial.org/release/3.5.0 , notes only

(Curses) Allow specification of number of terminals in the curses port

The apparently highly misleading ; ) line about it in Hengband's English readme https://github.com/hengband/hengband.../readme-eng.md

./hengband -- -n<number of windows>  ## for normal ASCII graphics

appears to be modified from PosChengband's readme, dated June 2013 https://github.com/NickMcConnell/pos...3b0/readme.txt

  Then run poschengband as desired:
    $ cd ..
    $ ./poschengband -- -n<number of windows>  ## for normal ASCII graphics
  or
    $ ./poschengband -g -- -n<# of windows>    ## for 8x8 tile graphics

(Mind you, I'm not suggesting using Angband's version 3.5.0 as the source for putting -nN support in Hengband--especially since it and the PosChengband subwindow style (added to Angband in 2019 with credit to you : } https://github.com/angband/angband/c...f76cc30dcb9bc5 ) dropped in together quite simply from current Angband; I just got curious to see where the -nN system came from.)

And then for the sake of completion I wanted to see when/where the PosChengband subwindow system came from: seems to be a commit in the frogcomposband repo (forked from your Composband, which was forked from PosChengband, although now unfortunately the PosChengband's repository history stops before that change), made by deleted user @poschengband on September 10th, 2015 as "Curses: Dynamic Layout with Command Line Parameters" https://github.com/sulkasormi/frogco...f76cc30dcb9bc5

[smbhax]

Does anyone else's compiled GCU hengband.exe come out at over 220 MB? The other 'bands I compile are like 1/20th of that size, and heck the downloaded Windows graphical Hengband's exe is like 3 MB...so 220 seems a little weird. = P

This file size inflation can also be seen at the individual file level; for instance, in Angband, main-gcu.c is 37 KB, and the main-gcu.o generated when I compile comes out at 51 KB--whereas in Hengband, a 41 KB main-gcu.cpp results in a 462 KB main-gcu.o.

And Hengband's compiles take substantially longer than the other 'bands I've compiled.

I suppose Hengband is C++ whereas the others are C, but eh hm well I don't know how this is supposed to work. I'm using Cygwin, and Hengband's default configure settings, with "--disable-japanese."