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

[smbhax]

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

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

(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.)

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

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.

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

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.

[Gwarl]

Very impressive. And I've been beating my head against ancient versions of angband and Z on the assumption that it wouldn't be that easy (it has never been that easy before).

I'll make my own edits to 3.0.0 and see if it works for me.

[Gwarl]

Just to vent; it never even occurred to me that I could simply walk into main-gcu on 3.0.0 and I spent some time yesterday bashing my head against 2.2.1r2 and that was weird. I was able to completely remove the code that divided the terminal into subwindows there and the terminal was still being divided into subwindows, it was maddening.

Also don't feel bad about just copy pasting bits of code, that's all I do, it's how the "-- -right 40x25,* -bottom *x7" syntax got into angband in the first place (I copy-pasted from poschengband)

[smbhax]

Just to vent; it never even occurred to me that I could simply walk into main-gcu on 3.0.0 and I spent some time yesterday bashing my head against 2.2.1r2 and that was weird. I was able to completely remove the code that divided the terminal into subwindows there and the terminal was still being divided into subwindows, it was maddening.

Also don't feel bad about just copy pasting bits of code, that's all I do, it's how the "-- -right 40x25,* -bottom *x7" syntax got into angband in the first place (I copy-pasted from poschengband)

I was looking through some more files and could swear I just saw some chunk of code that made me think it could still generate subwindows all by itself but eh now I can't find that specifically so I probably just imagined it. 8 o

Good to know about those subwindow size parameters, they do seem like a bit of alien code. ^_^

Good luck with it! I can't say it was easy exactly, but going from Hengband to Angband I just copied in the stuff that seemed like it had to do with subwindows, then walked it back as compile errors came up. Going from Angband to Hengband got a little more intense, particularly when everything compiled except for a conversion or something error about

	t->text_hook = Term_text_gcu;

and I couldn't understand it because that same chunk was in the other version and had always compiled just fine. Wasted a bunch of time scratching my head over the containing term_data_init_gcu function, looking up the text_hook function in a header file, modifying it, which of course broke other areas of the game that use it, giving up entirely, then coming back and trying to make my own new hook function, which of course didn't work. : P As anyone with more experience would know immediately I'm sure, the problem was in the term_text_gcu function, which Angband has as

static errr Term_text_gcu(int x, int y, int n, int a, const wchar_t *s)

but which Hengband needs as

static errr Term_text_gcu(int x, int y, int n, byte a, concptr s)

... Or at least, it seems to. = P

[Gwarl]

yeah both variants have gone their own separate ways... a LONG way, since 2.8.1 which is why I assumed it wouldn't be this easy. Z 2.2.8 was actually more like angband 2.8.3 than it was like angband 2.8.1, which was a relief since I couldn't fix 2.8.1 (I tried). When I fix variants I usually try to find the earliest version of V which has the feature I want and copying from there, since 4.x is so different. I managed z 2.2.8 by reference to z 2.5.2.

Anyway I'm going to take a crack at heng 3.0.0 myself just because I want to do it myself. But you can still take credit for being the first.

[smbhax]

Anyway I'm going to take a crack at heng 3.0.0 myself just because I want to do it myself. But you can still take credit for being the first.

Yeah you'll probably be able to keep some things I had to throw out. : ) I'm just kicking myself for missing the "One does not simply WALK into main-gcu" joke. ^_^

[Gwarl]

Okay so the bigscreen fix itself was incredibly simple, I only had too parse a -b arg and add an if else with a handful of extra lines of code, but I went large and also included the poschengband subwindow layout so it looks scarier than it is

https://github.com/hengband/hengband/pull/2037

[smbhax]

Okay so the bigscreen fix itself was incredibly simple, I only had too parse a -b arg and add an if else with a handful of extra lines of code, but I went large and also included the poschengband subwindow layout so it looks scarier than it is

https://github.com/hengband/hengband/pull/2037

Yours looks nice! This is really cool. = D

[smbhax]

The "-- -o" to use the old subwindow layout won't be too confusing with the older "-o" option for "use original keyset," I suppose?