How Zaxxon Taught Me to Program



I don't know many of you remember the arcade game Zaxxon. I do know that seeing Zaxxon for the first time -- in the mid-eighties -- transformed my feelings on user interface.



Until Zaxxon appeared, and even for a significant time thereafter, arcade games were centered in two-dimensional worlds. Space Invaders, Asteroids, Galaga, Qix... some of the names escape me, but they were flat. Stuck in a world that was one pixel deep.



But Zaxxon changed all of the ground rules, introducing a fascinating, unique and three dimensional landscape. And it opened up my eyes to alternative designs for even the relatively tame process-control software I worked on at that time.



Yes, I was still at the O Corporation (described in exquisitely boring detail in earlier blog entries). And one of our more advanced process control devices used a radioactive source (say, Cesium-137) and a matching detector to scan the width of plastic sheets. Here's a stupid-looking text "diagram" that imagines we are standing at the very end of the line looking forward as plastic sheeting comes toward us:

     || -> detector

  ----- Plastic Sheet -----

     || -> source

The sheet would be running in belt fashion toward the end of the line and the detector and source would move in tandem. The software we created would read the measurement signal from the detector, calculate the depth of the plastic sheet along its width, and render a pretty picture of it in 2D.

  X X                  X  X

  X X X       X   X    XXXX

  XXX X X     X   X  X XXXX

  XXXXX X XXXXXX XXX X XXXXX

  XXXXXXXXXXXXXXXXXXXXXXXXXX

  X  X   X     X     X   X X

  X                  X     X

The whole point of our system, though, was not just to render the excess width (and, thus, expensive wastage), but to support real-time control of the width. The problem was the dimensional nature of the sheeting. The plastic was controlled by a series of bolts (around 32, I think). If you screwed a bolt down, less plastic came out at that point. And if you opened it up, more plastic came out.



Making sure the plastic was as flat as possible was the key. No waste, lots of money saved, happy bosses and fat bonus checks. Yeah, sure.



Anyhow, the early attempts at control just divided the width of the plastic into cross-sections, matched each section up with a bolt, and ran a straight PID feedback loop. What they quickly discovered was the "squish" effect. That is if you tried to respond to a bump in the plastic "web" by just screwing down on the bump using PID, you simply got two bumps on either side of the bolt. In other words, the plastic just kind of got "squished" down at that point and resurfaced elsewhere.



I was sent up to company "B" in upstate New York for a month to figure out how to tackle this issue. Luckily, it was the summer. If it had been winter, I might only be surfacing now as a frozen historical oddity like the ancient glacier-dude they found a while back in Switzerland. Only the archaelogists would be wondering about my pocket-protector and tape-covered glasses.



Anyhow, with a week to go, I still hadn't come any closer to a solution to the squish problem. I grew panicky. As I passed a local arcade, I started thinking about Zaxxon and its "3D belt" user interface. Was there a three-dimensional solution to the problem? What if we took adjacent bolts into the equation... and time-phased the bolt adjustment? In other words, could we take another dimension into account?



After a bunch of late night tinkering with the algorithm, I was ready for testing. We kicked off a few runs and, sure enough, the results were much better. We played around with the adjacent bolt algorithm and with the time-phasing. By Friday, we had results that were, for the first time, quite promising.



I learned from that experience the value of embracing new and different concepts, regardless of their origin, background or creators. And, if that meant more time in the arcades playing games, what's not to like?



Return-codes vs. Exception, Part 336



Today I was, purely by accident, browsing the Mozilla documentation for details on their browser architecture. I stumbled upon the following section:

Exceptions / nsresult Code execution can fail at runtime. One programming mechanism to deal with failure is to use exceptions. While Mozilla uses Exceptions in its JavaScript code portions, it does not in C++. One out of several reasons for this is exceptions haven't always been portable, so what was done in the past has stuck. Mozilla C++ code uses return codes to simulate exceptions. That means, while in JavaScript you can use try-catch blocks, in C++ you should check the return code whenever you call an interface method. That return code is of type nsresult. For this reason, the logical return type, as defined in the IDL file, is mapped to an additional method parameter in the C++ code. The nsresult type is intended to transport additional failure reasons. Instead of simply reporting failure or success, an integer type is used instead, to allow for defining a lot of different error codes...

While I realize their solution is specific to C++, I thought it was worth noting.



Mozilla Exceptions / nsresult