Interesting the article didn't mention the one thing I remember vividly about RIP graphics, which is the rendering process. I always assumed it was vector based because of the way the image would get rendered segment by segment as it was downloaded. It looked like you were watching a video of the artist painting the image. Shapes and lines would get created and filled in and overlayed. On a 2400 modem it was interesting to watch, which was important when you were waiting for data to trickle in. Here's an example:
https://youtu.be/XtWmPO-cLR8
Basically the same effect happened with a lot of DOS shareware drawing programs in the day. The file formats were often instructions like:
Line (20,500) (45, 520) (15)
Line (200,523) (65, 520) (15)
Circle (300, 300) (100) (30)
Fill (50,30) (16)
and so on
If you had a slower computer, or the software wasn't optimized that well, you'd be able to sit and watch your drawing re-draw every time you loaded the file or made certain edits.
Not just DOS, Windows as well. The WMF (Windows Metafile), EMF (Enhanced Metafile) and EMF+ formats are exactly that, except that primitives correspond to GDI or GDI+ calls. And they're still fully supported. Even MSPaint in Win10 can still open them, although it's not listed among supported extensions when you do File -> Open.
According to the article, RIPscrip came to market in 1993 and it was being widely advertised to BBS sysops by 1994. From what I remember of this era, that was simply too late to stand a chance against the juggernaut of the web.
NCSA Mosaic (the first popular graphical web browser) came out in 1992. By the time I first got web access in the fall of 1994, the web was already far larger and more fascinating than any BBS I had ever used. And then Netscape Navigator 1.0 was released on December 15, 1994, and I remember that all my geek friends had concluded that the world was about to change. The early web was captivating.
In 1994 and 1995, a proprietary graphics format from a 6 person company stood no chance.
I do miss BBSs. The shared a lot of the good aspects of forum culture in the mid-2000s, but for a local audience. And they definitely had a true geek spirit. But the early web brought the world to your fingertips.
Yeah, it was just way too late. If it had come out in like '87, and widely deployed by '89, there was a window of 4-5 years that could have worked well; by '93-'94 the action was in running SLIP/PPP on your netcom account to get direct access to the Internet, not dialing up to a BBS.
Part of the beauty about a BBS was that you could access it using anything, even an old or spare computer. All you needed was a modem and text display. An old 286 with a CGA card and 640k RAM was the perfect machine for a BBS, and with an EGA card you could dial in to the few RIP boards that existed.
Sure, you could do so much more with an HTML/browser, but you needed megabytes of ram, a high-res graphics card and monitor, a mouse, and OS like Windows or Mac, a fast CPU...
While it's certainly true BBS access had lower requirements than graphical web browsers, by the time graphical browsers appeared there was a huge population of home systems that could run them.
By 1994 Windows was installed by default on consumer PCs and you'd be hard pressed to buy a new PC that wasn't multimedia capable. The multimedia trend had been pushed by CD-ROM content since the start of the decade. Within a year of Netscape becoming available Windows 95 was the default OS on new PCs. AOL, CompuServe, and MSN also all existed by 1994 and had graphical clients.
So by the time Netscape was first released a majority of PCs in use were easily capable of running it. The number of just AOL users likely dwarfed the number of BBS users even at their peak popularity. C64 and Apple II die hards might have still been dialing their local BBSes but they weren't a majority and BBSes weren't really offering the ease of use as online services and then the web.
Yeah, it's kind of amazing. In 1994 I mostly used BBSs, and through an education grant had an entire 30 minutes per day I could use to dial-in to a very spare text-only Internet terminal with gopher access only.
By 1996 I was helping a startup ISP get off the ground and sending out floppy disks with dial-up internet, email software and a web browser and had pretty much just stopped using BBSs.
It also required its own proprietary dialup client on the user PC end, which meant switching out of whatever dialup BBS-oriented ANSI software you were using that had your list of local BBSes in it. Such as commo: https://news.ycombinator.com/item?id=22957345
The ansi scene is alive today and more vibrant than the past decade. Be sure to pay a visit to 16c and view some of what ansi wizards put out using just those same 16 colors. alpha king / blocktronics
One of the magical things about RIPscrip is that some (most?) viewers drew the art as it loaded in layers, so you got to see the vector art be assembled as your modem worked. Do yourself a favor and download PabloDraw (linked from the article) and view that k!light.rip file (it's part of this pack: https://files.artpacks.org/1999/sadist04.zip).
There have been a few packs released this year, even. It's a fairly tight knit community with most of it on IRC, Discord and Facebook. Check efnet #16c for one of the more active places.
Only a few of my friends ever dialed in but it was a next generation replacement to a custom qbasic bbs that I had written.
The OMNI BBS admin interface seemed to borrow heavily from Visual Basic and even included Basic scripting features so that you could program entire games and experiences. Unfortunately it was very buggy and combined with my amateur coding skills I didn't get very far with anything beyond the basic built-in features of email, message board and file repository.
I remember being at an early BBSCON, perhaps in Tampa. I bought something at a vendors booth. He got on a PC and typed in my order. I asked what he was doing and he explained that he was connected to their BBS in Denver. Once it charged my credit card it was going to print out a mailing label with a bar code. An employee would scan the code, find the book, put it into an envelope and slap on the label.
That book was waiting on my doorstep when I returned from the conference. This was maybe 1989 or 1990, I told my boss that our brand new FAX machine was toast, I'd just seen the future. The really funny thing is that thirty years later that FAX machine (or it's replacement) is still being used.
RIPscrip never took off in my area; but I still BBS to this day and it seems to me that it failed to stick.
Consider the LORD dragon presented in the article in both ANSI and RIP: the _ability_ chasm between the artistic representations is enormous!
ANSI was lovely because it was only a small abstraction beyond text; and the chunky lo-fi art made it accessible to many, without getting ugly.
Consider nowadays where the low-ability alternative to that high fidelity dragon would likely be rendered in shaky mspaint blobs. There's good reason we don't see much of that, and yet in the days of the BBS there was ANSI _dripping_ off the text.
I used to run a C64 CNet based BBS (Tomcat BBS's were very popular in my area). One thing that CNet did that none of the others did was allow you to buffer ANSI/ASCII keystrokes and then play it all back. This resulted in a 'stop motion' style ANSI art "movies". Some of my users were quite good at making these movies, incredibly entertaining too.
The problem I had with RIPscript was back in the 90s on my Mac there were no RIPscript viewers available. It was a DOS only technology, while the Web worked on not only the Mac but also my FreeBSD box. The company was also trying to make a living off of the tech while Mosaic and Apache were free.
The other aspect was that it was relatively hard to make a RIPscript image. You needed a vector graphics artist. The web went with simple raster graphics instead which opened up the talent pool considerably. The bandwidth and memory constraints that RIPscript were built around were quickly demolished in the 90s as computer power skyrocketed and relatively fast modems became cheap.
Ah nostalgia! I "volunteered" at TeleGrafix in HB back in the day. I used to ride my bike an hour after school just to package up RIPterm/paint floppies and use that horrible FedEx PC in the back. I was a fledgling code junkie and had hoped I could glean some of the genius that went into making RIPscrip, though I'm sure it would have gone over my head anyways. I was definitely a bit sad they never "made it big", on the other hand, they never paid me for all those hours I put in (and I never even got to look at any code).
Robo/FX was another graphical BBS that came out in the early 90s. I remember migrating from RemoteAccess to Robo/FX; it was quite the change from ansi art.
In 1986 I was a developer for IBM's IBM PC support BBS. You could access knowledge base articles and patches. At that time we wanted to add graphics and were looking at adding NAPLPS support.
It's interesting to note that the only terminal I use that rendered the VT-100 torture test perfectly is Apple's Terminal. All others balked at double height/width.
Few implement a full set of ANSI SGR commands. VTE and Konsole are the only ones I found that can do overlines (useful in status lines).
Also odd that so many people reinvented wheels - when sixels, Tektronix, Minitel, NAPLPS and others were available, people still invented new "standards", to the point standards became mostly useless.
Back in 1995 I wrote a library for creating BBS Door games using RIP graphics, in QuickBasic 4.5. Also created a RIP Door Game of the classic Battleship game. It never went anywhere as most of my local BBSs started shutting down the following year.
I wrote some JavaScript that draws RIP files into a web canvas, and an experimental RIP to SVG converter. It's still incomplete. Here's the source:
https://github.com/cgorringe/RIPtermJS
1. RIPscrip v1.54, the most popular version, was targeted towards 640x350 px EGA graphics, which is an odd resolution with non-square pixels. They tried fixing this in later versions, but they weren't as popular.
2. Non-standard bezier curves and the flood fill algorithm caused issues with rendering. I've had a lot of issues trying to get it working right as the flood fill would leak through holes in lines which aren't rendered exactly like RIPterm did. And the specs don't give details on how they did it.
hey, this is pretty cool! i've actually been looking for something like this as there is quite a collection of RIPscip files in the archive: https://16colo.rs/tags/content/ripscrip
while they convert to PNG just fine, the realtime rendering was at least half of the experience, especially with the ones that used 'dithering' :) there was a similar issue for viewing ansimation, this was addressed by using the javascript version of ansilove (https://16colo.rs/tags/content/ansimation)
i'd surely be interested in integrating this in case you find the time to resolve the last issues.
The best way I remember enhancing the graphics of my door games, was with those local versions of the game you could install that'd connect using its own protocol to the BBS. Versions of The Pit where you'd get local images and sound files. In a lot of ways that feels closer in step to the web, which focused more on protocols and structure of your data than on how to render your image. RIPscrip maybe intersects with the <form> element.
Flash seems like the more direct competitor that he touches on. It's easier to see in hindsight, but they really won by taking care of the content creators. I tried a few times to make RIP graphics back in the day but could never really figure it out. Flash, in contrast, had an experience for the designers and artists that is still remembered fondly today. It set the course for a whole new generation of animation.
BBS Door Games, I ran a few on my bbs. Unfortunately by 1996 I was getting only a couple of people dialing in any more. Everyone glued to the world wide web even though the world wide web didn't have as many features at that time.
You know, I've been doing a lot of linux / ssh work recently, and I'd love to have something in the console that could give me more of a graphical interface. The midnight commander is good, but a file manager, document preview tool would be awesome. Particularly since so much of the content we produce today is graphical in some way. Something that we could use over SSH without setting up RDP / VNC - I don't need an entire desktop, and often don't have the bandwidth to make it viable anyway. Do you think that something like RIPScript could be used for that? Would there be a way to create a linux graphical terminal?
https://en.wikipedia.org/wiki/Sixel for displaying static images or https://en.wikipedia.org/wiki/ReGIS for vector graphics.
Sadly I think only xterm fully supports these.
Though the modern alternative would be an escape sequence to request a file descriptor into which to just dump an html document. Your OS already has a browser, the terminal should be able to just embed it above the commandline to display graphics.
Wow, seeing the LoRD screen was a punch in the feels! It reminds me of a guy on our bbs who would set his alarm to coincide with the daily Trade Wars reset so he could get his turns in before anyone else.
I am eternally ashamed to admit I never did manage to beat the Red Dragon. Many years later I downloaded the game and ran a local BBS just so I could see what the result was.
Am I misremembering that RIP also added a very boring download step? Like if you play LORD for the first time you have to download a bunch of images that get cached locally. Then the sysop updates to a minor version and you have to download some of the new art.
I thought it was all too slow (both downloading and drawing menus) and the RIP art I saw was mostly very underwhelming, in particular compared to ANSI art.
I have a very distinct memory of a graphical BBS that ran on the Apple II in the late 80s. It's possible it only ran on the IIGS, but I don't think so. I think it used hires mode. My memory is that it was called gbbs, for graphical bbs.
There was something called Greg's BBS, but that's not what I'm referring to.
If such a thing ever existed, I can find no trace of it on the Internet. :-(
Even before reading the article I was going to mention RIP and how it came along just as the web was spinning up. Even if the web never became a consumer-level technology, it was clear that modem speeds were starting to ramp up around this time and BBS systems were starting to take serious looks at moving beyond ANSI and ANSI-like text-mode systems.
RIP was notable because of how much it looked like more serious commercial dial-up systems like the Prodigy On-line service (pre-internet) [1]
One of the ones I remember the best was the FirstClass BBS system for Macs. I think a modern version is still around for school systems. It offered a full GUI, I believe it could transfer multiple things at once, and had pretty good graphics support. There's pitiful little information I can find on the internet for what it used to look like in the mid-90s, but here's one of the best screenshots I can find. [2]
IIR there were maybe 2 or 3 other similar systems, each with their own server-client system and protocol -- these all seem to be lost to time.
The main problem of course is that user-uptake needs to be massive to really make these a success. With ANSI systems, pretty much any dial-up client could connect to any BBS systems regardless of what server software it was running. Even in the case where a weird character set was being sent back (like say when a MS-DOS system connected to an Amiga) you could more or less still use the BBS. But for RIP BBSs (and others like FirstClass), you needed a specialized client to dial-up just the one or two BBSs in your area that provided it, and if you were an avid BBSer, it really took you out of your normal "flow" from your main BBS terminal software.
Once you were connected, the content of a RIP BBS may not have been all that compelling as BBSs were really driven by the interests and passions of the Sysop.
For those that don't remember those days, the average BBS user's workflow looked something like this:
1 - Fire up your dial-up software
2 - Start dialing every single BBS you've been able to dig up and add to your dialer phonebook, this is automatic, but you'll get mostly busy signals since most BBSs are run off of one line.
3 - Eventually connect to one, maybe 20-30 minutes later. Is it one you're really interested in?
4 - Do some things, you only get a few minutes each day.
5 - Disconnect, start dialing again.
Having to jump out of this fairly automated flow to fire up another different client just to dial in to one or two boards was just never going to fly. However, around the time the Web started to really take off some terminal clients were starting to integrate RIP and most RIP servers had an ANSI fallback.
One of the reasons I think the web really took off was that you only needed to connect to your provider, and then all the sites were accessible. You didn't need to jump around between different applications or clients or anything. Just connect once, and you can go everywhere even if the content at that time was more or less the same and graphics and display capability weren't really much beyond what was theoretically already available.
What a blast from the past. I had completely forgot about RIPscrip after I got internet access in 1994, but I remember how awesome it was after years of text-based BBS's.
I watched (literally in Cleveland) getting RIP into Searchlight with LaRosa and Rossiter. TeleGrafix had near-zero footprint in the BBS world. There was no other BBS that used RIP until Searchlight, yet the article does not mention this.
How come BBS + RIP article not mention Searchlight?
I ran a Maximus board connected to FidoNet for a few years. I lost the ansi menus. They were purposefully more simple than what was around, but I thought they were elegant and pretty. Upgrading to rip killed the board for me. I shut it down within a month of that.
I have seen RIPscrip used on the internet, although I had no software to render it so I just got the text based display instead, which nevertheless is fine.
One thing to note in why RIP could have never been successful, aside from originally being closed-source, is while it was vector-based in nature the specification called for a static sized view port of 320x200. Future revisions of the spec could have fixed this but it would have missed the window to be relevant going from BBS to WWW.
