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

[smbhax]

Oh. Okay, I think these are actually showing the full size possible--it's just that that's the maximum dimensions of those "Yeek cave" dungeon floors; the map view wouldn't seem "small" except for how Hengband fills in the space with those gray "x" marks where you haven't cast Detect Traps (you can turn that off in an option).

In the wilderness, the map sizes are a bit bigger:



That's just the full extent of the pre-rendered map tile.

These are also the sizes you see if you maximize your main window in Hengband's Windows graphical client.

So anyway, I guess either of those two versions of main-gcu.cpp actually do the trick: the first is more RGB-color-table-accurate, keeps the colors of current GCU Hengband, and more Hengband code; the second is more current Angband code, with weirdly brightened dark colors--approximately matching how they come out in Hengband's Windows graphical client, as it happens. I'm no coder so they are probably doing horrible things somehow somewhere, but they seem to compile and run okay for me in Cygwin (with the --disable-japanese configure option; haven't tested them without that), at least.

[smbhax]

Second attempt at it: this time I used Angband's main-gcu.c as the base and pasted in stuff from habu1010's main-gcu.cpp as necessary to clear compile errors. Had to remove some Angband mouse and advanced key handling stuff for which Hengband doesn't have support elsewhere--ditto with Angband's colors over Hengband's basic 16.



Dark colors come out slightly brighter in this version (my first version and regular Hengband are slightly dimmer to the same degree by comparison to it), I suppose because more of Angband's color handling got in this time. There's very little Hengband code and the file is 25% smaller than my first version...but the map rendering is still stuck at 130x42 max for some reason.

With this Angbandy-er version, the brightness level of the darker colors now just about matches the colors in Hengband's graphical Windows client, actually. But the dark colors as rendered by the Hengband color-handling GCU code are much more accurate to the actual RGB values in the color table in term/gameterm.cpp. (And easier on the eyes...so I'm going to stick with my version 1 over this more Angband-ified version 2.)

I went looking for map size limits in other files, didn't find anything but of course I don't know what I'm looking for.

[smbhax]

I remember having fixed cursor issues in other variants, it was a small one liner iirc but I don't remember which version it came from.

Anyway I'm working my way up fixing the curses frontend in ancestral versions, angband 2.8.3 is done, next up is zangband 2.2.8. I'll have to stop at a version of hengband prior to their C++ rewrite but maybe one of their devs will be able to check what I've done and take it from there.

Hm well it's a horrific hack but by lots of copying and pasting from current Angband's main-gcu.c, I've managed to get a version of Hengband's main-gcu.cpp (I used habu1010's flicker-fix pull request https://github.com/hengband/hengband/pull/2024 as the base) that lets the game run in a *somewhat* larger subwindow--or rather, a full-sized subwindow, but something is preventing the map being drawn across quite all of it, so on a large enough resolution there are black bars to the right and bottom of the map.

I'm attaching my hacked main-gcu.cpp to this post. Here's a screenshot running in Cygwin (click thumbnail for the full size 1080p screen)--that map size you see there, 130x42 I think, is as big as it gets, even if you run with no subwindows:



The game also no longer assumes four subwindows from launch, instead requiring the usual command line parameters (like "-- -n4" or "-- -right 40x25,* -bottom *x7").

I don't know C *or* C++ so there are probably all kinds of horrible things going on here...but it compiles and runs, and *seems* to work in extremely limited testing. Maybe some person who actually knows things can work out what I've screwed up to prevent the map window from using the full area.

EDIT: As I found later in this thread, this actually is showing the viewport at full size; it happened to look smaller size because the "Yeek cave" beginner dungeon levels I was using for testing were smaller than the viewport size. ; ) So, this version **is** full screen, with -nN and PosChengband-style subwindow support, native Hengband colors, and habu's cursor fix.

[Gwarl]

I remember having fixed cursor issues in other variants, it was a small one liner iirc but I don't remember which version it came from.

Anyway I'm working my way up fixing the curses frontend in ancestral versions, angband 2.8.3 is done, next up is zangband 2.2.8. I'll have to stop at a version of hengband prior to their C++ rewrite but maybe one of their devs will be able to check what I've done and take it from there.

[smbhax]

(And so it appears that they do have a team member who knows their way around Curses, which is awesome. Since Hourier said in their Discord developers channel that only Becky42 maintains main-g(c)u, I take it Discord Becky42 = Habu1010 on GitHub.)

[smbhax]

Hm, the loose cursor blipping around the subwindows is more pronounced in live, I suppose just standing out more due to the latency. It's something I reported to them, but they don't play in Curses over there due to language support--I think--so it doesn't sound like Curses-specific bugs will be a priority for them. https://github.com/hengband/hengband/issues/2014 I tried comparing the cursor-handling bits I could spot in their main-gcu.cpp with Angband's main-gcu.c, buuut it was just "Greek" with minor variations to my non-coder self.

It looks like Hengband team member Habu1010 has submitted a pull request to fix the stray cursor, with changes to main-gcu.c and z-term.cpp: https://github-com.translate.goog/he...ull/2024/files

EDIT: Hah that's funny, Google Translate could handle it on the fly but not from a direct link, I guess. The original is https://github.com/hengband/hengband/pull/2024/files

[smbhax]

From their Discord https://discord.gg/VvDTvb4ewH : )

[smbhax]

(Aside from making the 00 00 FF TERM_BLUE color a slightly lighter 00 40 FF in src/term/gameterm.cpp so it isn't painfully dark to try to see, the other change I've made locally is to comment out the two "You failed to pick the lock" outcomes in src/action/open-close-execution.cpp, because bonking my face against random locked doors up to 69x so far just to open them was a bit much.)

[smbhax]

Nice! : )

The map size happened to fit nicely on my 1080p screen with a size 19 Droid Sans Mono in Cygwin, so I hadn't stopped to wonder about what was setting its parameters.

Hm, the loose cursor blipping around the subwindows is more pronounced in live, I suppose just standing out more due to the latency. It's something I reported to them, but they don't play in Curses over there due to language support--I think--so it doesn't sound like Curses-specific bugs will be a priority for them. https://github.com/hengband/hengband/issues/2014 I tried comparing the cursor-handling bits I could spot in their main-gcu.cpp with Angband's main-gcu.c, buuut it was just "Greek" with minor variations to my non-coder self.

[Gwarl]

3.0.0Alpha51 is up on angband.live but they're missing a few fixes, like support for a main window larger than 80x24 in the curses frontend. I'll see what I can do to fix it in the coming days.

[backwardsEric]

I suspect the compiler is too old, it's gcc 8.4 which is the latest available in the apt repositories available. Is there anything else I can try besides setting up a newer version?

Perhaps replace std::reduce with std::accumulate? std::reduce was introduced in C++-17. std::accumulate should give the same result in this case (though perhaps be less efficient in compute time) and appears to be supported in older versions of the C++ standard.

[Gwarl]

I upgraded to g++ 11 and it compiled...

[Gwarl]

Thanks, that fixed it. I got a couple of other files needing the same fix, now I've run into this

knowledge/knowledge-items.cpp: In function �KIND_OBJECT_IDX collect_objects(int, KIND_OBJECT_IDX*, BIT_FLAGS8)’:
knowledge/knowledge-items.cpp:144:27: error: �reduce’ is not a member of �std’
auto k = std::reduce(std::begin(k_ref.chance), std::end(k_ref.chance), 0);
^~~~~~
knowledge/knowledge-items.cpp:144:27: note: suggested alternative: �deque’
auto k = std::reduce(std::begin(k_ref.chance), std::end(k_ref.chance), 0);
^~~~~~
deque
Makefile:4988: recipe for target 'knowledge/knowledge-items.o' failed

I suspect the compiler is too old, it's gcc 8.4 which is the latest available in the apt repositories available. Is there anything else I can try besides setting up a newer version?

[backwardsEric]

Gwarl, I didn't encounter any problems compiling it on Debian bullseye (Debian's version of gcc 10.2.1 was the compiler). From GitHub's logs for Hengband's Actions, they're successfully compiling it on Ubuntu 20.04 LTS using clang-11 or gcc (gcc version is either 10.3 or 9.3 according to GitHub's summary of the installed software for the Ubuntu runner).

Did you try adding

#include "system/object-type-definition.h"

to src/birth/character-builder.cpp? That might be enough to satisfy unique_ptr's use of sizeof().

[smbhax]

I didn't run into anything like that either when compiling it on my own machine. Some difference in the compiler you're using on live? I hope you can get it working, it would definitely be nice to see there. : )