In 1982, the videogame Yars’ Revenge for the Atari 2600 needed to show a “neutral zone” in the middle of the screen. The console was so primitive – an entire great book was written about this – that it didn’t have any video memory. Any cheap effect would do, even random noise… but something as simple as generating noise was also too much for the underpowered system. So the creator of the game decided to do something that in any other situation would mean at the very least trouble, if not a downright security disaster. He crossed the wires and output on screen… the game’s own source code:

The source code looked noisy enough, and the problem was solved. (Somewhat recently, Retro Game Mechanics Explained analyzed it carefully in this YouTube video, to make sure it’s not just a myth.)

A similar approach was used in a Nintendo GameCube game Metroid Prime, at a moment when the protagonist’s visor needed to appear disrupted. It was two decades later, but the team still bounced off of hardware limitations, this time around memory:

The GameCube only has 24MB of RAM, so every texture has to be carefully considered. If we used a low resolution texture (64x64) to save memory the “static” would be blurry and not crisp. One engineer on the team came up with a great idea: what if we just use the memory holding the Metroid Prime code itself! We quickly tried it out and it looked amazing. When you see Samus’s visor affected by electrical “noise” in game, you’re actually seeing the bits and bytes of the Metroid Prime software code itself being rendered on the screen. Turns out machine code is sufficiently random to work great as a static noise texture!

This is how it looked:

A few years later, in 2008, people working on Xbox 360 were testing a new interface for their entire console. It was called NXE – New Xbox Experience – and in the bottom-right corner it showed delightful ripples:

…or, not just delightful. While NXE was tested internally, the ripples actually encoded the serial number of the console, to prevent leaks. Apparently, it was built specifically so that Microsoft only needed just two images to find out the entire serial number.

A less surreptitious version of this idea exists today – for example, setting up a new Apple Watch shows a pretty pattern…

…that also happens to encode enough information to identify the specific one watch. It really appears to be nothing more than an obfuscated QR Code, and “boy, have they patented it.”

I know concealing a message inside another message is called steganography. I don’t think all of these fall under that umbrella, and I don’t even know all the above can be called “hacks.” I just thought they were interesting examples of information masquerading as noise, and noise pretending to be information.

Duff’s device is a C language technique that looks like this:

send(to, from, count) {
register n = (count + 7) / 8;
switch (count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
}

It achieves two things:

• It unrolls the loop in chunks of eight. Unrolling the loop is when instead of telling the computer “do X 5 times,” you say “do X do X do X do X do X,” trading some code readability and memory usage for higher speed.
• It cleverly (ab)uses a property of the C language to unroll the remainder of the loop, which normally would be impossible to do as the remainder is less than 8 and different every time. It does so by basically overlapping a do/while loop atop a switch/case structure in a way that should come with a coding equivalent of a parental warning.

I always assumed the technique is from the 1970s and was just a show-offy thing that didn’t serve any function, a “look how clever I am” from a programmer who was perhaps just a touch too nerdy. But yesterday, I found a 1988 message from the said programmer, Tom Duff, and it turns out I got almost everything wrong.

First of all, the technique was from 1983, when Duff was at Lucasfilm – much later than I expected.

Second of all, it actually solved a problem. Duff’s device wasn’t just making things faster abstractly, but actually fixed a user-visible performance issue. “[The loop before applying the device] was the bottleneck in a real-time animation playback program which ran too slowly by about 50%,” writes Duff.

Most importantly, however, Duff himself had mixed feelings about it:

Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this discovery.

I recognize this set of feelings from many different software hacks I invented in my life. I think it’s important to carry them all with you – not fall in love with the hack and continue seeing it for what it is (and what it will be in the future as code ages), but at the same time not be above using it if it’s solving a real issue.

Also, Duff adds:

Many people […] have said that the worst feature of C is that switches don’t break automatically before each case label. This code forms some sort of argument in that debate, but I’m not sure whether it’s for or against.

I can’t speak for C, but I have always felt frustrated about JavaScript stealing that convention – it’s so error-prone, and in my many years programming in it, I have never had to use a Duff’s device or anything else that benefitted from it.

A funny and occasionally spicy 15-minute video by Nerrel from October 2024 about some of the nuances and legal fights surrounding Nintendo’s fight with community-made emulators:

The video paints Nintendo in the harsh light, highlighting their double standards and willingness to throw their corporate legal weight around just to squash the challenges before they go to court, despite court precedents ruling against them.

The video also talks about software preservation – this is the part that feels very important to me – and I also learned things about piracy, DCMA, and modern video game encryption.

Just to highlight the versatile value of emulation, in another corner of the emulation universe, I found this fascinating project: a web page called Yes we scan, made by George MacKerron, that promises scanning directly from the browser – for example if you have an old scanner unsupported by your modern OS.

And… it actually works! It combines WebUSB with an interesting technique:

Your web browser emulates a whole PC running Linux with open-source scanning software (SANE). It connects that to your scanner via WebUSB.

If you are interested, the details page has more… well, details. MacKerron also wrote Printervertion that allows you to print directly from web, too, even if your operating system abandoned your vintage printer. The way I understand this, both efforts basically invite an alternative operating system that might be more supportive to take a stab at scanning or printing, and do it in a friendly and sleek way through emulation. It’s kind of incredible this is even possible.

From the Animation Obsessive newsletter, a fun and nicely illustrated recounting of the way Jordan Mechner animated his seminal games Karateka and Prince of Persia. It’s rotoscoping, as everyone knows by now, but on a hard difficulty mode:

Mechner’s setup for Karateka was wild. Over his Moviola screen, he taped thin paper, upon which he traced key frames from the Super 8 footage beneath. Then he took his pencil sketches to a VersaWriter — an early drawing tablet — and traced them on that. Frames of movement became pixels on his computer monitor. From there, he cleaned them up with an art program he’d coded.

If this was a fun read, here’s a good complementary 20-minute video from Ars Technica about a specific challenge in Price of Persia:

Everybody who saw the game oohed and ahhed. It was like a great proof of concept, but it wasn’t that much fun to play, and I kind of had the sinking feeling as I realized that I’ve done almost everything I meant to do, but it just doesn’t have that excitement that I was hoping for.

Also there was a ticking clock, which is that the Apple II platform was dying.

[…] So this was the problem: two years into development, I’d used up all the memory to get as far as I’d gotten, but the game was missing that suspense and excitement and sense of conflict that had made Karateka so simple and so much fun. What was I gonna do?

It’s a great example of a creative technical solution, which also informed the game’s storyline – a perfect collaboration between design and engineering.

(Also: Karateka was already mentioned once on Unsung)

This DOS demo called Wake Up! is astonishingly small – only 16 bytes:

The demo doesn’t just make QUOD feel gargantuan. Output this one solitary emoji, “Woman Technologist with Light Skin Tone” – 👩🏻‍💻 – and you spent all your 16 bytes, too. (Proof!)

The creator’s write-up is a bit hard to follow, but there are some interesting aspects to it: “stealing” the beauty from math itself, the reliance on the environment being set up properly (to avoid wasting precious bytes on initialization), and the tight connection between the hardware, the visuals, and the sound.

Oh yeah, in case you haven’t noticed, this has sound! Two out of 16 bytes are devoted to its production, using an existing BIOS function that slots nicely into the existing graphics routine.

This is another recent demo that caught my attention: NINE, from about a year ago:

The platform here is a computer of a similar vintage as the early DOS machines, Commodore 64. C64, like many other home microcomputers, supported special graphical entities called “sprites,” which were used for gaming since the rest of the graphics couldn’t move very fast. (Today, your mouse pointer is conceptually similar to a sprite, being imbued with special powers unavailable to anything else.)

C64 could output up to 8 such sprites. The demo inexplicably has… nine.

The NINE demo didn’t focus on absolute minimalism, but instead employed a barrage of ghostly (and ghastly!) trickery to achieve something that was thought impossible. This time around, the explainer from the author – a 22-minute YouTube video – is filled with great storytelling, and absolutely worth a watch:

I think both of these showcase two things that I appreciate and that translate to great UX design as well.

The first demo shows tight integration between design and the capabilities of software and hardware. Let’s pick the sound routine that needed just 2 bytes. If there wasn’t a way to output sound within this extremely tight budget, the author likely wouldn’t fight to their death to get sound… they would instead focus on what else was possible within two bytes. This is getting as close to full understanding of the medium you’re working in as possible.

The second demo highlights how sometimes you can use absolutely horrid sleights of hand to achieve something beautiful – and how you can perhaps find beauty in those sleights of hand, too. It reminds me of the quote attributed to Teller (of Penn & Teller):

Sometimes magic is just someone spending more time on something than anyone else might reasonably expect.

Penn & Teller talk a lot about how there are only two keys to their success: going further than others would think, and not worrying about employing inelegant tricks in service of something that would appear to be of utmost elegance.

Today’s computing limitations are different than the ones from the 1980s. But a lot of this attitude can still be helpful, even four decades in, and even if your work seems as far away from the demoscene as you can imagine.

In the Fallout 3: Broken Steel addition, the team wanted to introduce a moving subway train under Washington, D.C.:

However, the engine did not have any moving vehicles. Instead of adding a new kind of primitive into the game engine, the creators… made the player character itself become the subway car when in motion:

This was done by removing freedom of movement from the player, forcing the character to slide on the floor, and equipping him with… a “metro hat.”

The visuals of people hacking this to use it outside of the subway area are really funny:

Technically, it was not a hat, but a right-arm armor, as you can see from the right hand missing in the above picture.

The FPS genre is filled with all sorts of hacks for hand-held weapons, to compensate for the challenges of depicting things accurately not feeling as great…

…but I have never heard of someone “wearing a train.”

(The title comes from this post.)

It’s hard to imagine it now, but during iPhone’s first year, no emoji were available at all. It took four years until 2011’s iOS 5 gave everyone an emoji keyboard.

But in between 2008 and 2011, there existed a peculiar interregnum where emoji were only available on Japanese iPhones. The situation had to be carefully explained and caveated:

Eventually, an enterprising developer realized that emoji outside Japan was as easy as toggling a UI-less preference with a great name KeyboardEmojiEverywhere, hiding inside the innards of the iPhone:

Except, “easy” is in the eye of the beholder. This was still a few too many hoops to jump for an average iPhone user. So, developers figured out that there could be an app for that: the above preference incantation wrapped inside an application with an easy UI, and put in the burgeoning App Store.

The interesting part is that Apple initially fought some of these efforts, by rejecting a Freemoji app and likely a few others. (Not sure if this was about emoji specifically, or more principally about losing control.)

The developers had to get sneaky, and started hiding emoji enablers inside other apps. A $0.99 “RSS reader for a Chinese Macintosh news site” called FrostyPlace unlocked emoji by “simply pok[ing] around in it for a minute or so by tapping in and out of an article and playing with the two buttons at the bottom of its screen. That part is important, so be sure to do some genuine tapping.”

Then there was the free Spell Number (you can still see its old App Store page), where punching in a certain secret number would give you the same.

The author called it an “easter egg” and even wrote candidly at the end of instructions that “you can also delete Spell Number if you don’t want it, the setting will still be here.” (The number also had to change from 9876543.21 to 91929394.59 at some point, perhaps to evade… something?)

Eventually, Apple seemingly gave up – Ars Technica has a fun interview from 2009 from someone who renamed their app from Typing Genius to “Typing Genius – Get Emoji” and got away with it:

Ars: As the screenshot at the start of this post shows, you haven’t been shy about advertising the Emoji support over at App Store. Are you worried that adding Emoji to your application might have negative consequences? Are you worried about Apple pulling it from App Store?

Fung: I’m obviously taking a risk here by advertising Emoji directly on iTunes. That being said, I’m not the first. Worst case scenario, I’ll update the application with Emoji support removed. I’m hoping that Apple will turn a blind eye to this because I can’t see any harm done in allowing users to use Emoji.

Not quite “I am ready to do some time for the good cause,” but close enough.

Yet, it still took until 2011 for emoji support to be universally available with iOS 5, and even then you had to enable the keyboard in settings.

I like this little story of a mysterious latent cool new thing hiding inside your device, a thing that you could unlock only if you followed some seemingly nefarious instructions that never fully made sense but that actually worked.

An interesting tidbit: At least early on in 2008, for emoji to work both the sender and the recipient had to follow the instructions. So the toggle wasn’t just about adding a keyboard, but also enabling the decoding and rendering. (And complicating things further, iPhone’s Japanese keyboard had emoticons, and that keyboard was widely available without any hacks. The difference between emoji and emoticons was not obvious to many people, leading to a lot of extra confusion.)

Lastly, a fun sidebar: I asked about all this an old internet buddy, Steven Troughton-Smith, whom I remembered back from my GUIdebook days, and who still routinely posts fun hacks and discoveries about Apple platforms on Mastodon. I thought “Steven might remember that story; he seems like the kind of person who’d at least know how to find an answer.” Turns out, my hunch was better than I thought: Steven was the enterprising developer who actually discovered how to give emoji to any iPhone, all the way back in 2008.

The year is 1981. Your IBM PC is equipped with a tragic speaker that sounds awful for anything except occasional beeps. (Those beeps sound awful, too.)

You can’t afford a sound card and besides, sound cards for your PC have not been invented yet. You can’t even afford a floppy drive, so you’re one of the rare people who actually uses an audio cassette player as a storage device – a technique usually reserved for more primitive machines that have half the bits your new PC does.

But there’s a silver lining. Your cassette player has a little relay that controls its motor. You can engage and disengage the relay at will.

So, someone figured out that toggling the relay kind of sounds like a metronome. Like percussion. It’s a hack, but in the sonic landscape inhabited solely by your sorry speaker, it’s a breath of fresh air (scroll to 7:26 if you don’t land there automatically):

The year is 2026. Your computer itself is the size of an audio cassette, fits in your pocket, has better storage, graphics, sound, pretty much everything compared to a 1981 PC. It even has a special haptic motor. Except, that motor can only be controlled by native apps, and there is no official API to do it from a browser.

But there’s a silver lining. Tapping any checkbox on a site generates a haptic pulse. And that apparently works even if the checkbox is hidden and if the computer is doing the tapping.

So, someone figured out a way to use that to build a library that gives websites powers to provide haptic feedback. It’s a hack, but damn if it’s not one someone took to its logical conclusion.

I love these kinds of hacks, and I wonder what’s going to happen to this one. Will it fly under a radar, or will some websites start abusing it? If so, will Safari clamp it down, or will it actually give people a proper API for haptics?

A really interesting 28-minute video by daivuk about making a first-person shooter game QUOD that fit in just 64 kilobytes:

I found watching it strangely enthralling and even nerve racking. The creator keeps adding stuff that seemingly has no chance of fitting into such a small space – textures! sounds effects! music! his own language! – and somehow finds a way to squeeze them all in.

This is inspiring, but also practically useful: even though you and I are maybe never likely to need such high optimization, some of these techniques alone could be useful in some tight quarters like a load-bearing CSS file, or embedded software.

As an example, the author wrote his own “music tracker,” which is a clever way to reduce the weight of music: instead of the tune being one big audio file, only the instruments are sampled, and then arranged in repeating patterns.

Except in his case, there were no instruments… just audio effects already existing in the game. And audio effects themselves were generated in a similar way, by combining smaller waves and effects.

The same was done for textures: the creator wrote a bespoke text editor that saves each texture as smaller pieces and combination instructions – a sort of a “PDF” of a texture rather than a more costly scan of the printed page – and re-generates it on entry.

Lastly, this debug view of “cost” was really interesting. (Good debug views, in my opinion, are generally underrated.)