Old technology never die, it only gets emulated.

Anyone remember the ANSi format? The ANSi (with a lowercase “i” – ain’t it 1337?) format was used on Bulletin Board Systems (BBS for short) years ago. If BBSs were the world wide web of the 90s, ANSi screens would be the HTML of the 90s. To make a long story short, ANSi screens were a visual format which allowed the user to see a low-resolution graphic in text mode, using a 80 lines/25 column screen and 16 unevenly distributed colors. ANSi screens were the digital graffiti of the past, with its very own culture and community (the “scene”). In a time where internet was still a thing very few people had access to, the ANSi scene was global. Well, before I get too nostalgic and start crying low-res tears, you can find more information on the ANSi format and the underground art scene in this article.

Back to my point: sometime I ago I saw this ANSi viewer by SetPixel built using Shockwave [Director] technology. At the time I wondered if it was possible to build something similar in Flash, and reached the conclusion that before that was even possible, a special font – emulating the DOS characters and corresponding code page – had to be built.

The reason is simple. Setpixel’s solution probably used a graphic character to create the final picture; something I could not accomplish in Flash (with movieclips) because having tons of movieclip instances on the screen (2000 for a small screen) would make it insanely slow. My only choice was using a real textfield and working from that, setting colors and backgrounds.

I couldn’t use a windows font; most of them just barely support some of the classic text mode characters, and when they do, they do it with no regard to the original format of the font. I mean, they don’t have a pixel-by-pixel fidelity. Call me a text mode fidelity maniac. I had to create a DOS emulating font.

So I fired up QuickBasic (!), created a quick program to display all 255 characters directly on screen, and captured the screen using Screen Thief, a classic DOS image grabbing software that has accompanied me for ages (it was mainly created to capture game screens on DOS, but it did capture text screens on graphic format). Zooming on the grabbed image and working on the font software, the Perfect DOS VGA 437 font was born (isn’t that just a bizarre name?). It perfectly emulates the 80/25 text screen used on VGA monitors, encoded using code page 437, for DOS compatibility. It’s a “bitmap” font for Flash (should be used at size 8 for no anti-alias, etc) created to be used on the ANSi viewer.

From that on, building the viewer itself was quite simple. It just reads an .ANS file directly from its location (it’s a viewer, not a converter) as it was a XML file, parses its ANSI control codes (color, position changing) and outputs HTML code. To achieve the desired result – having colored font and backgrounds – two textfields were used: one with the foreground character and color, and one on the background, with a block character using the background color.

The result is a faithful recreation of the way ANSi screens were seen on DOS. Faithful to the fact that gradient characters doesn’t really match when they’re next to each other and the palette colors are uneven. Nice. See this example (small screen), this example (medium screen) or a bit more information.

That brings me to the second point of my post… Flash speed. Yeah.

Some two years ago, I was working on a sound editing (online) application in Flash. It would allow the user to edit several music tracks, turning instruments on or off, and playing them in sequence. It would also allow the user to save the music (send the music via e-mail).

When sending via e-mail, the program would generate a long string containing data for which sound channel: which instruments were on or off, in which position, at which volume and pan settings, and so on. Since the music data wasn’t saved to a server database, all music data was to be transmitted via the URL query strings.

As predicted, the generated string was pretty long, and had to be compressed. Based on the patterns of the generated string, I was able to create a compression scheme that would take standard music sizes (something like 800 characters) and transform that in 100 bytes, using only alphanumeric characters, URL-friendly.

What was funny about this whole process was Flash’s performance. Flash Player version 5 – then standard – would take some 45 seconds to compress a 800-character long string. This in a single loop (through all the string) full of charAt()s and indexOf()s.

Later, the “save/send via e-mail” process was dropped from the application, mainly because the company didn’t want to allocate people to create the sendmail script (!). I didn’t have much time to mess with the data compression algorithm either so I forgot that for a while.

When the Flash player 6 came out I decided to test my compression scheme again. I ran the same test – which took 45 seconds on my test machine – on the new player. The result was something like 1 or 2 seconds. Insanely fast, at least in comparison.

Then it brings me back to my ANSi viewer. While the parsing time is okey for this examples I provide above, it’s important to notice they’re small, ~20 lines examples. Many ANSi screens would take up to 100 or 200 lines on BBS intros, or up to 1000 if you were on crack and feeling like drawing. With a standard 80-line, 35000-byte ANSi screen, render times for this movie increase considerably. The reason is, Flash can’t deal very well with long strings, and this ANSi render process uses very long strings.

As such, even though that’s what I wanted to do, I can’t create a more robust ANSi viewer in Flash, that allows big screens to be scrolled and so on — because it takes forever to render them. I’ve tweaked the rendering process as much as possible (or I like to believe so) and even though I’m happy with the final results, it just displays that Flash is, for now, a toy in which things are nice and easy but not really fast. Not even medium speed.

It’s only natural, then, that I get a bit happy after seeing the few last posts on several Flash-related blogs and news sites: many of them pointed to this post at UltraShock with information gathered from the FlashForward panels regarding the next Flash player speed. Basically, the next player – dubbed Flash X – will perform some 500% faster on a PC, and a bit more on a MAC. They’re mainly array and component measurements, but I guess that’ll also reflect on string management and overall display speed.

Good news. I hope they release that player soon – as rumors go, it’ll be released before Flash MX 2 or Flash 7 or whatever. Hopefully I’ll be able to turn this ANSi viewer into a worthy .ANS displaying solution and even make my pathfinding prototype faster in the process. I’m really curious to see how these two will perform in the new player with no code changes on the scripts themselves.

Oh, and of course: the header on this site is an ANSi logo itself, as is the header on the comments popup.