improved GCU code in HEAD

[david3x3x3]

No, I didn't change anything on my PC.

[Magnate]

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.

I shall be forever grateful - it is well beyond my coding ability. I'll happily test patches against any svn revision you care to name.

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"

Thank you. Next time I find myself with borked ASCII (by which I mean evil #s for walls instead of nice solid blocks) I'll run this and report back. Much as I appreciate the sense of your -a and -g options, playing with #s for walls is a total no-go for me. I would rather pull out my toenails.

EDIT: Ok, I just tried this. I found a setup via PuTTY into my Debian-Sid box which gave me #s and no solid blocks available via "Interact with visuals" (which is on the main game options menu in 3.0.9b and is via the feature knowledge menu in 3.1.1). The program simply says:

I am sorry, your terminal does not have the dim string in the capabilities
I am sorry, your terminal does not have the init color string in the capabilities
I am sorry, your terminal does not have the color names string in the capabilities
I am sorry, your terminal does not have ACS characters in the capabilities


Terminal: xterm
You've got 8 colours
You've got 64 pairs of colors possible
To set foreground: ^[[3%p1%dm
To set background: ^[[4%p1%dm
To reset colours : ^[[39;49m
To standout      : ^[[7m
To bold          : ^[[1m
To reverse       : ^[[7m
To blinking      : ^[[5m
To exit standout : ^[[27m
To exit attribute: ^[[0m
To original pairs: ^[[39;49m

... which is fine, but *why* do I have no ACS characters? When I log into that machine directly (not via ssh), the output is slightly different:

I am sorry, your terminal does not have the color names string in the capabilities
I am sorry, your terminal does not have ACS characters in the capabilities


Terminal: linux
You've got 8 colours
You've got 64 pairs of colors possible
To set foreground: ^[[3%p1%dm
To set background: ^[[4%p1%dm
To reset colours : ^[[39;49m
To standout      : ^[[7m
To bold          : ^[[1m
To dim           : ^[[2m
To reverse       : ^[[7m
To blinking      : ^[[5m
To exit standout : ^[[27m
To exit attribute: ^[[0m
To init color    : ^[]P%p1%x%p2%{256}%*%{1000}%/%02x%p3%{256}%*%{1000}%/%02x%p4%{256}%*%{1000}%/%02x
To original pairs: ^[[39;49m

... so what is determining the capabilities of these terminal environments, and how do I affect the provision of ACS characters?

[d_m]

... so what is determining the capabilities of these terminal environments, and how do I affect the provision of ACS characters?

I already responded on IRC, but I will also put it here for posterity. Curses programs use your $TERM environment variable to figure out which capabilities your terminal has. They do this by looking up the terminfo or termcap entry that your system provides for this type. You can read this via "infocmp." For example:

joe@prompt$ infocmp dumb
#       Reconstructed via infocmp from file: /etc/terminfo/d/dumb
dumb|80-column dumb tty,
        am,
        cols#80,
        bel=^G, cr=^M, cud1=^J, ind=^J,

There are two ways to fix this. The first is to specify a "better" TERM variable on the command-line. For instance "TERM=xterm angband -mgcu" This works well when your terminal emulator is confused, or your system hardcodes the TERM to something dumb. Sometimes color problems can be fixed by using "xterm-color" instead of "xterm". EDIT: for experimentation, here are a bunch of terminal types you can try out just to see what happens: ansi, vt100, vt102, vt220, rxvt, dumb, xterm, xterm-color, xterm-256color, screen.

The second way is by creating, or finding, a "better" terminfo entry to use. You can find them online or get them from other systems where things work better. This is kind of annoying, but if your distro gives you bad terminfo entries, it's the only way. You can then compile these with "tic FILE" which will create a local terminfo DB at "$HOME/.terminfo"

Whew! Hope that helps someone out.

[d_m]

I'll happily test patches against any svn revision you care to name.

Ok, I'm attaching a patch that should apply against HEAD. It's not a dirty hack per se, but it's probably not ideal. I was able to replicate your number pad issue (#796) in PuTTY on Linux, and this fixes it for me. Let me know what you get.

[Magnate]

Ok, I'm attaching a patch that should apply against HEAD. It's not a dirty hack per se, but it's probably not ideal. I was able to replicate your number pad issue (#796) in PuTTY on Linux, and this fixes it for me. Let me know what you get.

Yep - works perfectly for me too - it fixes the problems with PuTTY, without causing any difficulties playing in an xterm or a console. Very many thanks.

[Magnate]

Somehow I managed to clobber that code before committing--I had something basically identical which I thought I checked in.

Anyway, thanks for catching that; it's fixed in HEAD now.

Almost: here are my results using angband -mgcu -- -g ...

When I use PuTTY, the walls and floors use the correct ACS characters (solid block and centred dot respectively).

When I use a terminal in GNOME, again both walls and floors are correct.

When I use a linux console, either natively or via direct ssh (not PuTTY) the walls are correct but the floors are big ugly white squares (a very very big dot). I tried using the terminfo entry you sent me (by using TERM=xterm before invoking angband), and it got worse: the walls became the letter a, and the floors became tildes. Weird that it works for you and not for me.

Any idea what could be causing this?

[d_m]

When I use a linux console, either natively or via direct ssh (not PuTTY) the walls are correct but the floors are big ugly white squares (a very very big dot). I tried using the terminfo entry you sent me (by using TERM=xterm before invoking angband), and it got worse: the walls became the letter a, and the floors became tildes. Weird that it works for you and not for me.

Any idea what could be causing this?

I can confirm this behavior on the linux console using ACS graphics.

The floors are currently using ACS_BULLET rather than period when in ACS graphics mode. I'm not sure if there are platforms where this is a significant improvement. It sounds like on the linux console, the ACS_BULLET character isn't a very good one to use.

Unfortunately, I think the fix for this is either changing the "floor" character angband uses back to period (either on a global basis, or in your pref) or using -a to turn off ACS graphics.

I'm going to open a ticket about this. I think the correct resolution is just to always use period, unless there is a terminal for which period is a bad choice, in which case maybe "interact with graphics" or -a are the options.

[Nick]

I can confirm this behavior on the linux console using ACS graphics.

Me too.

I'm going to open a ticket about this. I think the correct resolution is just to always use period, unless there is a terminal for which period is a bad choice, in which case maybe "interact with graphics" or -a are the options.

I'm inclined to think that playing on the linux console is probably not very common now, and maybe you could count on those that do to also be able to handle changing their floor character with a pref file. At least, I was inclined to think that, until I went and checked on a gnome terminal and found bullet and period indistinguishable. So I think this post is a complete waste of everyone's time. Situation normal.

[Magnate]

I'm inclined to think that playing on the linux console is probably not very common now, and maybe you could count on those that do to also be able to handle changing their floor character with a pref file. At least, I was inclined to think that, until I went and checked on a gnome terminal and found bullet and period indistinguishable. So I think this post is a complete waste of everyone's time. Situation normal.

Not so - the bullet and period are distinct: the period is at the bottom of the character, the bullet is in the centre.

I agree that for the Linux console, it is acceptable to expect people to amend their pref files if they wish to use ACS graphics. For me it's well worth doing so in order to have solid walls - others may wish to use -a and play with #s for walls.

I don't think a global replace of ACS_BULLET with a period is a good idea. It does look subtly different.