Lobsters retrocomputing - 29 Aug 2026

Page 2 of 2

A. I think the most important thing we did was remove the Mac operating system from the game as mush as possible. We call the MacOS to draw graphics, play sound, or get something from the keyboard. So we're not doing anything with windows. We're not calling our event loop- WaitNextEvent() rather- really often. We call it very infrequently. We're not handling mouse clicks through the operating system. Most of our graphics are bitmaps, so we're not doing a lot of line-drawing calls, rectangle-drawing calls, or other QuickDraw stuff. So really we don't use many OS calls, just Time Manager calls, CopyBits() and GetKeys().

Q. As you built the game, were there instances for which you realized the design was flawed? Flaws where you said, "We need to redesign this for better play," or "It's easier for somebody to navigate around if this code was changed"?

A. Marathon suffered that calamity many times. We did that with the maps. We changed the maps to make the game play different. And we did that with the game code as well. Especially the rendering engine. I forget the exact number, but it was fully rewritten at least three times. It also suffered a lot of small changes here and there. The texture-mapping routines underwent the same thing. They were fully rewritten at least twice. Other parts of the game had the same thing happen. You wrote something and it doesn't work, then you fix it. A lot of times when you do something for the first time, it doesn't work. That happened a lot.

Q. Were there performance issues, where something works, but it's so slow you had to use a different algorithm or change the game architecture slightly or a lot, perhaps to improve performance?

A. Yes, that happened. It's kind of interesting because most of the time, for instance, the rendering engine and texture mapping are the most speed-critical parts, and we rarely rewrote those for speed. We rewrote them because they didn't do something right or we needed to do more with them. Every time we rewrote them, they would get faster, of course, because we would get better at it. So, the only rewrite that was specifically intended to speed the game up was the one that put the texture mapping into assembly. We never rewrote a huge part of the code just because it didn't run quickly. It was usually because it didn't do something we wanted it to do.

Q. These rewrites were more for design or game play issues than for performance.

A. Right. One of the reasons that Marathon was started only in May was that we were rewriting large parts of it that we were not happy with. We could have shipped it at the end of August, but we weren't happy with it, so we didn't. I think that was a really good decision. I would make the same decision again. If I'm not happy with something, we're not going to publish it. We're going to continue to do cool 3-D stuff and we are working on something now, but we're not talking about it.

Q. Will this something use advanced MacOS services like QuickDraw 3D?

A. No, it will not. The hardware acceleration options in Quickdraw 3D are very interesting to us. I'm really excited about having hardware acceleration for 3-D texture mapping. But the software services of QuickDraw 3D, which is primarily what is available now, are not as interesting to us because we'll always be able to outdo the software because we're trying to code a very specific case, and QuickDraw3D handles the general cases.

(c) Hayden Press

All Rights Reserved.

Back to the Marathon's Story page.

Previous page | More Lobsters retrocomputing | Headlines

Original: https://marathon.bungie.org/story/jasonjonesTofTMPG.html