improved GCU code in HEAD

[d_m]

At this point, I think making some subopts to control GCU graphics (e.g. whether or not to use the ACS) would be good. I have definitely seen issues with the ACS in certain UTF-8 terminals, as well as in misconfigured environments.

Well, I've already taken my own advice.

If you play SVN HEAD, as of r1628 you should see two new subopts. -a(scii) does not use the fancy ACS graphic characters, so it will give you old-style # walls. -g(raphics) is the default behavior currently, which mostly means the solid walls using the ACS_CKBOARD character.

While there is an argument (I guess) that manually editing the tiles supersedes this, many terminals don't correctly advertise their capabilities--in those cases, being able to say "this terminal doesn't actually have ACS graphics so don't use them" is nicer than expecting the user to create a custom termcap file, or custom Angband graphics.

[d_m]

I just tried out this version. This has the same problem for me that all of the 3.1.1 versions have had. It could be a problem with my PC configuration. I run the xterm-242-3.fc11.i586 package on Fedora 11. Every time I run Angband within an Xterm window, all of the wall characters are invisible. I prefer playing Angband with # signs for the wall characters rather than solid blocks. I haven't figured out the -mx11 flag to get # signs, either.

Please give me the output of:

infocmp

Are you running from within screen? Over SSH? If I were you, I'd try different TERM types (vt100, xterm, xterm-256color, vt220, etc) to see the different effects. E.g. "TERM=xterm angband -mgcu"

At this point, I think making some subopts to control GCU graphics (e.g. whether or not to use the ACS) would be good. I have definitely seen issues with the ACS in certain UTF-8 terminals, as well as in misconfigured environments.

[Pete Mack]

You can always override the default (borked) prefs with your own.
In the "features" knowledge menu, "interact with visuals", and set the value to what you want. Then save your prefs.
But that's a lot of work, for so many features.

Alternatively, edit font-x11.prf, and delete all the overrides for granite and permanent walls.

[david3x3x3]

I just tried out this version. This has the same problem for me that all of the 3.1.1 versions have had. It could be a problem with my PC configuration. I run the xterm-242-3.fc11.i586 package on Fedora 11. Every time I run Angband within an Xterm window, all of the wall characters are invisible. I prefer playing Angband with # signs for the wall characters rather than solid blocks. I haven't figured out the -mx11 flag to get # signs, either.

[d_m]

1. The numpad keys get messed up sometimes (I think this is specifically related to PuTTY - ticket #796)

I'm going to investigate this... I bet it has to do with calling (or failing to call) the keypad() function, or something else strange. Unfortunately I don't have a Windows machine to test with. I'll see if I can reproduce this with PuTTY on Linux; if not I may be sending some patches your way.

2. The solid wall characters sometimes revert to #s and %s. I think this is locale-related, but I'm not sure. Sometimes I go to "interact with visuals" and find there are no ascii graphic characters at all, only numbers and letters and the basic punctuation symbols.

I'm not really familiar with the "interact with visuals" so you'll have to be more specific about what you're doing. That said, my guess is that this issue has to do with what the value of $TERM is (and by extension, the values in the termino/termcap database on the host you're playing Angband on). I think the graphics come from the ACS (alternate-character set) which xterm and many other terminals define.

I'm attaching a pretty useful C program to inspect what curses believes about your terminal. You can compile it with "gcc -lncurses -o tty-colors tty-colors.c"

[Pete Mack]

I use -mgcu a lot, primarily over ssh (because I haven't yet learned how to set up x11 forwarding!).

ssh -Y doesn't work?

[Magnate]

I just checked in some changes that I hope will make playing Angband in GCU (ncurses) even better than it already is! I mostly play Angband this way, although I'm not sure how many other people do anymore.
...
Anyway, I'm interested in feedback on this.

I use -mgcu a lot, primarily over ssh (because I haven't yet learned how to set up x11 forwarding!). Many thanks for your work on this - your #1 I had noticed before, and I think I had also noticed the colours thing.

But my biggest two issues with -mgcu are both difficult to reproduce:

1. The numpad keys get messed up sometimes (I think this is specifically related to PuTTY - ticket #796)

2. The solid wall characters sometimes revert to #s and %s. I think this is locale-related, but I'm not sure. Sometimes I go to "interact with visuals" and find there are no ascii graphic characters at all, only numbers and letters and the basic punctuation symbols.

If you have any knowledge about either of these I'd be grateful for advice.

[Nick]

Nice - this has gone straight into FA.

[d_m]

I just checked in some changes that I hope will make playing Angband in GCU (ncurses) even better than it already is! I mostly play Angband this way, although I'm not sure how many other people do anymore.

Here are the changes. If anyone either notices problems linked to them, or has other issues, please let me know.

1. On some terminals (gnome-terminal for instance) recent builds end up drawing the background not as black but as a dark-grey, which is disconcertingly bright. In the process of fixing this, I had Angband start using the default-bg provided by ncurses. This will make things like transparency or non-ANSI colored terminals work, rather than drawing black (or dark grey, or whatever).

2. I fixed an obscure autoconf error which meant that terminals with color-changing capabilities would never actually get to do their thing. Probably no one will notice this.

3. I made it so that on terminals supporting 256 colors (e.g. xterm-256color) you get the same range of colors as in the other ports. I have found this to be really nice.

Anyway, I'm interested in feedback on this. Arguably #1 is sub-optimal, since people can choose dumb terminal background colors; I am (perhaps wrongly) assuming that getting things working properly in gnome-terminal, etc. is more important than supporting this.