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

[Gwarl]

Ah, and "stty" stands for "Set Teletype," according to Google. Looking through source code, I find curses support in some form all the way back to Umoria, although in 2.4 FrogKnows for instance it wasn't used on all systems, if I'm reading this right...and there's some stty stuff (sgttyb, ttyb) in there--which is gone by 2.6.1.

huh I remember looking at 2.6.1 and seeing strange ancient libraries and no curses and giving up on the idea of ever being able to compile it. (looked again, guess I misremembered. I do remember it being unlikely to ever compile)

[Nick]

Which reminds me:
@Nick--
Macros are non-optional in Sil, and presumably will be in Beleriand. There are a number of abilities that need to be toggled on/off by a single keystroke; fire arrows are the obvious one. This cannot be done with keymaps. (I first ran into this in ToME, where you needed to be able to change stance efficiently, trading stealth, saving throw, and perception for speed and damage.

Thanks Pete, I'll watch out for that.

[smbhax]

Curses was originally ascii gfx package built on stty. Now includes unicode support. The original ANGBAND UNIX support used stty, which is where macros came in.

Ah, and "stty" stands for "Set Teletype," according to Google. Looking through source code, I find curses support in some form all the way back to Umoria, although in 2.4 FrogKnows for instance it wasn't used on all systems, if I'm reading this right...and there's some stty stuff (sgttyb, ttyb) in there--which is gone by 2.6.1.

[Pete Mack]

Curses was originally ascii gfx package built on stty. Now includes unicode support. The original ANGBAND UNIX support used stty, which is where macros came in.

Which reminds me:
@Nick--
Macros are non-optional in Sil, and presumably will be in Beleriand. There are a number of abilities that need to be toggled on/off by a single keystroke; fire arrows are the obvious one. This cannot be done with keymaps. (I first ran into this in ToME, where you needed to be able to change stance efficiently, trading stealth, saving throw, and perception for speed and damage.

[smbhax]

(I got curious as to what "GCU" stands for; Googling showed it as an Angband-exclusive abbreviation, at least as far as relates to video games. Anyway in older versions of Angband's main-gcu.c -- the oldest on the official site/repository appearing to be from 2.7.4 https://github.com/angband/angband/b...src/main-gcu.c , soon after Ben Harrison's 2.7.0 source file reorganization -- line 3 says

/* Purpose: Somewhat generic Unix Curses support for Angband */

So G(eneric) C(urses) U(nix), I suppose--which could be a pun on "GNU," for "GNU Project," a software project that helped lead to the development of Linux; "GNU" is a recursive acronym for "GNU's Not Unix." https://en.wikipedia.org/wiki/GNU_Project

Later versions of main-gcu obscured the (possible) meaning; Hengband's for instance has

/* Purpose: Allow use of Unix "curses" with Angband -BEN- */

"Curses" itself was a pun on "cursor optimization." https://en.wikipedia.org/wiki/Curses...mming_library)

~~~~~~~~~~~~

"Hengband" appears to be a punning acronym, well it's the sound, "hengubando," you get from four Japanese characters, which have individual meanings:

"hen" - strange
"gu" - stupid
"ban" - barbarian
"do" - anger

^ That's from Google Translate. That last one is spelled out as "ika" on their translation form, but pronounced uh possibly a few ways, one of which is "do." The forum's encoding doesn't accept the Japanese characters themselves; you can see them here: https://translate.google.com/?sl=ja&...2&op=translate

So anyway, they have a firm grasp on the essence of the game. : D)

[smbhax]

Configuring with CXXFLAGS set to "-g0 -O2" and building would verify if that's the case.

Thanks! That did the trick. : )

make install

gives me a 223 MB exe;

make install CXXFLAGS="-g0 -O2"

(first time of course I had to do

make clean install CXXFLAGS="-g0 -O2"

) gives me a 4 MB exe.

[backwardsEric]

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

Compiled on a Mac, the executable for 2.2.1 is 2.4 MB while 3.0.0 beta is 4.2 MB; so some inflation due to the C->C++ change or other code changes since 2.2.1. The default configuration (at least on the Mac) includes debugging symbols. I'd suspect that those might be the reason for the large executable size on Cygwin. Configuring with CXXFLAGS set to "-g0 -O2" and building would verify if that's the case.

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

That seems like par for the course for C++; a Linux build for "make distcheck" of Hengband 2.2.1 takes about 3 minutes on GitHub's hardware and takes about 25 minutes for the Hengband 3.0.0 beta.

[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."

[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

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

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?

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

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.

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

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!!