Many terminals can support a 256 colors mode, which replaces the standard 16 colors (or rather, 8 plus a brightness bit) with a set of 256 ones.

This is tempting, especially as most Unix terminals do support that extension. Too bad, there are technical issues that turn making this into a default into a not so good idea.

And what would be the benefit of 256 colors ? No, I'm serious. I can easily easily distinguish all the 16 colors of DCSS. With 256 colors, I would probably have to examine monsters quite often. Unless you plan to use them strictly for decorations, in which case DCSS might end up looking cluttered like Dwarf Fortress. Can I have a proof of concept first ? A few screenshots would suffice. — b0rsuk 2010-09-09 06:11

256 colours is certainly not obviously a win, but a few new distinguished colours could help. A current issue is the dark gray elf floor – having one extra shade of “medium gray” there would be quite good. Some vault makers would like to use it for non-important variation (like the colouring of trees); here it would be necessary to be quite careful not to hide important information. — rob 2010-09-09 09:25

This page is here to document the issues.

The problem is that this extension was added with disregard to compatibility. The issues are:

• there is no way to detect this by querying the terminal
• there is no way to make the color codes fall back or be ignored.
  • The code ESC [ 48 ; 5 ; <color> m does not follow the usual rules. ESC [ m codes (“Set Graphics Rendition”) are supposed to be a sequence of independent commands, and terminals are expected to harmlessly ignore any codes they do not recognize. This sequence, however, if is not specially recognized by the terminal, will be misinterpreted as a sequence of: a request to set the background to an invalid value (ignored by most clients), then a code for “turn blink on”, followed by an arbitrary number which again can clash with an existing valid code.
  • Thus, having 256 color mode on when it's not supported will have bizarre visual results.
• detection using the TERM environment variable is unreliable.
  • A bit of history: TERM was supposed to uniquely identify a terminal and its set of capabilities. The problem, though, was that a system that didn't recognize a given value of TERM broken your display nearly completely – and the uptake of new values was/is slow. Heck, even as of 2010, Solaris does not recognize TERM=linux. This resulted in everyone just falsely claiming to be xterm or rxvt.
  • Yet, since in general, those who claim to be xterm tend to do have this support, we may risk breakage by enabling 256 colors in that case.
• we would break any observers on CAO/CDO, and those who watch ttyrecs, if it was recorded with 256 colors but is watched on a terminal without that
  • that client/server thingy can fix the CAO/CDO issue

There's a popular script you can use for testing: [http://www.frexx.de/xterm-256-notes/data/256colors2.pl].

• Windows console
• real Linux console (ie, text mode) (TERM=linux)
• real BSD console (TERM=cons25)
• cygwin/msysgit (TERM=cygwin)
• rxvt (TERM=rxvt)
• urxvt (partial support, colors >87 turn out white) (TERM=rxvt)
• old teraterm (TERM=xterm)
• stterm (TERM=st)
• terminal.app (TERM=linux – wtf??? It's supposed to identify itself, not the platform…)

• screen (TERM=screen)
• tmux (TERM=screen)

• xterm (TERM=xterm)
• libvte (gnome-terminal, roxterm, …) (TERM=xterm)
• konsole (TERM=xterm)
• putty (TERM=xterm)
• new teraterm (TERM=xterm)

• Mac stuff

While, as per the above, having 256 colors by default, or using them in vaults/etc is a bad idea, we may allow players to use them in their config files.

• CAO/CDO would be affected. We may add filtering, but what to convert those colors to?
• ncurses 5.7 is required, 5.6 can't do 256 colors
• the colors are not named.
  • Using a mapping from X11's rgb.txt would be bizarre and require a lookup for any use.
  • The extra colors are a 6x6x6 color cube and a 24 color grayscale ramp. Possible names could be “c025” for 0% red, 40% green, 100% blue and “g23” for the next to the brightest gray.
• we assume the color (including elemental colours) fits in an 8 bit variable in hundreds of places in the code. It may be a lot of work to find all of those.

Thus, I'm certainly not rushing to implement this. Let's concentrate on Unicode support instead, as that works on all supported platforms (aside for bugs in Crawl), can be autodetected, and so on.

Actually, since I'll need to alter the way DGL passes terminal codes to/from the client anyway (to implement charset conversions), adding a 256 color filter might be doable. Detecting new ncurses is also ok (trivial with autoconf, doable with a hack with our current makefiles). Due to detection woes, the colours would have to be explicitely enabled in the config file, but this is also not a show stopper.

There would be two major things to do: replacing every single function and variable that passes colors to use a wide type that can handle both foreground and background, and elemental colors on top (a good piece of legwork), and dealing with places that pass additional flags like branding. I have no clue about the latter. — KiloByte 2011-01-19 13:45