Doom 3 owns.

I also got around for an hour or so of Resurrection of Evil; unfortunately I was left less than satisfied. The Grabber weapon is more useful than Half-Life 2's Gravity Gun, but also far less interesting or cool. The physics engine is adequate, but nothing like HL2's Havoc engine, which also detracts from the weapon's cool factor; the whole thing just basically feels like a ripoff of HL2 (which is something id Software should not feel compelled to do). I'll give it a fresh attempt tomorrow.

Finally, of note is the Classic Doom 3 project, which is sort of a must-have for any Doom fan.

I'm generally fascinated by the effects of nuclear bombs. It's not the technology I'm interested in as much as the aftermath; the images from the Hiroshima and Nagasaki bombings, along with the stories and related social phenomena (Godzilla is just a trivial example) hold an irresistible sway over me.

After spending about 20 minutes reading through George Weller's rediscovered report of Japan's nuclear aftermath it was really, very difficult lifting my jaw off the floor. It's an astonishing read, particularly because it combines the early 20th century technical ignorance regarding nuclear weaponry and its various effects with surprising candour and lack of naivette. I was a little concerned with the reliability of the publication, but I suppose having it reported on CNN and subsequently slashdotted lends it at least some credibility.

At any rate if you have any interest in the post-apocalyptic, you owe it to yourself to read the report. That said, you also owe it to yourself to play Fallout. Sleep tight.

Brian Moriarty (creator of Loom) speaks! Besides explaining how Loom was originally meant to be a trilogy, he adds an insight on the reason its sequels never came out:

Contrary to popular belief, the LOOM sequels were not abandoned because LOOM didn't sell well. LOOM has sold more than half a million copies in various formats since it was published in 1990. The reason the sequels weren't made is because I decided I wanted to work on other things, and nobody else wanted to do them, either.

As a huge fan of Loom I'm not sure which saddens me more: the original theory that Loom did not sell well (aside from being an astoundingly good game, Loom had an Israeli version - in native Hebrew no less! - and sold extremely well here), or the fact that the trilogy was simply... neglected.

Another interesting bit of trivia: a Japenese re-arrangement of the soundtrack was made but never released. Moriarty sold one of the only existing copies on eBay last April. I contacted the buyer and hope to get the music available on the internet.

Last but not least, you know you've played way too much Loom when not only do you recognize the source of the following passage, but you can actually hear Cygna's voice in your head when you read it:

Destiny shall draw the Lightning
Down from Heaven; roll its Thunder
Far across the Sea, to where I
Wait upon the Shore of Wonder
On the Day the Sky is oepened,
And the Tree is split asunder.

I somehow managed to miss the release of The Ur-Quan Masters alpha 0.4. Just so you understand, alpha 0.3 was quite stable and I was able to complete a game successfully. Alpha 0.4 is even more stable and adds some more features (PC intro/ending sequences, "triscan" filter to name two). It is the best free PC game you will ever play.

Also, the Precursors' remix project contains some pretty kick-ass remixes and covers of the various SC2 tunes. I've made an addon for Ur-Quan Masters which contains what I perceive as the best version for each tune; I'll post a link when I can find some web-space for that (the package currently weighs in at about 90mb) - alternatively I'll do some reading about the new trackerless BitTorrent and see if I can use it instead.

One thing I do wish UQM had is the ability to select a tune at random from a selection (for example, there are two or three very good versions of the Thraddash theme I would like to be able to put in the remix pack). I'll see if I can file a feature requests or maybe even add it to the source code myself.

Slava, one of my colleagues, asked me to help him out on a strange issue: he's integrating an old 2D vector engine (written in C++/MFC) into a new .NET 1.1 WinForms application. The vector engine exposes an API through a native DLL export, along with a bunch of structures. The issue was with unmarshalling one of the native structures: everything seemed to be unmarshalling correctly except for the double values (we got things like 2.53e-250 - uuh, not likely).

Slava's already managed to consume the same DLL successfully from Delphi, and upon reviewing the two we couldn't find any difference. What we managed to miss at first was that the Delphi marshalled structure was declared with a {$a-} prefix, which means "ignore alignment" - otherwise Delphi might assume that the structure might be in some way memory-aligned.

Figuring that our .NET woes might be due to the same issue, a quick look around MSDN revealed to us that the StructLayoutAttribute(LayoutKind.Sequential) declaration also relied on the "pack" member of the same class, which "controls the alignment of data fields of a class or structure in memory." My logical conclusion as a programmer would be that creating a sequential structure would default to a straighforward memory representation - i.e. no alignment - but apparently it's misguided; .NET defaults to 8-byte alignment for managed structures. We set the alignment size to 4 and voila - problem solved.

This only goes to prove that even the simplest and subtlest of programming challenges can baffle even experienced developers, and both Slava and I wasted quite a bit of time on this issue. The moral? There isn't one, really; just expect to be baffled now and then no matter what you've seen or been through.

It took me ages to understand the fundamentals of internationalization, (man-) language interoperability etc. In fact, only after working on MFC software over a year I encountered a problem so fundamentally accute I couldn't for the life of me figure it out, and it took a bitchslap from my friend Ilya (Konstantinov) to make me halt and figure the problem out properly.

Internationalization is hard. Perhaps its hardest aspect is support for the various languages; each language has its own character set, and although most widely-used languages derive from the basic latin alphabet there are still subtle differences. German makes extensive use of accented characters (é and ü for example); Czech makes use of the relatively unknown caron (č) and that's just the tip of the iceberg. Imagine the thoroughly different requirements of Arabic and Hebrew: complex script languages that are not only written right-to-left, but employ a completely seperate alphabet with different requirements. For example, did you know there are two ways to write several letters in the Hebrew alphabet, depending on their location (middle or end of a word), but those versions of the same letter have the same semanthics? Or maybe you've run into the latin letter Eth (Ð), which to my knowledge only exists today in Icelandic?

Finally, to the point: if you've ever received an e-mail with question marks instead of words, entered a website in your native language but got gibberish instead or perhaps (for the more astute) wondered how it is possible to display text from so many different languages on one document (web site...), you're not alone. Most programmers are completely unaware of these fundamental issues, and cause massive headaches to users and fellow programmers alike. I've come across an article Joel Spolsky wrote back in 2003 with an absurdly long name; no matter: finally someone (certainly with more credability than myself) has taken it upon himself to write a thorough introduction to the subject for people - developers in particular, but the technically savvy among you might also be entertained - who do not realize its importance. Please, please please go and read it before you go on with your daily lives.

Eric Lippert has an incredibly interesting five-part blogpost about the mathematical essence of musical theory, along with some pretty nifty demonstrations. I've dabbled a little in the more practical applications of musical theory before (writing wave and module players and some basic software synths) but honestly have never been really interested in its mathematical/physical aspects.

This, ladies and gentleman, is interesting shit.

• Desafinado, Part One: Eric Continues His Obsession With The Greeks
• Desafinado, Part Two: A Perfect Pythagorean Tuning
• Desafinado, Part Three: Too Many Fifths
• Desafinado, Part Four: Rolling Your Own WAV Files
• Desafinado, Part Five: Getting Down Without Hitting The Bottom

I've been developing Exchange and Outlook-centric applications for the last 4 years or so, and now I can tell you that I have absolutely no nerve endings in my forehead as a result (try bashing your head against the table, keyboard or wall repeatedly for four or so years and you'll see what I mean).

Developing applications for Outlook is an impossibly frustrating task; from the lackluster documentation (MAPI documentation is scarce, not to mention obfuscated and outdated) to unexpected behaviour (Outlook COM API shutdown events never occur) to missing features in high-level APIs (CDO is missing a lot of functionality, and Extended MAPI can only be used from C++ code) to depracated critical features (the password parameter for CDO.Session.Login is ignored outright). All that if you readily ignore proper bugs (CDO session logoff taking between 30 and 180 seconds, instead of - say - 0.02), COM Threading Apartment issues (CDO can only be used from STA threads - say goodbye to convenient remoting or web services) and the ghastly Outlook Object Model guard which made creating an entirely new Extended MAPI wrapper necessary to write the simplest code even for secure enterprises. Are you getting my drift here?

I distinctly recall doing some Outlook add-in work for a guy on Rent A Coder; what was originally intended as an Outlook add-in template on which the guy can build his own code turned into a fully-fledged commercial application, because the buyer simply could not afford to learn Outlook/MAPI basics. The good news for me was that the years of suffering resulted in my becoming something of an Exchange/Outlook expert and that this kind of knowledge pays very well indeed; the bad news are that it's literally impossible to do an Outlook project without reducing your life expectancy considerably (all you cardiologists must be really damn pleased about that).

Anyways I just read that according to Eric Carter I must despair no more! Apparently the new VSTO (Visual Studio Tools for Office) 2005, currently in beta, includes a proper managed API for Outlook. Hurray! Huzzah! Finally Microsoft delivers something for Outlook/Exchange programmers that might not utterly suck. Break out the champagne, everyone - our torment is over!

NOT. Unfortunately the managed API for Exchange is nowhere in sight (mind you, I've been promised an alpha version by a Microsoft premier representative back in September 2003 or so), and Exchange/MAPI programming is still a major hassle (what with the Exchange OleDB provider not functioning under ADO.NET, CDO being STA-only requiring workarounds, WebDAV being slow and often times irrelevant if Custom Forms are used, TNEF specs few and far between etc.) All in all I'd still rather choke than write an Exchange-based service. Fortunately it still pays well enough for me to afford a guy sitting behind me constantly, ready to invoke the Heimlich maneuver at any given moment.

A bunch of tidbits to get you through the day:

1. Three words: what. the. fuck.
2. Do you recall that classic picture of the back of a girl? I recall seeing that picture demonstrating the graphic prowess of generations of computers and video cards (from the earlier Macs, through a friend's 286/VGA machine and the first true color-capable PGA video card another friend used to own). Ilya sent me a link detailing the original story. Interesting, if you're a history buff like me.
3. This (Hebrew only) news post only goes to show that stupidity knows no bounds.
4. While not American, I find the very concept of a senate intelligence committee voting on expanding an already-problematic Patriot Act extremely disturbing. What really yanks my chain, though, was that the vote was held during a secret meeting, to which members of the press were barred entry. Does anyone else consider the very concept of legislation in secret anti-democratic in the extreme?
5. I came across an amusing definition of a particular class of bugs, dubbed heisenbugs. I think I'll start using the term.
6. Finally, it appears we have an Aibo here at work! The damn thing is really disturbing. Photos and experiences to come (as soon as I get my ass off the chair long enough).

One of the most useless, slow and annoying features in Visual Studio.NET (2003 included) is its crappy "dynamic help" feature. It cripples the IDE performance, adds horrendous I/O overhead, pops up on top of the property sheet constantly and is completely useless to boot.

Gladly Fabrice managed to Come up with a way to get rid of it completely! Good riddance to bad rubbish. (Note that the registry change should be made in HKCU and not HKLM)

Update: Alternatively, go ahead and download VSTweak. It does the above and other things as well.