Flash ANSi viewer and reflections on Flash speed

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.

A quick note, though: that .fla file was made for Flash 6 or something. If you open it on any modern Flash version, it will compile properly but won’t render the ansi screens very well. You need to go to the textfield available on the stage (the one which includes the fonts), click the “Embed…” button on its properties, then select “Basic Latin” and “Latin I” as the character ranges to include.

Originally Flash 6- would include everything, but Flash 7+ grants you more control over the ranges, and unfortunatelly when reading old files, modern Flash versions simply lose that information and stop exporting fonts properly, just picking up the common ones (some letters, some characters).

I am one of those ‘gone but not forgotten’ from the bbs scene from back in the early ’90’s…To mention I’m only 29 years old now going on 30 in a couple of months, but anyway, I am really into the ansi art scene, and I absolutely love that ansi viewer that you made using flash, I would appreciate it if you would consider adding a feature to it so you could choose to add as many ans art photos to the viewer as you wanted, this way it could be used like a flash slide show. I am getting much better in my days in creating bbs type art…

In fact, I have to totally remake my stuff. With Flash 8’s new bitmap capabilities, the ability to read and show ANSI files is much much better now, and can be done much faster, but it has to be redone.

When I get the time I’ll be sure to create a ansi loading class. But right now I’m pretty busy, so I it’ll take some time…

hi i’m very interested in any sort of accelerated ansi viewing that may be possible in flash. I’ve written an app in delphi to convert images over to mono ascii, ‘mirc’ color ascii or ansi, and would like some sort of way to show and/or animate these images…

looking forward to whatever you may come up with for flash ansi viewing zeh, if frame rate could be high enough i’d like to try making some sorta wolfenstein 3d game in ansi output 🙂 or maybe a wing commander style game… i’m blockh34d on yahoo/aim if you ever want to chat, or honkykong on efnet … i’ve done a fair bit with a* too, working on image recognition now, its always nice to have people to chat with AI stuff about, maybe cya later.

Hi Zeh. Just wanted to thank you for the ANSI example. My partner and I are working on making a flash-based game using ansi/ascii art, and this gave us quite a bit of inspiration. We’re probably going to code our own ansi rendering class/method, and we’ll be sure to post that somewhere.

Also, great work with the pathfind stuff on a different page, even if that was a few years ago. Your work is of masterful quality.

Nice! I actually have thrown this specific example away — it uses a lot of AS1 hacks — and started a new “TextScreen” class on AS2 (works kinda like BitmapData, but you can set character tables and basically render ANSI screen easily). I haven’t finished it (there’s no ANSI/PCB/BIN parsing methods yet), but I really think it’s a much better approach than the one I’ve taken on this specific example.

It’s very early in development and I won’t have much time to work on it for a while, so if you’re interested, please mail me at zehfernando ([at]) zeh.com.br and I’ll share it with you.

Chris: not much, I guess, since it’s intended to work as a normal display screen (with write() methods, .cursorX and .cursorY properties, and such). But again, it’s early in development so it doesn’t feature, say, automatic scrolling or word wrapping.