I really enjoyed reading this tale of optimization lore.
It starts out pretty straightforward, and then it just goes nuts, before finally transcending into opcode glory for the ages.
A friend of mine, a gifted programmer, was nearly finished with a new game. Somehow, he had squeezed into a 1980’s-era PC, pretty faithfully, what was at the time a graphically impressive coin-op game popular at the arcades.
The only problem was that his version of the game was unplayable. It was too slow, and the choppy motion broke the player’s immersion. It was after all a side-scroller.
My friend, who had been working on the game while also taking a full load of college courses, was starting to seem a little frazzled. Fearing that he had missed some easy optimization, he asked me to take a look at the code.
I did. But there was no easy optimization to be found.
The code was tight. Everywhere I looked, he had already done all the things I could think of. Loops had been unrolled. Unneeded draws had been eliminated. All evidence of waste had vanished.
And, with them, our hopes of an easy fix.
But what about a hard fix? A crazy fix?
Well, that was always a possibility.
Note that when he refers to a “1980’s-era PC”, he’s not talking about the 8086-based IBM PC. The word PC refers to multiple devices, and while John Hodgman is probably the funniest, he’s talking about a machine using the 6809 micro: either the TRS-80 Color Computer or the Acorn 2, most likely.