Finally, continuing from part 2, last but certainly not least, we need to talk about color.

Color accuracy in ANSI is something that was occasionally discussed around the scene even in the DOS days, but those issues mostly centered around the particulars of an individual’s monitor’s brightness and contrast settings (or perhaps how rich of a layer of dust had amassed on its surface over the years.) That’s to say, the 4-bit (16 color) VGA palette was pretty much a known quantity. In fact, for backwards compatibility reasons both VGA and earlier EGA’s 4-bit palettes were based on the original Color Graphics Adapter (CGA) modified RGBI palette.

Enter “New Technology“. It took a while for most people in the BBS scene to notice or care since most of us kept running the much more MS-DOS adjacent Windows 9x series of operating systems, but change was in the air. I recall making the switch to using Windows 2000 Professional at work. The first time I did some playing around with an old DOS program, or perhaps it was mTelnet, I was jarred by how utterly jacked up the colors in Windows NT’s new CMD.EXE console looked. Soon after, my friend and sometimes collaborator Grymmjack put out a little release that included a Windows registry file to make the necessary changes to correct them. This file became absolutely mandatory to me and many others as droves of home users finally migrated to the NT series of operating systems with the release of Windows XP in 2001.

So what’s going on with the colors in CMD.EXE? Well, if each of the RGB color values in the 4-bit VGA palette is represented by a value from 0-255, the dark colors are 2/3s the intensity of the bright colors. In other words, 170. Likewise, when an even darker color is desired for mixing colors, 85 is used. Dwelling on this seemingly odd approach a little, I believe the intent may have been that since 0 is considered a color (black) and 255 is most definitely a color (white) only two additional values were needed, with 85 and 170 quartering the scope. Makes sense!

CMD.EXE’s colors, however, seem to be based on the standard 16 color RGB palette. The scope is quartered with the assumption that black is the absence of color. That means we go from 1, to 64, to 128, to 192, to 256 (despite actually being zero-based.) More importantly for our purposes, dark colors use a value of 128 which is 1/2 intensity instead of 2/3s. Whoa! Much more damning, this palette largely does away with the finer mixing of colors with the 1/4 value, meaning the infamous color 6, brown, is now “dark yellow” or “olive” and our bright blue no longer has its beautiful icy hue. Another telltale sign that our palette has been tampered with is that every ANSI artist’s favorite color 8, dark grey, is substantially lighter in this palette. The 4-bit color table in this article demonstrates this well with its first two columns.

Having figured all of that out, one thing I haven’t been able to find any information on is why this was done. Was it the “New Technology” team at Microsoft wanting to cast out the CGA RGBI palette like the dusty old relic that it is? Was it perhaps an intentional shift to a standard RGB palette for some particular technical reason? Maybe it was all a mistaken assumption made by a lone Microsoft developer that has continued to be overlooked all these years? I don’t know. One thing I do know is that it sucks for us ANSI enthusiasts.

Now, with Windows 10 Microsoft has thoroughly tossed out all of the old standards, coming up with a new color scheme called “Campbell” seemingly based on, well, absolutely nothing. This is, instead, apparently an intentional effort to make the colors have higher contrast on modern LCD monitors. Curiously, the palette itself seems to have much less contrast when viewed as a whole. Whatever. For ANSI, these new colors are a total disaster – we have a weirdly orange reds, an almost tan brown, barely distinguishable dark and bright purples. I just… can’t.

So, how do we fix this? Well, if you’re using any version of Windows prior to Windows 10 version 1709 AKA “Fall Creators Update” then the very same registry hack that I mentioned we used to use almost 20 years ago will still work today. Here is a quick bonus archive with my take on all three of the described color schemes in separate registry files for those wanting to experiment. Unfortunately with the newer color scheme changes Microsoft seems to have also changed how CMD.EXE stores its color settings, though you could always try to compile the new “Colortool” and build your own equivalents using the classic RGBI color values. More likely, you’ll just want to go to the properties of your console window, click the “Color” tab, click each individual color, and customize the RGB values there to match those same RGBI colors. While you’re in there, you might as well change your cursor size to “Small” under the “Options” tab and don’t forget to fix your font too.

Here’s my terrible command prompt in Windows 10 using the old CMD.EXE colors (since I upgraded to version 1709 the new color scheme wasn’t forced upon me.) Did I mention that Windows 10’s CMD.EXE now parses ANSI escape codes natively? I just used the “type” command to display this dope Grymmjack ANSI!

Here it is again after fixing the RGB values of the 16 colors, setting them back to the proper RGBI palette. Notice how the dark blue and purple are a little brighter? How bright blue is, well, a totally different color? How the shading seems to be blended a little better, and how the cyan highlights on the font look more appropriate? Most importantly, dark grey has been restored to glory?

Ahhh, much better!

—
1. fil-koku.ans by Filth from Blocktronics: Awaken (2003)
2. gj-drk.ans by Grymmjack from Used #4 (2000)

Now let’s go into a bit more detail about proportion and aspect ratio. An aspect ratio is, at least when we’re talking about displays, the ratio of the width to the height of an image. In Part 1 of this series I talked about how the default CMD.EXE font was totally the wrong size. The end result of this being that the storage aspect ratio was also totally wrong, resulting in proportions being completely different than originally intended by the artist.

Simply put, the 8 x 12px font has the same width as the 8 x 16px, which has to mean its proportions must be different. Let’s take a look at the numbers for a better understanding of why that is. The 8 x 16px font, the width being half the size of the height, has a .5:1 (or 1:2) aspect ratio. The default Windows CMD.EXE 8 x 12px font has an aspect ratio of ~.67:1. Quite different. To have the same proportions, it’d need to be 6 x 12px, which would give it the same .5:1 aspect ratio. For the record, the original 9 x 16px font has an aspect ratio of ~.56:1, which means its actually somewhere in between. If you compare the three images of ACIDDraw I used as example in Part 1, you’ll see they’re all the same width, but with very different heights and, therefore, proportions. Here’s a more direct comparison for the visually oriented, keeping in mind the 9px wide font has been resized to have the same width as the other two:

So which one of them is accurate? Well, talking strictly from an artistic standpoint, whichever one the artist drew it with and/or intended for it to be viewed with. These days, that probably means 8 x 16 but it could easily be any of those. In this case, while its been awhile, I’m pretty sure when I drew that outline I was using the 8 x 16 font. Thanks to more and more modern ANSI editing and viewing applications saving this information in SAUCE meta data and referencing it when rendering, a lot of times it’ll actually be displayed as intended, but that really only goes for much newer art displayed by much newer applications, unfortunately.

Now it’s time to throw a massive wrench into the works. You see, when talking less modern applications, well, none of these are accurate.

The VGA graphics mode that most IBM compatible PCs were using with the now discussed-to-death 9 x 16px font for text mode was running at 720 × 400 screen resolution. Interestingly enough, unlike most of the other screen resolutions we’re used to dealing with these days, 720 x 400 is not a 16:10 storage aspect ratio, but rather 9:5. Weird. That doesn’t really matter though – most EGA and VGA games in MS-DOS were running at 320 x 200 which was indeed a 16:10 storage aspect ratio and they’re still affected by the same issue I’m about to describe. Some of you are probably already honing in on the issue based on the subtext here. That is, none of us had 16:10 widescreen monitors back in the day, now did we? No, we had 4:3 display aspect ratio CRT monitors.

As it turns out, there is a difference between our storage aspect ratio and display aspect ratio, so our pixel aspect ratio isn’t 1:1. Due to their analog, raster scan nature, our old CRT monitors would actually stretch square pixels to be quite a bit taller than they are wide. The stretch from 16:10 to 4:3 is fairly dramatic, as it’ll take little imagination for most of us to recognize since it hasn’t been that long since we moved from 4:3 or 5:4 monitors and TVs to 16:9 and 16:10 widescreen monitors and TVs. What that means is that in addition to needing to use a font that is yet taller than it is wide than the one Windows wants us to use by default, we still need to stretch the entire image vertically by something like 35% to make it look how it would have looked when we were drawing it using something like ACIDDraw or TheDraw back in the day. Here’s a nice video discussing this phenomena as it applies to DOS games, with loads of examples.

Back in the world of text mode, here’s an example of taking the above image with the correct 9 x 16px font in its native 9:5 storage aspect ratio and stretching it to a 4:3 display aspect ratio in an image editor to simulate how it would look on a CRT:

That’s a big difference! I drew that outline without using the stretched aspect ratio so that’s not necessarily “correct” in this case, but the vast majority of ANSI art before the mid 2000s would have probably been drawn in 4:3.

Unfortunately fixing this is way more complicated than changing a font around, and is best accomplished with some form of video manipulation. A lot of retro game emulators, for instance, include some sort of a way to approximate this stretched out display, but unfortunately very few text mode programs I’ve encountered seem to be concerned or even aware that this is a thing. PabloDraw and its short-lived competitor TundraDraw, include an option to emulate this video stretching, meaning ANSI and ASCII fans and artists can still view and draw today using this display aspect ratio if they choose. Sadly, none of the most popular ANSI-BBS compatible telnet and SSH terminals out there that I’m aware of (such as SyncTERM or NetRunner) support any sort of 4:3 aspect ratio emulation. As for CMD.EXE itself? Nope!

So, short of dragging your old CRT monitor out of your attic and plugging it in, then forcing CMD.EXE and the rest of your console applications to run full screen (which doesn’t even appear to work in Windows 10’s new CMD.EXE by the way) there aren’t many workarounds to this issue. DOSBox is a good way of running old DOS programs with an emulated 4:3 display, though you’ll need to tweak the default settings to achieve this. Even still, since DOSBox is developed primarily with running old games in mind, not all old BBS scene related programs will run correctly under it. Perhaps setting it up to dial out to telnet boards would be a good subject for a future article, though! For CMD.EXE and 32 or 64 bit console applications, it seems that sticking with that old trusty 8 x 16px font may be a decent compromise, as it produces a display aspect ratio just a little bit closer to the full 4:3 height than the 9 x 16px font does.

Thankfully, at least viewing standalone ANSI with the correct fonts and aspect ratios is much easier. Besides being supported in PabloDraw, as mentioned, virtually all of the online text mode art viewing sites (such as 16colo.rs) are using the brilliant Ansilove utility to do their image conversion. Ansilove supports both the 9px wide font and, as of this year, the ability to stretch the display aspect ratio as well, meaning modern efforts to display and archive text mode artwork will have a leg up on accuracy.

Well, I didn’t say it was all good news. On to something a little easier to tackle…

—
1. ViiX2 – XXX – We Hijacked!.ans by Jack Phlash, Enzo, and Avenging Angel from Vii-X2 #2 (2005)