17 Jun, 2011, Scandum wrote in the 1st comment:
Votes: 0
ANSI colors handle the primary colors: red, green, and blue, as well as secondary colors: yellow, magenta, and cyan.

With xterm 256 colors it's possible to handle the tertiary colors, which is the mixture of a primary and secondary colors. As following:

cyan + blue = azure, blue + magenta = violet, magenta + red = rose, red + yellow = orange, yellow + green = chartreuse, green + cyan = spring green



Traditional MUD color systems use letters to indicate colors, with r, g, b, y, m, c being taken by primary and secondary colors. w is typically white, and d (dark?) is typically used for black. The 6 tertiary colors (azure, violet, rose, orange, chartreuse, and spring green) unfortunately overlap. I came up with the following:

C –> C+B = A = Azure
M –> M+R = P = Pink (Rose)
R –> R+Y = O = Orange
Y –> Y+G = L = Lime or Lawn (Chartreuse)
G –> G+C = S = Spring green
B –> B+M = V = Violet

There may be options I haven't thought of.

Most MUDs will want to convert a 256 color to a 16 color code for older clients, I'll probably do that as following:

B –> Azure
R –> Pink
R –> Orange
G –> Lime or Lawn
G –> Spring green
B –> Violet

For displaying bold I'm leaning toward using intensity 2 for the secondary color, and 5 for the primary color, and for dim 1 and 3 respectively.

I think this covers all the notable colors besides white, grey, and black. Thoughts?
17 Jun, 2011, KaVir wrote in the 2nd comment:
Votes: 0
Don't forget brown - an important colour for ASCII maps!

My snippet already handles ANSI colour downgrading, but it does it based on the RGB values.
17 Jun, 2011, Scandum wrote in the 3rd comment:
Votes: 0
I don't think there's an obvious brown in the 256 color range, though dim yellow comes pretty close.
18 Jun, 2011, donky wrote in the 4th comment:
Votes: 0
Wow the 256 colours don't seem anything that special. This is them, right?

18 Jun, 2011, Raduryn wrote in the 5th comment:
Votes: 0
For being 256 of them, it really looks like many of them are exactly the same, honestly. This is definitely sad… but alot of the lower right corners of those boxes look very similar.
18 Jun, 2011, donky wrote in the 6th comment:
Votes: 0
That 256 colour grid was extracted from a perl script. Looking at the bland array of colours, I feel reminded of plaid.

Here's 16 colour dithering, but it's really only useful as fixed painted tiles since the actual foreground mix is a character. There's no good brown here either. This also reminds me of plaid, but it looks more lively.



I've always wanted to do a display of dithered 256 colours, but never gotten around to it. Really one of the MUD development wikis should go into these things in detail. It's nothing new, and it would give a fuller picture of the scope which telnet can possibly be used.
18 Jun, 2011, KaVir wrote in the 7th comment:
Votes: 0
Scandum said:
I don't think there's an obvious brown in the 256 color range, though dim yellow comes pretty close.

I use "\033
I use "\033[38;5;094m", [url=http://www.godwars2.org/images/plugin_ro... demonstrated in my example RoD plugin[/url]. It looks brown to me.

[quote=[url=/topic-3445-56352#p56352]donky[/url]]Wow the 256 colours don't seem anything that special.[/quote]
Well they're just colours, they're not going to revolutionise your mud or anything - but 256 foreground colours and 256 background colours is certainly a step up from 16 foreground and 8 background. If you want 24-bit colour you could use MXP, but 256 colours are considerably easier to add (as they're implemented in the same way as regular ANSI colours).

8BitMUSH [url=http://8bit.memoryleak.org/]uses the colours for ASCII artwork[/url], but even a "regular" mud can benefit from a wider range of colours…particularly if it uses ASCII maps.
18 Jun, 2011, Scandum wrote in the 8th comment:
Votes: 0
KaVir said:
Scandum said:
I don't think there's an obvious brown in the 256 color range, though dim yellow comes pretty close.

I use "\033
I use "\033[38;5;094m", [url=http://www.godwars2.org/images/plugin_ro... demonstrated in my example RoD plugin[/url]. It looks brown to me.[/quote]
It's technically a shade of orange, but it does look brown indeed. Any suggestions for an abbreviation?

[quote=[url=/topic-3445-56356#p56356]KaVir[/url]][quote=[url=/topic-3445-56352#p56352]donky[/url]]Wow the 256 colours don't seem anything that special.[/quote]
Well they're just colours, they're not going to revolutionise your mud or anything - but 256 foreground colours and 256 background colours is certainly a step up from 16 foreground and 8 background. If you want 24-bit colour you could use MXP, but 256 colours are considerably easier to add (as they're implemented in the same way as regular ANSI colours).[/quote]
With 24 bit colors you'll still have the same 6 tertiary colors. It's great for images, but for distinguishable color differences it's (imo) just as good as 256 colors.
20 Jun, 2011, oenone wrote in the 9th comment:
Votes: 0
Raduryn said:
For being 256 of them, it really looks like many of them are exactly the same, honestly. This is definitely sad… but alot of the lower right corners of those boxes look very similar.


You're male, right? Women have better color vision, so they might be able to distinguish them better…
20 Jun, 2011, donky wrote in the 10th comment:
Votes: 0
oenone said:
You're male, right? Women have better color vision, so they might be able to distinguish them better…
Glass half full kind of guy, right?
21 Jun, 2011, Scandum wrote in the 11th comment:
Votes: 0
From what I gathered women are less likely to be color blind. There's a fairly detailed color blindness test here that checks for 10 variations of color blindness: http://colorvisiontesting.com/ishihara.h... Are you by chance partially color blind donky?

Admittedly the palette looks rather bland, but it's not so bad once you look at the individual colors on a black background.

After some thinkering I switched %d to %e (ebony) using color codes <g05> and <bbb> and added %t (tan) using color codes <eda> and <cba>. Also switched %s to %j (jade) and changed %s to silver to create a 6 color grayscale. That gives a total of 32 different colors.

As green and lime were pretty close I straightened this out by using <afa> for green and the other primary/secondary colors as the bright ANSI version of green is closer to <bfb>.

That adds up to 32 colors with (imo) fairly easy to remember color names.

21 Jun, 2011, quixadhal wrote in the 12th comment:
Votes: 0
That looks pretty good Scandum. I personally don't care for the one-character color code systems (too easy to get false hits from stuff like URL's), but it looks to be at least partially compatible with a few of the Dikurivative systems.

I may have slightly different values for a couple of things, but this shows what my algorithm does when remapping down to ANSI.

22 Jun, 2011, Rarva.Riendf wrote in the 13th comment:
Votes: 0
Scandum said:
As green and lime were pretty close I straightened this out by using <afa> for green and the other primary/secondary colors as the bright ANSI version of green is closer to <bfb>.

That adds up to 32 colors with (imo) fairly easy to remember color names.


Could you also post all the telnet value you use ?
I personally use those
{0, "null", ""},
{1, "red", "\x1B
Could you also post all the telnet value you use ?
I personally use those
{0, "null", ""},
{1, "red", "\x1B[0;31m"},
{2, "green", "\x1B[0;32m"},
{3, "yellow", "\x1B[0;33m"},
{4, "blue", "\x1B[0;34m"},
{5, "magenta", "\x1B[0;35m"},
{6, "cyan", "\x1B[0;36m"},
{7, "white", "\x1B[0;37m"},
{8, "clear", "\x1B[2J\x1B[1;1H"},
{9, "norm", "\x1b[0;0m"},
{10, "grey", "\x1B[1;30m"},
{11, "b_red", "\x1B[1;31m"},
{12, "b_green", "\x1B[1;32m"},
{13, "b_yellow", "\x1B[1;33m"},
{14, "b_blue", "\x1B[1;34m"},
{15, "b_magenta", "\x1B[1;35m"},
{16, "b_cyan", "\x1B[1;36m"},
{17, "b_white", "\x1B[1;37m"},

Someone asked for more colors… and your choices seem quite refined .
22 Jun, 2011, Scandum wrote in the 14th comment:
Votes: 0
I'm planning to release a snippet soon, I'm still working on a better 256 color to 16 color conversion algorithm.
22 Jun, 2011, KaVir wrote in the 15th comment:
Votes: 0
Rarva.Riendf said:
I personally use those

Those are the standard ANSI foreground colours that almost every mud uses, what we're talking about here are the xterm 256 colours. You could in theory just extend your list with more entries like this:

{18, "brown", "\x1B        {18, "brown", "\x1B[38;5;094m"},[/code]However that would only work on certain clients - some players might see strange flashing colours, or black text on a white background, or the actual escape code, or even no text at all.  So in practice you're going to need to differentiate between the old ANSI colours and the xterm colours, with some way for the player to indicate which they support, and some sort of conversion algorithm (or an alternative colour in the table entry).

My snippet automatically determines xterm 256 colour support, and converts to normal ANSI colour when necessary.
22 Jun, 2011, Rarva.Riendf wrote in the 16th comment:
Votes: 0
KaVir said:
Rarva.Riendf said:
I personally use those

Those are the standard ANSI foreground colours that almost every mud uses, what we're talking about here are the xterm 256 colours. You could in theory just extend your list with more entries like this:

{18, "brown", "\x1B        {18, "brown", "\x1B[38;5;094m"},[/code]However that would only work on certain clients - some players might see strange flashing colours, or black text on a white background, or the actual escape code, or even no text at all.  So in practice you're going to need to differentiate between the old ANSI colours and the xterm colours, with some way for the player to indicate which they support, and some sort of conversion algorithm (or an alternative colour in the table entry).

My snippet automatically determines xterm 256 colour support, and converts to normal ANSI colour when necessary.
[/quote]
Oh ok, I never really looked into it, thx for the explanation. I always overided colors in my client so I never bothered before I saw this thread.
22 Jun, 2011, quixadhal wrote in the 17th comment:
Votes: 0
Scandum said:
I'm planning to release a snippet soon, I'm still working on a better 256 color to 16 color conversion algorithm.


The one I use gives pretty decent results, it uses a distance formula to find the "closest" match between palettes. It is slow, but… for xterm256 (and especially if you're really only concerned with 32 values), you can just precompute the conversion and use a lookup.

KaVir has a nice fast formula, but it only uses the 232 inner color values. If you look carefully, you'll see the black and white are actually outside that range (print the darkest black from the 232 middle values on a black background and you can just barely see it… likewise with white).

22 Jun, 2011, Scandum wrote in the 18th comment:
Votes: 0
KaVir's algorithm seems pretty close to what my 2009 256 color snippet uses. It converts as following:



There's quite a bit of room for improvement, I'll probably end up using a 256 entry lookup table as creating a satisfying algorithm will probably be more work.
23 Jun, 2011, quixadhal wrote in the 19th comment:
Votes: 0
Yes, his algorithm is the rightmost column in my image. The middle column is what I use, which does an RGB distance calculation.
23 Jun, 2011, Stendec wrote in the 20th comment:
Votes: 0
I wrote the code that adds 256-colors support to NakedMud available on nakedmud.org. It comes up with an RGB value for the specific color, then converts it to HSV and picks a substitute based on the hue and value (or returns a gray if s is under 0.25).



The actual code can be found at http://pastebin.com/VbWCHpDM, since the code available at http://nakedmud.org/module:colour only has a conversion table in it.
0.0/59