The International House of Mojo

The late 1990s and early 2000s were an unpleasant time for trying to get the SCUMM games running properly on a modern version of Windows. The problem was so institutional that forums reliably came with a sticky thread compiling a list of troubleshooting suggestions and recommended workarounds.

The appearance of ScummVM onto this sorry scene was an absolute godsend. But a reasonable question persisted: Why was it left to fans to reverse engineer a solution? Why didn’t LucasArts bother to grind out some new, Windows XP-friendly interpreters themselves, which ought to have been a relatively easy task for the custodians of the source code?

In fact, the truth is even worse than that: They did make new interpreters, but then mostly didn’t do anything with them.

To further explain this weird but by no means anomalous bit of minced commitment by the studio, which is Exhibit 294 in LucasArts’ proverbial indifference to its own damned catalogue, we turned to programmer Aaron Giles, the man responsible for producing XP-compatible .exe’s for these games in the early 2000s…only to have the fruits of his labor gradually, unceremoniously, and partially condescended to be given the light of day.

---

Could you tell us a little about your background and how you came to land a job at LucasArts?

Sure. In 1994 I was working as a Mac programmer at Cornell University Medical College in Manhattan. LucasArts had just recently released their port of Star Wars: Rebel Assault for the Mac, which I eagerly picked up to play on my fast new PowerMac 6100—one of the very first generation of PowerPC-based Macs. While I thought that the game itself was pretty cool, I couldn’t help but notice that it ran a bit sluggishly in spots on my new machine. Curiosity eventually got the best of me, and I decided to start poking around in the code to see if I could understand why.

As it turned out, the Rebel Assault Mac port was not optimized at all for PowerPC. In fact, it was 100% Motorola 68000 code, and thus when you ran it on a new PowerMac, it ended up running in Apple’s 68000 emulator. Even though my PowerPC was running at a blazing 60MHz, the emulated code was not quite able to consistently match the performance of a native 25-30MHz 68020.

Now, at that time, I was super bullish on the PowerPC. I was doing native PowerPC programming at work and had also been working on porting my postcardware program JPEGView to native PowerPC. Thus, I already knew a decent amount about how the 68000 emulator interacted with native PowerPC code. It didn’t take long for me to come up with some ideas for how I might be able to insert some native PowerPC code into Rebel Assault to make it run more smoothly.

Over the course of a few late nights, I basically ended up reverse engineering the 68000 code that copied pixels to the screen and rewrote it in native PowerPC assembly language. Feeling pleased with the results, I put together a little patcher program that anyone could use to make their Rebel Assault run more smoothly and put it out on the internet for other PowerPC gamers.

The folks at LucasArts soon caught wind of what I had done and started thinking about how they should respond. Luckily for me, their Mac programmer was not only impressed, but was looking to move on to work on Nintendo 64 development. LucasArts flew me out for some interviews to see if I’d fit as their new Mac porting guru, and things went well.

---

---

I believe your first involvement with updating the SCUMM games came in the form of being tasked with some Macintosh ports. Is this the case, and if so how did it then lead to the effort of updating the games for modern Windows? Do you remember what year this would have been?

It’s a bit of a long story, but here goes.

When I first started at LucasArts, I was immediately tasked with porting two up-and-coming games: Dark Forces and Full Throttle. At the time, the Mac was behind in terms of first-person shooter titles—DOOM hadn’t even yet made it to the platform—and so Dark Forces was my #1 priority. But I was equally enthralled by the impressive cinematics, sound, and artwork of Full Throttle, so I put in a decent amount of early work on that.

Fortunately, SCUMM has been ported to a wide range of systems in its history, so doing the port of Full Throttle was relatively painless. The main trick is that Full Throttle was the first SCUMM game to also integrate the INSANE video playback engine that was used for Rebel Assault. In fact, the version of SCUMM that Full Throttle runs on uses INSANE as the layer that talks to the platform-specific hardware. Thus, my main work was to hook up the INSANE engine to the PowerPC Mac hardware. Once that was done, the game pretty much worked without much additional effort. (That work also meant that Rebel Assault II was a breeze to get working.)

Once those first two games were done, I had a bit of a lull before the next games (Rebel Assault II and The Dig) needed attention, since the DOS versions were still being finished. Further, I had pretty much done all the necessary groundwork for both games due to the INSANE work I did for Full Throttle. Looking at the Mac release history, I noticed there were two recent SCUMM games that had never received proper Mac ports: Day of the Tentacle and Sam & Max Hit the Road. Well, that just wouldn’t do.

So I spent a week or two getting those two games up and running. They were both running on older versions of SCUMM. But instead of porting them directly to the Mac, I decided to upgrade them to run on top of the INSANE engine, just like Full Throttle did. And once I did that, they just magically worked on the Mac because INSANE already ran great. When I let marketing know that they had two more unplanned Mac games to release, they kind of freaked out, but eventually came around to the idea and gave them proper Mac releases.

If you’re a Day of the Tentacle fan, you know that it includes a fully functioning version of the original Maniac Mansion embedded in the game. Now, Maniac Mansion had never been ported to the Mac. But I didn’t want Mac users to lose out on the opportunity to play it, so part of the Day of the Tentacle work also involved porting Maniac Mansion to run on top of the INSANE engine so that it too could run on the Mac.

Eventually, I also ported The Dig to the Mac, along with a few other non-SCUMM titles like Afterlife and Mortimer and the Riddles of the Medallion (and even the cute little Indiana Jones and his Desktop Adventures). Then I moved on to work on Windows games, specifically Outlaws and the Jedi Knight expansion pack, Mysteries of the Sith. But after 3.5 years, I decided that I wasn’t really interested in big production games, preferring instead to work on smaller emulation projects. So when an opportunity came up to work at Connectix on their Virtual PC product, I decided it was time to say goodbye to both LucasArts and the gaming industry.

I didn’t think too much about LucasArts for a few years, but in late 2001 I got the idea to start revisiting the old SCUMM games. I wanted to play them on my Windows machine, but the DOS versions weren’t great running on modern Windows. A few years previous, I had joined the MAME emulator project, and in 2001 had just finished switching MAME over from DOS to Windows as its primary platform. So at that point I knew rather a lot about how to modernize old DOS code to run on Windows. That knowledge, plus knowing as much as I did about the SCUMM architecture, plus the work I had already done converting the older games to run on top of INSANE, meant that porting them to work on Windows would be a slam dunk job. If I could get my hands on the code again.

So I reached out to some folks I knew that were still at LucasArts. I suggested to them the idea of letting me do modern Windows ports, with the idea that they could either take my work and re-release the games, or they could just give me permission to independently release Windows executables that would work with the data in the existing DOS releases. It took a few months of back & forth before the potential started to appear, but eventually I was formally approached to do the job.

I know at the time the fan community was desperately interested in official updates to the SCUMM games, so it’s a real shame that was actually undertaken only to be largely shelved. Was it your sense that there was considerable internal interest in re-releasing the graphic adventure classics, or was prepping them for such a possibility more on your own initiative?

I would gauge the internal interest at LucasArts as relatively “meh” on re-releasing the games, especially the older titles. While there were certainly several internal advocates who were excited to see it happen, the overall temperature from the production side was definitely lukewarm. After my initial proposal, I got a few months of radio silence. Then suddenly there was interest in creating a downloadable version of Full Throttle using my updated engine. I think this was going to be a way of drumming up excitement for the ultimately cancelled Full Throttle 2. From there, additional ideas were proposed. I tried to push the older titles but was told flat out that there was little interest in anything before the 256-color era, so it’s hardly surprising to see that nothing really progressed beyond that.

A page on your web site suggests that you updated all twelve of the SCUMM games, notwithstanding LucasArts’ decision to keep many of the updates unreleased. Can you confirm that’s the case?

Actually only 11 of the 12: Maniac Mansion, Zak McKracken, Indiana Jones and the Last Crusade, Loom, Secret of Monkey Island, Monkey Island 2, Indiana Jones and the Fate of Atlantis, Day of the Tentacle, Sam & Max, Full Throttle, and The Dig. I never did any work on Curse of Monkey Island, which was quite different in that it ran at high resolution and used a newer SCUMM engine.

What challenges did you face with standing those games up on a modern machine?

The game engines were written in C. If you’re a C programmer, you know that “int” is a fairly ambiguous type. The original DOS versions assumed that int was a 16-bit value, whereas most modern compilers assume it’s a 32-bit value. A lot of my work involved hacking up the original source code to be explicit about what size any “int” value actually was.

A second challenge involved interrupts. The sound engines all ran at interrupt time, which in the DOS world meant that the main game code would stop execution entirely while the sound engine ran; when the sound engine was done, it returned back to the game code. On modern machines, running something like sound is done on a separate thread. But today, we have multi-core processors, so that sound thread might run at the same time as the game code (just on a different processor), which the original code was never designed to handle. So ultimately I ended up forcing the game and sound threads to all run on the same processor, thus ensuring that when the sound code was running, the game code could not, just as it was in the original DOS days.

Your Mac ports invented a smoothing algorithm that your subsequent SCUMM interpreter carried over as an offered feature. What was the impetus for this effect?

The smoothing feature actually predates my involvement. It was originally designed by Eric Johnston, who named the algorithm “EPX”. It was invented to solve the problem that Macs didn’t have any kind of low-resolution video modes. Pretty much the lowest color mode you could get on the Mac was 640×480 (there was also a 512×384 mode, but it was rare). Conveniently, if you double the 320×200 resolution of the original games, you get 640×400, which fits nicely—with some letterboxing—within the Mac’s 640×480 resolution. Thus all the Mac ports were pixel doubled so they filled the screen.

But because Mac users were used to the full resolution of their machines, the games looked especially chunky if you just doubled the pixels straight. So Eric came up with some clever logic to make more intelligent guesses about how to expand each low-resolution pixel into 4 high-resolution pixels. I believe it was first implemented in the Mac ports of Loom and the original Monkey Island.

When I first started working on Mac ports, we still had the pixel doubling problem, so it seemed natural to incorporate EPX into my work. And when I later did the Windows ports, we were in a similar situation, with 640×480 being a minimal resolution for running Windows. So it was logical to add that as a feature as well.

If you’ve updated all those games, then by implication you’ve seen the source code for all of them -- any amusing discoveries? I hear Loom’s take on the SCUMM engine under the hood was especially…ambitious.

I’ve done a lot of porting work in my career, both at LucasArts and elsewhere, and one of the most interesting things about doing ports is that you often never really get that up close and personal with the details of the original code. If it’s well-written, compiles cleanly, and works without issue, then there’s really no call to dig in and understand what it’s doing.

Overall, I would say the SPUTM engine was quite well written, and thus the need to go in and understand nuances or clever hacks never materialized. So no, I can’t really say anything about what Loom may or may not have done to push the engine to its limits.

One interesting tidbit I ran into when I was given the source code archives was the discovery of a (I believe) never-released DOS version of the 256-color Zak McKracken. Originally the 256 color version was only released for the FM Towns, but it seems that at least some work was done on the DOS side to make it work there as well.

Older versions of SCUMM used a lot of Assembly code. How did you go about converting all that and staying sane?

Perhaps the very early versions of SPUTM had a lot of assembly language, but by the time I got my hands on the source, the only assembly language I had to deal with lived in the sound and video engines. Since I was rewriting those already and redirecting them to talk to the INSANE engine, I mostly ignored the assembly code in favor of writing new code in C.

One exception to this is for the earlier SCUMM games (Maniac Mansion through Loom). Those games didn’t use iMUSE, but rather talked directly to the sound system. For the Windows ports, I opted to emulate the SN76496 sound chip that was in the Tandy 1000 (and the PCjr, which I grew up on), so I had to reproduce the assembly code in C and then modify it to talk to my sound chip emulator.

For Indiana Jones and the Last Crusade and Loom I ideally would have written an AdLib emulator, but I didn’t have the time or access to an appropriately-licensed emulation core. So for Indiana Jones I had it talk to my SN76496 emulator (which admittedly was a significant downgrade from the AdLib sound), while for Loom I focused on the CD-ROM version that had fully digital music and thus didn’t need a fancy music engine.

Did you interface at all with Aric Wilmunder, the so-called “SCUMM Lord” who was instrumental in maintaining the engine for most of its active life?

Oh yes, Aric was super helpful and instrumental in helping me pull together all the necessary resources to make the project happen. He’s much more of a packrat than I am, so he was able to dig out old source code and game versions for me to work with. Aric was always a pleasure to work with, both at LucasArts when I was there, and for the Windows ports after I left.

This one’s really specific, but I was curious if you ever encountered the source code for the Nintendo version of Maniac Mansion, which as I understand it ran on a version of SCUMM specially modified for the NES by David Stifel of Intellivision fame.

Sorry, no, can’t help you there.