David L. Craddock writes fiction, nonfiction, and grocery lists. He is the author of the Gairden Chronicles series of fantasy novels for young adults, as well as numerous nonfiction books documenting videogame development and culture, including the bestselling Stay Awhile and Listen series, Shovel Knight by Boss Fight Books, and Long Live Mortal Kombat. Follow him online at www.DavidLCraddock.com, and on Twitter @davidlcraddock.
Bestselling author David L. Craddock presents another round-up of interviews from his 19 years writing books about video games. GameDev Stories Volume 8 broadens the subject matter of the long-running series, branching out into interviews about the construction of the popular tabletop setting the Forgotten Realms and the Magic: The Gathering mythos.
Nearly 19 years into my career as a writer, I've published over two dozen books about how games are made and the people who make them. None of them would have been possible without countless hours of fascinating conversations leading up to all that writing and revising. This eighth volume collects some of my favorites from the past five years. -David L. Craddock, curator
"Stop writing all this good shit. Clickbait us! It's what we are used to!"
– Shacknews Reader"The scale of this is amazing. Holy shit, seven months of interviews, and it just shows everywhere."
– 2018 Kunkel Awards Nominee: Excellence in Feature WritingRandy Linden has gained increasing attention over 2022, and rightfully so. He's worked in game development for years as a programmer, and is most well-known as the wizard behind bleem!, a commercialized emulator for the original PlayStation, and the engineer behind Doom's conversion to the Super Nintendo. It's a conversion that should not exist, given the crudity of the SNES hardware compared to the comparatively more sophisticated PC architecture that Doom ran on when it launched in December 1993. Linden made it happen, but that's another story for another time.
Linden's technical wizardry goes back even further. He wrote a Commodore 64 emulator for Commodore's successor, the Amiga, and managed to convert Dragon's Lair, a beautifully animated adventure game for arcades that ran on a Laserdisc, to floppy disks for the Commodore Amiga. That, too, is a story for a later date. Arguably one of Linden's most impressive feats for which he's gained greater acclaim over the past year is an unfinished port of Quake for the Game Boy Advance.
Let that sink in. Quake, released in 1996 on a fully 3D game engine written under infamously difficult circumstances by id Software mastermind John Carmack and his coding partner Michael Abrash, running on a Game Boy Advance. It was a feat considered as impossible as getting a playable version of Doom up and running on the SNES. But Linden had done that; Quake was simply his next challenge.
In this interview, one of eight I conducted with him for some top-secret projects I've got brewing, Linden and I talked about the origin of Quake on the GBA, why the game remains unfinished, and how he spun off the tools and tech that made the conversion possible into a homebrew first-preson shooter called Cyboid.
**
David L. Craddock: What was the genesis of your interest in bringing Quake to Gameboy Advance?
Randy Linden: It started out from the same perspective that Doom did on the Super Nintendo. It was one of those games that really struck home with me. And I felt that it would be great to bring it to a wider audience. It was obviously on PC, and I think it was on Mac at the time, but that was a small percentage of people. Gameboy Advance was the current hot device. So I took a look at the specs, and I thought, yeah, with a lot of work, this could actually be functional.
I set out down the same path as I did with Doom for the Super Nintendo. I used the reverse engineered specs on the data format: I wrote my own tool chain to process the data into my own format, and I wrote an engine that could take that data and display it.
David Craddock: You had to write a custom engine for Doom on SNES as well, but I wonder if Quake required a different process or approach since it was a true 3D game as opposed to Doom's so-called "2.5D" tech.
Randy Linden: I did the same sort of process where I researched 3D. I've got this technical notebook. It has these little tabs [to delineate[ different sections in the book. So I did all sorts of research on the Gameboy Advance, and its hardware, and on Quake, and on 3D graphics, and on lighting, and on texturing. With all of that knowledge and all of that technology, I started working on a very simple texture mapper. It turned out to be a very, very complicated texture mapper, because it has to do lighting and shading, some accurate texel-accurate rendering. It did a whole bunch of fancy things on the Gameboy Advance. But it all started from a kernel of an idea that was, basically, can I make this work on a popular handheld device, and still have it be playable?
[Author's Note: A texel, short for texture element or texture pixel, is a single unit of a texture map. Much like how sprites are comprised of individuals pixels, a texture is made up of an array, or collection, of texels.]
David Craddock: Nintendo's developers were saying the Game Boy Advance was similar to Super Nintendo, but upgraded a bit. How similar was the GBA to the SNES in terms of working with it? Did your knowledge of the SNES give you a leg up on developing for GBA?
Randy Linden: The Gameboy Advance hardware is very similar to the Super Nintendo hardware. The main difference is the processor. The graphics modes support the ability to have a bitmap. That's advanced, that's new, because the Super Nintendo didn't do that unless you had the Super FX chip. But the main difference was the CPU, which was an ARM TDMI processor, compared to the 65816 of the Super Nintendo, and that difference alone was significant. It was a generational leap forward in technology.
ARM devices are now everywhere. They're in most phones, the vast majority of, of tablets. They're in portable devices. And Nintendo was early on the bandwagon, making a portable game device using it. But the graphics hardware, like I said, was very, very similar to the Super Nintendo.
David Craddock: You've told me how the Super FX technology was integral to getting Doom running on SNES. Was the sophistication of the ARM processor, coupled with your knowledge of how the hardware handled graphics, enough to make up for the absence of something like the Super FX and Super FX2 chips?
Randy Linden: Absolutely. There's no question about it. The processor has the ability to do things like take a source value, perform an operation on it, store it into a destination register [memory address], and shifted by a certain amount all as one single opcode [an instruction that specifies an action to be performed]. It's a very high performance but low powered device. Plus, it had a few modes. I used the fast interrupt mode and the interrupt mode and the undefined mode and the system mode as a way of getting extra registers.
The ARM processor has basically 16 general purpose registers. That's very similar to the Super FX, which has 16 general purpose registers. The big difference is that the ARM registers are 32-bit wide, and the Super FX registers are 16-bit wide. Plus the Super FX had a wide range of opcodes. But the ARM7TDMI had an even wider range of opcodes plus it had what was called a thumb mode, where you could write opcodes that were 16-bit wide, with restrictions on what the opcodes could do. But it allowed you to write code that was twice as dense. This matched well with the Gameboy Advance memory because certain memory was 16-bit wide and other memory was 32-bit wide. So if the memory was 16-bit wide, and you were trying to execute a 32-bit instruction on it, it worked just fine. But it required two memory accesses for each of the halves of the 16-bit. So instead, you could write using this thumb mode, which gave you the majority of the power and flexibility that the ARM mode had, but add half of the size of the instructions.
David Craddock: With Doom, you performed a sort of triage: You would look at the game and make decisions such as well, what can I lose? What can I change? For example, you made the sprites one sided on SNES. Aas you looked at Quake, what were some of the decisions you reached along the lines of triaging to make the game perform as well as possible?
Randy Linden: Good question. I would say that learning from Doom and having to make tradeoffs, I didn't want to make any tradeoffs. I think that the Gameboy Advance prototype that I released shows that there weren't really trade off that were being made. You had the texture mapping, you had the lighting, you had the sub pixel, sub texel accurate rendering, and you had dynamic lighting.
Well, actually, that's not true. There was one tradeoff that was made. I made the decision to go with sprites for the weapons in the prototype that was released. There is an E1M1 version of that prototype that is the first level of Quake that has the weapons rendered in 3D. And the extra cost and overhead of doing that rendering I decided was not enough to lower the frame rate. It was not worth enough in visual fidelity. Plus the weapons as sprites could look better than they could if they were rendered as 3D, because the Gameboy Advance when I rendered the 3D, it was actually using the same trick that I did on the Super Nintendo where I was effectively pixel doubling instead of having every single pixel. So very much like on the Super Nintendo, the weapons could be full fidelity.