[T2] ncurses interface problems

[Therem Harth]

I'm now trying to get various things to work properly with the ncurses/GCU interface. The rationale is that ncurses works both on OSX and in X11 environments, and could maybe even be made to work on Windows with PDCurses. Also it's probably easier for a n00b like me to work with than SDL. But I've run into several issues...

Running: shift + direction does not work at all, instead of running you get seemingly unrelated commands. All shifted arrow keys move left one and down one; additionally, left and down ask for a direction, up says "There is nothing to activate", and right displays the character screen. Shifted numpad keys don't have the weird side effects, but don't cause the character to run either - they just move you one space in the specified direction. I have absolutely no idea what's happening with this.

Ctrl-s doesn't save: as mentioned in a thread here a long time ago. ^s works fine, but Ctrl-s to save is intuitive and I want it to work. Again, no idea why it doesn't; AFAIK it's not reserved for anything.

Colors seem off: Certain shades of brown display as bright yellow for instance, some shades of red display as hot pink, and one shade of gray as bright cyan. This is obviously for compatibility with 8-bit terminals, but it looks strange. Maybe someone could advise me on a better way to emulate normal Angband colors on an 8-bit terminal?

If anyone's got some pointers on how to approach these problems, I'd like to hear...

[d_m]

Hi Therem,

Before answering your specific questions, I wonder how much experience you have working with ncurses and terminal emulators? There are a lot of ins-and-outs and so some of your questions might not have easy answers.

Running: shift + direction does not work at all, instead of running you get seemingly unrelated commands. All shifted arrow keys move left one and down one; additionally, left and down ask for a direction, up says "There is nothing to activate", and right displays the character screen. Shifted numpad keys don't have the weird side effects, but don't cause the character to run either - they just move you one space in the specified direction. I have absolutely no idea what's happening with this.

The normal ncurses library isn't able to recognize SHIFT + arrow keys. In fact, there are a wide range of inputs that can't be be distinguished (e.g. CTRL+5) by ncurses' input reader. AFAIK Angband has never support SHIRT+direction for running, but only dot followed by direction.

If you take a look at http://www.leonerd.org.uk/code/libtermkey/ you might be able to get this working... this library does its own input handling and in some cases is able to report this kind of information. There is an outstanding task to try to integrate this into Angband, but we haven't even started yet.

Ctrl-s doesn't save: as mentioned in a thread here a long time ago. ^s works fine, but Ctrl-s to save is intuitive and I want it to work. Again, no idea why it doesn't; AFAIK it's not reserved for anything.

This is probably because your terminal emulator is using CTRL+q and CTRL+s for flow control (xon/xoff). Angband (and many other ncurses programs) have some termios logic on startup to disable this kind of thing, so you'll need to investigate that and compare. CTRL+s should currently work for you in V.

Colors seem off: Certain shades of brown display as bright yellow for instance, some shades of red display as hot pink, and one shade of gray as bright cyan. This is obviously for compatibility with 8-bit terminals, but it looks strange. Maybe someone could advise me on a better way to emulate normal Angband colors on an 8-bit terminal?

Terminal emulators can provide different amounts of color support. Some (e.g. vt100) are monochromatic. Others (e.g. ansi) support 8 colors (16 if you count bold vs unbold). And some support more (e.g. rxvt supports 88 and xterm-256color can support 256).

It's important to be aware that to support more than 16 colors you need two things: both a terminal emulator that can support that many colors (e.g. the xterm program, gnome-terminal, etc) and also be using a TERM variable whose definition on your system claims to provide the right number of colors. For instance, even though the xterm program supports 256 colors, many other terminal emulators use TERM=xterm, so that definition claims to only support 16. You need to use TERM=xterm-256color to get the extended color support.

TL;DR Not all terminal emulators can handle more than 16 colors. Angband only started supporting more than 16 colors fairly recently, and AFAIK very few variants pulled in that support. It's more complicated than it should be, and requires you to understand a little bit about termcap/terminfo, ncurses, etc.

Take a look at V's main-gcu.c file if you want to see how we're currently doing things.

EDIT: Feel free to respond with questions. I just wanted to let you know that you're entering an area that is pitch black, and that you are likely to be eaten by a Grue.

[Therem Harth]

First, thank you very much for answering my questions! Alas I'm quite the novice - been using Linux since I was a teenager, but never really looked under the hood much. (And "using the command line" does not qualify as "under the hood" here.)

The normal ncurses library isn't able to recognize SHIFT + arrow keys. In fact, there are a wide range of inputs that can't be be distinguished (e.g. CTRL+5) by ncurses' input reader. AFAIK Angband has never support SHIRT+direction for running, but only dot followed by direction.

Ah. That's very unfortunate, seeing as curses looks like the best interface candidate for OSX (the SDL interface being sluggish and rather incomplete). It wouldn't be such a problem... Except that the position of the '.' key (at least on laptop keyboards) makes things kind of painful.

Would it perhaps be possible to have an OSX binary version statically compiled against the X11 libraries, so as not to require the OSX SDK just to play the game? That would at least make X11 viable on OSX.

(Note that I know almost nothing about OSX, and won't buy Apple products for personal reasons, so it's all quite theoretical right now...)

This is probably because your terminal emulator is using CTRL+q and CTRL+s for flow control (xon/xoff). Angband (and many other ncurses programs) have some termios logic on startup to disable this kind of thing, so you'll need to investigate that and compare. CTRL+s should currently work for you in V.

Okay, that's good to know. I'll check out the V code and see what I can do.

<snip>

TL;DR Not all terminal emulators can handle more than 16 colors. Angband only started supporting more than 16 colors fairly recently, and AFAIK very few variants pulled in that support. It's more complicated than it should be, and requires you to understand a little bit about termcap/terminfo, ncurses, etc.

Ah, I had thought it was 8 bit color, not 8 colors. My bad.

[d_m]

Ah. That's very unfortunate, seeing as curses looks like the best interface candidate for OSX (the SDL interface being sluggish and rather incomplete). It wouldn't be such a problem... Except that the position of the '.' key (at least on laptop keyboards) makes things kind of painful.

Yeah, it's too bad.

Before you give up, you could give http://www.leonerd.org.uk/code/libtermkey a shot. That said, I doubt most OSX users are going to be super excited about playing in a terminal.

Would it perhaps be possible to have an OSX binary version statically compiled against the X11 libraries, so as not to require the OSX SDK just to play the game? That would at least make X11 viable on OSX.

(Note that I know almost nothing about OSX, and won't buy Apple products for personal reasons, so it's all quite theoretical right now...)

If your users install X11.app then it's possible to build Angband on OSX for X11 (I've done it before). However, it won't work if they don't have X11 installed, and it won't behave how they expect.

I think it will be hard for you to build a good cross-platform experience by yourself. If I were in that position I would be very tempted to just use something like Pygame (http://pygame.org/news.html), which has a relatively good cross-platform experience across Windows/OSX/Linux.

[Therem Harth]

Yes, that is tempting; but T2 is already written in (dodgy) C, with extensions in Lua. Switching it over to pyGame or such would probably take a great deal of effort. Especially as I've come to realize that I basically suck at programming, despite everything I learned in college. I would just have no idea how to approach porting a giant roguelike game from a procedural to an object-oriented model.

[d_m]

Yes, that is tempting; but T2 is already written in (dodgy) C, with extensions in Lua. Switching it over to pyGame or such would probably take a great deal of effort. Especially as I've come to realize that I basically suck at programming, despite everything I learned in college. I would just have no idea how to approach porting a giant roguelike game from a procedural to an object-oriented model.

Ah, right. I forgot that this was all in the context of T2.