A picture might be worth a thousands words, but icons are a fun way to explore retro apps! Hover over any icon to see the file‘s name, the country of origin, and the name of the media; then go to about page to find links to the original media at the Macintosh Garden!

Despite the popularity of pixel art, modern web browsers have a flaw that have led to a rampant waste. Take this happy Macintosh icon I found on the web:

In its original form, as designed by Susan Kare, this icon was 32×32 pixels. It was packed into a mere 128 bytes on disk and it looked sharp and beautiful. Today, this image of it weighs in at 18,271 bytes and is a bit blurry around the edges.

Search on the web for pixel art and you find plenty bloated by upscaling and then blurred by JPEG compression. Even after this, these images are much larger than they ought to be. I could not find a single icon that was exactly 32×32 pixels—all were engorged to several hundred pixels on a side!

Why is this happening?

A 32×32 pixel icon such as is far too small for today’s displays, but when you try to upscale it using a browser’s the width and height attributes, you will discover browsers provide only two upscaling choices:

• linear interpolation
• nearest-neighbor interpolation

Neither is satisfactory for pixel art: linear filtering blurs the image, while nearest-neighbor introduces inconsistent pixel sizes and shimmering during resizing.

CSS hints at solutions, but they are mostly dead ends: the image-rendering property offers crisp-edges, said to be “best for pixel art or line drawings,” behaves identically to nearest-neighbor in every browser I tried; pixelated was either unsupported or behaved inconsistently.

A possible solution

I was tipped off to a solution in the video Crafting a Better Shader for Pixel Art Upscaling by t3ssel8r, itself inspired by Cole Cecil’s 2017 article Scaling Pixel Art Without Destroying It.

The technique was originally intended for game engines, and SDL3 even includes SDL_SCALEMODE_PIXELART, but it got me wondering whether the same ideas could be brought to the web.

As a proof of concept I created a custom HTML element named <pixel-art>.

Below is a comparison between native images and the custom element.

Resize the container using the handle in the lower-right corner.

Pay particular attention to the middle two examples. They may appear similar initially, but the nearest-neighbor version exhibits shimmering and irregular pixel widths at certain scales. The custom element preserves crisp edges while maintaining consistent pixel geometry.

The final example recreates the classic Macintosh “fatbits” view.

Unlike pre-scaled PNGs, these source images occupy only a few hundred bytes on disk—much closer to how software shipped in the Macintosh era.

Some things are best left to the imagination…

Having a custom element opens up some unthinkable possibilities beyond simple upscaling. For example, supplying as a texture transforms the pixel art into cross-stitch:

Were he still around to see it, Steve Jobs would have had a about this, something like this:

I’ve published an Instructable that shows how to generate super fast analog voltages on an Arduino. Watch the whole video for a very special New Years message!

To find out how I did this, head over to Super Fast Analog Voltages From Arduino

Yesterday my Apple Macintosh PowerBook 3400c died.

This happened just after I had loaded MacOS 8.6 on a 80x 2GB CompactFlash card I got off eBay. My hope was that a solid state boot drive would insure against future mechanical hard drive failures, something I often worry about with my vintage computers. In a cruel yet comical twist of faith, the very act that I hoped to preserve it seems to have killed it.

Mr. Murphy, you never fail to surprise!

This laptop served me well. In college, it was the first laptop I ever owned. Years later, its floppy drive and Ethernet allowed me to image and preserve my remaining vintage Macintosh floppy disks and transfer them into Basillisk II for posterity—later some of these same files would form the basis for my Retroweb Vintage Computer Museum.

With Ethernet, AppleTalk, a floppy drive, PCMCIA, CD-ROM and SCSI, the 3400c was a perfect bridge from the new to the old: with it as a gateway to my modern PC, I lend new life to my childhood Macintosh Plus, loading new-to-me software onto it from the Internet and even helping in the process of loading drivers for a SCSI Iomega Zip drive. The Mac Plus now outlives it and owes much to the 3400c that preceded it.

And so, PowerBook 3400c, with your many peripherals at your side, may you rest in pieces. You will be missed.

UPDATE: It was the AC power brick! With a replacement Apple “yo-yo” power supply from eBay, the Mac is now undead!

Recently I have had the opportunity to try out third demo of “Titanic: Honor & Glory”, a gorgeous game under development by Vintage Digital Revival that recreates the historic ocean liner in stunning detail and realism.

I captured some 360° panoramas from the demo that show you just how realistic and gorgeous the graphics are. Here is a black and white panorama of the first class dining room:

And here is an exterior shot, showing the Titanic in its dock:

I highly recommend you try out the demo yourself. If you would like to create your own panoramas, I have made a YouTube video to document the process. The process should work for any game with a first person vantage point.

The following software was used in the video tutorial:

• Titanic: Honor & Glory Demo 3 (free)
• Image Composite Editor (free)
• Exif Fixer (shareware)

Advanced Tip: The method can also be extended to create equirectangular images, such as this:

The only modification to the technique described in the video is that the in-game footage is captured by sweeping from top to bottom while rotating in a spiral pattern.

I have been working on a game that bridges the new to the old. Maze War is a historic game: it was the very first first person shooter game, released in 1974 for a computer called the Imlac.

Maze War VR is a web game. On the surface, it is an simple web game with a retro feel, but how the first led to the second is a story of how one hack led to another, and then to another, and to many others still.

It Started with a Museum

I have a sweet spot in my heart for retro computers and software. I built an online computer museum, in JavaScript, so that people could interact with vintage computers and learn about them. This is the altruistic reason I share with others: in truth, the project was a selfish excuse for me to spend time tinkering with emulators, old software and Javascript, three things I really enjoy.

Some of the features in my museum stem from a desire to leave no “what if” unexplored. For instance: I made it so the emulated computers could talk to one another, via an emulated serial connection, from one browser window to another. This entailed a series of sub-hacks, including code to emulate a Hayes smart-modem and a virtual telephone exchange complete with made up telephone numbers in the ficticious 555 area code, which would allow one emulated computers to “dial” another via WebRTC data-channels.

One of my early experiments involved running two instances of Battlechess, one on an emulated Macintosh and another on an emulated Commodora Amiga 500 in different browser tabs. Using my emulated modem, I was able to send a move across the line, but not quite reliably enough for a playable game (perhaps Battlechess required serial flow control, which my code did not implement).

MazeWars+ between two emulated Macintosh instances, however, worked perfectly, proving the concept and leading me to want even more than two simultaneous players.

From Emulated Modems to LocalTalk

Having gotten a pair of computers to play Maze Wars+ via a serial link, I set my sights on allowing several to do so. Most of the computers in my museum lacked native networking capabilities, but the Apple Macintosh Plus, the crown jewel of my museum, had in its original form the ability to participate in a LAN called a LocalTalk network. With LocalTalk, Maze Wars+ on the Macintosh supported up to thirty simultaneous players. Thirty is a whole lot better than two.

The Macintosh had a Mini DIN-9 port on its rear called the LocalTalk port. This port served double-duty: it could serve as a serial port or as an interface to the LocalTalk network, via Y-splitters. At minimum, two Macintosh computers could be cabled directly together via their LocalTalk ports, making a small LAN of two, but more often, several computers were daisy chained together into a larger network.

This simplicity lead me to believe that LocalTalk was plain old serial communications, with the transmit and receive lines electrically coupled into a common wire. I suspected that expanding my serial port demo to a LAN would merely involve shuttling serial data from one emulated Macintosh to several others, a trivial modification from sending it to just one, which I had already demonstrated. Easy peasy.

The Zilog E8530 SCC

It turns out I was wrong. The Macintosh uses a chip called the Zilog E8530 SCC, a master-of-all-trades. Yes, it does serial communications, but it also has a much more complex mode called SDLC that forms the backbone of the LocalTalk network. In this mode, the chip is quite sophisticated. It frames packets, senses the media, avoids and detects collisions and computes frame checksums.

The PCE emulator I had been using implemented the serial mode of the Zilog chip, but not the SDLC mode. This task would fall to me. Fortunately, I was able to rely on the earlier work that had been done by Mike Fort for the Mini vMac emulator. Even with that source as my guide and the comprehensive “Zilog SCC/ESCC User Manual”, adding SDLC capabilities to the PCE emulator turned out to be a significant undertaking.

The reward came when I combined this with my earlier WebRTC work to allow several emulated Macintosh computers to communicate using native AppleTalk frames on a simulated inter-browser network. Today, my museum features several multi-player Macintosh games, such as NetTrek, Pararena, and Maze War+.

The Xerox Alto: The Missing Link

My success in making Maze War+, a Macintosh game, playable in LAN mode in my museum lead me to the next step: a step forward but also back in history. The Xerox Alto, a computer developed at the Xerox PARC Labs in the 1970s, is an important player in the history of the Macintosh: it inspired Steve Jobs and his team to develop the Macintosh GUI.

Not only did the Xerox Alto play this pivotal role to the Macintosh, it also ran a much earlier version of Maze War, which had been developed at MIT around 1976. The more I learned, the more I understood that the Xerox Alto could weave together two threads in my museum: the story of the Macintosh as well as the story of Maze War, the game.

At this point, it became inevitable that my museum had to one day have a Xerox Alto running Maze War, in multi-player mode.

The Xerox Alto, in JavaScript.

So inspired in this new mission, I came across an emulator called SALTO and ported it to JavaScript using the EMSCRIPTEN toolchain. Sadly, I found that it was too buggy and slow to be of use.

Further research led me to another emulator, Contralto, that was being developed by the Living Computers: Museum+Labs. This emulator proved to be much more robust, but was written in C#, making my plans of using EMSCRIPTEN to port it to Javascript impossible. Porting it by hand appeared daunting, but another brave individual had already taken up the challenge.

I got in touch with the author of ContraltoJS, a JavaScript port of Contalto, and began collaborating with him. The Ethernet emulation was something the author of ContraltoJS had not yet tackled, so I volunteered to help, hoping that my earlier work with PCE and SDLC would give me the right experience for the job. This turned out to be true and my earlier AppleTalk tunneling code morphed into a general library for tunneling legacy protocols over WebRTC: now capable of both LocalTalk and the legacy Ethernet frames that the Xerox Alto employed.

I eventually demonstrated instances of ContraltoJS running in a LAN in the web browser, playing two multi-player games for the Xerox Alto: Battleship and Maze War.

Rethinking Maze War, in the Third Dimension

Along side my work with emulators, I had been learning THREE.js, a 3D graphics library for the web. It occurred to me one night that making a Maze War clone would be a excellent learning experience. Drawing mazes and spheres is fairly straightforward in THREE.js, after all.

Doing a remake of Maze War did not take me deep enough into the rabbit hole, however,so I decided my version would have to be compatible with the Xerox Alto version. This goal led me to reverse-engineer the legacy Ethernet frames of the original game as it ran under ContraltoJS. These packets were being wrapped and tunneled over WebRTC, so I ended up writing a packet inspection tool for my tunneling library.

The work of understanding the Maze War frames was aided by documentation on the PUP data frames used by the Xerox Alto as well as by code fragments from the original Maze War that were graciously provided to me by the developer of ContraltoJS.

The Last Frontier: Virtual Reality

The last step on this journey was rewriting the game to WebVR specs and Gamepad API. By using Crosswalk, I was able to bring it to mobile phone users. Maze War VR is now available both on the Android store as well as online for all major VR headsets. It has been tested on Google Cardboard, GearVR, Oculus Rift, but should work on any WebVR capable browser. Give it a try. Invite your friends to step right into this historic game with you.

Oh, and don’t forget it is also compatible with Maze War for the Xerox Alto.

One of my long term ambitions for the RetroWeb Vintage Computer Museum was to allow the emulated computers to talk to one another. Last July, after learning about WebRTC and PeerJS, I managed to accomplish first contact. By tunneling serial data over WebRTC, I had an emulated Macintosh running one browser window playing BattleChess with an emulated Commodore Amiga running on another browser window; I then played MazeWars+ with a stranger I met on the MAME IRC channel, showing that playing games originally meant for modem play via the Internet instead, through WebRTC, was not only possible, but also rather fun!

By August, I had become determined to tunnel AppleTalk packets over WebRTC, which would allow MazeWars+ and other multi-player Macintosh games to be played with several players at once. In subsequent posts of this series, I will explain what it took to get there.

The vast majority of THREE.js tutorials contain boilerplate code that assumes the WebGL content will be stretched across the entire window. These examples do not work at all when you try to position the WebGL canvas relative to other elements on the page.

A better approach is to start with code that works in all cases and then use the style sheet to stretch your content fit the entire window (if that is what you want). Doing it right from the start makes it easier to change your mind later and makes your code more flexible.

With this is mind, I am presenting two examples of how to do exactly that.

Example 1: Full window THREE.js using CSS

The first example looks very much like your typical THREE.js program: it shows a WebGL canvas that spans the entire window. The only unusual thing is the pastel background and the white margin.

Let’s walk through the source code to see how it is done. First, I make the body tag to take up the entire window. Doing this requires a trick where I peg each side of the body to the corresponding side of the browser window:

body {
  position: absolute;
  top:      0;
  left:     0;
  right:    0;
  bottom:   0;
  margin:   3em;
}

Second, I set a margin of 3em units to create the white border around the page (you could remove this line if you don’t want a border).

The body element is the parent of the canvas element; with CSS, it is easy to tell the canvas to use all the space available to it in the parent (which is the size of the window minus the margin):

canvas {
  width: 100%;
  height: 100%;
}

Later on (I have separated the positioning and formatting into two separate style sheets), I assign a background color to the page and the canvas:

html {
  background-color: white;
}

canvas {
  background-color: beige;
}

Example 2a: Flowing text around WebGL content

The second example shows text flowing dynamically around WebGL content. This example shows the true power of combining generically written THREE.js code with style sheets.

To do this, I make a change to the style sheet to size and position the canvas element:

canvas {
  float: left;
  width: 50%;
  height: 50%;
  margin-right: 2em;
  margin-bottom: 1em;
}

I set the canvas to be half the width and height of the parent and I tell it to float to the left of the surrounding text; the right and bottom margin control the space between the WebGL content and the text around it.

Provided the JavaScript is written correctly (as I will discuss below), going from one layout to another requires only a small change to the style sheet, as the following example shows.

Example 2b: Interactive Zoom! You can have it both ways!

We can take things one step forward. Since the layout is now controlled directly by the style sheet, it only takes a couple extra CSS rules and a bit of JavaScript to give the user the ability to zoom in on the WebGL content:

canvas.fullscreen {
  position: fixed;
  top:      0;
  left:     0;
  width:    100%;
  height:   100%;
}

canvas:hover {
  cursor:   zoom-in;
}

canvas.fullscreen:hover {
  cursor:   zoom-out;
}

The JavaScript code to toggle the state is equally trivial and could be made even easier if you were using JQuery:

function toggleFullscreen() {
  var canvas = document.getElementById("webgl");
  if(canvas.className == "fullscreen") {
    canvas.removeAttribute("class");
  } else {
    canvas.setAttribute("class", "fullscreen");
  }
  onWindowResize();
}

For simplicity, toggleFullscreen assumes there is just one class, this code will need adjustments if there are additional classes used on the canvas. The call to onWindowResize is necessary to adjust the parameters on the renderer.

What makes it work?

Making these examples work requires some changes to the typical THREE.js setup code. Look at the improved JavaScript code to see these changes.

One key insight came from rioki: rather than using the window’s width and height, I use clientWidth and clientHeight; these are the exact dimension of the canvas element as rendered on the screen, after all CSS rules are applied.

var canvas = document.getElementById("webgl");
camera = new THREE.PerspectiveCamera( 70, canvas.clientWidth / canvas.clientHeight, 1, 1000);

I also tell the renderer the specific canvas I want to use rather than letting it create a new one for me:

renderer = new THREE.WebGLRenderer({alpha: true, canvas: canvas});
canvas.width = canvas.clientWidth;
canvas.height = canvas.clientHeight;
renderer.setViewport(0, 0, canvas.clientWidth, canvas.clientHeight);

Setting the alpha to true allows me to set the background color of the canvas element from the style sheet; setting the canvas height and width to the clientWidth and clientHeight allows the resolution of the canvas to match the size of the canvas as it appears on the screen—these same values are passed on to the THREE.js renderer object.

The “onResize” handler updates everything when the browser window is resized, based on the new clientWidth and clientHeight values of the canvas:

function onWindowResize() {
  var canvas = document.getElementById('webgl');
  canvas.width = canvas.clientWidth;
  canvas.height = canvas.clientHeight;
  renderer.setViewport(0, 0, canvas.clientWidth, canvas.clientHeight);
  camera.aspect = canvas.clientWidth / canvas.clientHeight;
  camera.updateProjectionMatrix();
  render();
}

I came across a blog post that demonstrates using THREE.js to create SVG images. Since that demo was done in CoffeeScript, it took me a while to understand it and build an equivalent JavaScript demo (and the source code).

The SVGRenderer is undocumented in the THREE.js website and it requires a few extra files that are not a part of the standard THREE.js distribution. This post will help you pull the necessary parts together.

My demo is loosly based on this great THREE.js tutorial. I modified it to show the WebGL output on the left-hand side and the SVG capture on the right-hand side. Clicking the arrow updates the SVG capture and shows the code for the SVG on the bottom of the page.

When you hover your mouse cursor over the right-hand side, the paths of the SVG will highlight in red. These correspond to triangles in the original THREE.js model.

The nice thing about rendering THREE.js models as SVG is that the visible faces will become path elements in the DOM, allowing you to highlight them with a single style sheet rule:

path:hover {
  stroke: red;
  stroke-width: 2px;
}

This rule tells the web browser to stroke all path elements in a solid red line whenever the user hovers the mouse cursor over them.

How it works:

The demo uses the undocumented SVGRenderer object from THREE.js. The SVGRenderer object depends on another object called Projector. Neither are part of the official THREE.js build, so I grabbed the two source files from the “examples/js/renderer” directory of the THREE.js distribution from GitHub and placed them in my “lib” directory.

When the user clicks the arrow, the SVG on the right side is updated using a new instance of the SVGRenderer object. Here is what the code looks like:

var svgRenderer = new THREE.SVGRenderer();
svgRenderer.setClearColor(0xffffff);
svgRenderer.setSize(width,height);
svgRenderer.setQuality('high');
svgRenderer.render(scene,camera);

The SVGRenderer will store the SVG data in the domElement attribute of itself. In the following code fragment, I insert it into a parent DIV and remove the width and height attributes from the svg element so that I can scale it with style sheet rules.

svgContainer.appendChild(svgRenderer.domElement);
svgRenderer.domElement.removeAttribute('width');
svgRenderer.domElement.removeAttribute('height');

The SVG source for the bottom panel comes from the svgContainer.innerHTML attribute (domElement.outerHTML would work too). I use a regular expression to break up the source into lines and then post it into the destination text field:

document.getElementById('source').value = svgContainer.innerHTML.replace(/<path/g, "\n<path");

Real world objects have surface texture. In computer graphics, real world materials are simulated by combining bitmapped textures with facet information. Bump maps or displacement maps add fine details to a surface without increasing the polygon count.

3D printing software today does not use textures at all: a model of brick wall, for example, requires many very small polygons to capture details.

One reason is that 3D slicers use STL files which cannot carry texture information. There are several other formats that do, however, so using another file format such as OBJ would solve this problem. A second reason may be that 3D printing happens layer by layer, making it difficult to perform a displacement for all surface orientations.

For vertical surfaces, it would be easy: the slicer would use texture values to displace the print head laterally, perpendicular to the wall contours. For horizontal surfaces, however, the displacement would be above or below the current layer, which would complicate things.

In future posts, I’ll continue to explore the possibility of using textures in 3D printing and will present some work I am doing towards that end.