QuakeCon 2011 - John Carmack Keynote

QuakeCon Official

AI-assisted summary of QuakeCon 2011 - John Carmack Keynote — original source. Check the original for full context.

Source published: 2011-08-05

Key ideas

Rage spent six years in development, requiring complex four-tier caching and on-the-fly transcoding across multi-threaded pipelines to stream non-repeating MegaTexture assets at a locked 60 FPS on consoles. (0:30)
Carmack strongly advocates integrating static analysis tools like Microsoft's /analyze into daily build pipelines with a zero-tolerance fatal warning policy, citing a statistical failure rate across multi-million-line codebases. (58:01)
To mitigate runtime scripting bugs, id Software developed SuperScript for Doom 4—a fiber-based, native C++ dialect enforcing strict compile-time type safety over dynamic scripting languages. (69:16)
ZeniMax Media officially approved releasing the complete id Tech 4 (Doom 3) source code following the commercial release of Rage, continuing id's long-standing open-source tradition. (83:53)

Detailed notes

## Background Published on YouTube by QuakeCon Official on August 5, 2011, this video captures id Software co-founder and technical director John Carmack delivering his traditional keynote address. In accordance with event tradition, Carmack kicks off the convention with an extensive presentation detailing the studio's recent technological developments and future plans.

## TL;DR Carmack delivers an exhaustive technical postmortem on the six-year development of Rage and the id Tech 5 engine, detailing the architectural compromises of virtual texturing, 60 FPS console performance targets, and multi-tiered storage caching. He dives deeply into software engineering discipline, advocating for static code analysis, safer subsets of C++, and replacing embedded scripting languages with SuperScript for Doom 4. Reflecting on studio growth and industry shifts, he emphasizes the enduring educational value of tight hardware constraints before announcing the upcoming open-source release of the complete id Tech 4 (Doom 3) codebase.

## Atmosphere & style The presentation carries the hallmarks of an authentic, unscripted masterclass, feeling less like a corporate keynote and more like an intensely focused engineering postmortem delivered straight from memory. Carmack speaks with rapid, unfiltered candor, transparently breaking down production missteps, memory bottlenecks, and compiler behaviors without relying on polished marketing rhetoric or visual slides. The atmosphere is earnest, intellectually rigorous, and grounded in a quiet pragmatism that balances self-critique over elongated dev cycles with an unmistakable reverence for foundational systems programming.

## Bulletin - [00:30](https://www.youtube.com/watch?v=4zgYG-_ha28&t=30s) Rage spent six years in development, requiring complex four-tier caching and on-the-fly transcoding across multi-threaded pipelines to stream non-repeating MegaTexture assets at a locked 60 FPS on consoles. - [58:01](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3481s) Carmack strongly advocates integrating static analysis tools like Microsoft's /analyze into daily build pipelines with a zero-tolerance fatal warning policy, citing a statistical failure rate across multi-million-line codebases. - [01:09:16](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4156s) To mitigate runtime scripting bugs, id Software developed SuperScript for Doom 4—a fiber-based, native C++ dialect enforcing strict compile-time type safety over dynamic scripting languages. - [01:23:53](https://www.youtube.com/watch?v=4zgYG-_ha28&t=5033s) ZeniMax Media officially approved releasing the complete id Tech 4 (Doom 3) source code following the commercial release of Rage, continuing id's long-standing open-source tradition.

## Key takeaways - [06:44](https://www.youtube.com/watch?v=4zgYG-_ha28&t=404s) Targeting a locked 60 FPS on Xbox 360 and PlayStation 3 forced strict trade-offs, including abandoning dynamic lighting and accepting visible texture streaming delays. - [11:13](https://www.youtube.com/watch?v=4zgYG-_ha28&t=673s) Transitioning from continuous heightmap terrain to modular, stamped geometry caused GPU page cache fragmentation and required custom multi-tier physical caches. - [19:20](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1160s) Console hardware limitations, particularly slow optical media read speeds and split memory architectures, severely bottlenecked high-resolution texture streaming. - [25:17](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1517s) Despite having ten times the compute power of consoles, high-end PCs suffered from driver overhead and API abstractions that hindered consistent 60 FPS performance. - [31:12](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1872s) Carmack lobbied GPU vendors to support adaptive V-Sync and negative swap intervals to tear immediately on missed render deadlines instead of stuttering down to 30 FPS. - [36:35](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2195s) Real-time rendering graphics have passed the knee of the curve, yielding diminishing visual improvements for exponential increases in production pipeline effort. - [48:11](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2891s) Rage source assets exceeded 64 gigapixels and required heavy JPEG XR/HD Photo compression, which sometimes leaves surfaces soft under point-blank examination. - [52:20](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3140s) Aggressive post-processing effects and tone mapping often degrade fine, compressed texture details that engineering teams worked hard to preserve. - [01:02:43](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3763s) Static code analysis tools like Coverity and Microsoft's /analyze surfaced hundreds of latent logic bugs, justifying mandatory zero-tolerance compiler warning rules. - [01:06:54](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4014s) Allowing non-programmers to write dynamic scripts introduces major stability and performance risks, which id Software countered by rewriting UI code into native C++. - [01:09:16](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4156s) Carmack advocates restricting 95% of game engineering to a memory-safe, Java-like C++ subset, reserving raw unconstrained C++ strictly for performance-critical inner loops. - [01:18:53](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4733s) Developing games under tight, archaic hardware constraints remains an invaluable training discipline that modern high-level abstraction frameworks do not teach. - [01:25:18](https://www.youtube.com/watch?v=4zgYG-_ha28&t=5118s) The id Tech 4 (Doom 3) source code will be published as open-source once Rage ships, and Carmack challenged the wider industry to open-source seminal classic software engines.

## Detailed walkthrough ### [00:30](https://www.youtube.com/watch?v=4zgYG-_ha28&t=30s) Debuting *Rage* After Six Years of Ambitious Development

John Carmack takes the stage at QuakeCon 2011 expressing genuine relief and excitement that after years of merely discussing ideas, *Rage* is finally playable on the show floor. Having spent six years developing the title, Carmack admits to hanging around the attendee demo stations with a wide grin, watching people play. For id Software, *Rage* represented a calculated attempt to break out of its own historical archetype. Carmack reflects that the studio had become almost a stereotype of the genre it invented: run-and-gun first-person shooters defined by monsters jumping out of tight corridors.

While that classic formula built id’s legacy, the team wanted *Rage* to tackle creative and technical challenges they had never attempted before. Carmack acknowledges that with the benefit of hindsight, six years was an excruciatingly long cycle, and the studio might have questioned whether tackling so many novel systems at once was prudent. Yet, he maintains that fighting through those difficult technical battles ultimately produced a superior, remarkably polished game that achieved everything id originally envisioned.

> “In hindsight, knowing that it took six years, we would look back and say maybe we shouldn't have been quite as ambitious, maybe we should have, you know, done a few more of the things that we already had plenty of experience doing, but in the end everybody gets the benefit of, you know, we picked hard battles, we fought through all of them, and in the end I think we did a really damn good job on it.” — John Carmack

- *Rage* spent six full years in active development. - id Software explicitly sought to transcend its established "run-and-gun corridor monster shooter" reputation. - The studio provided several dozen demo stations on the QuakeCon show floor for attendees to experience the game directly.

---

[01:49](https://www.youtube.com/watch?v=4zgYG-_ha28&t=109s) Game Pacing and Moving Beyond Pure Deathmatch

At QuakeCon, attendees had access to developer menus letting them jump into any standalone level and blast away, but Carmack emphasizes that *Rage* cannot be fully understood from a brief ten-minute slice. At a recent press event where journalists were given a continuous three-hour hands-on session, players only began breaking into the real meat of the game right around the three-hour mark. That milestone is where the game world truly expands, introducing open environments, vehicles, and varied side activities. Carmack found it gratifying when press members repeatedly pleaded for extra minutes rather than relinquishing their controllers, and he jokingly encourages QuakeCon attendees to tag-team and "camp" demo stations to see the vast content packed onto the second DVD.

Carmack considers *Rage* the most enjoyable title id Software has ever produced, contrasting its dynamic pacing with traditional arena deathmatches. Though an avid supporter of competitive multiplayer, Carmack notes he was never the type of gamer who could spend eight continuous hours deathmatching. *Rage* intentionally modulates its intensity, balancing moments of sudden, abject terror in combat with quieter interludes spent exploring the wasteland, conversing with NPCs in towns, or taking on jobs. While id is not attempting to turn the game into a sprawling RPG like *The Elder Scrolls V: Skyrim*, Carmack notes they learned how to incorporate narrative and world-building layers that enrich the core action without undermining the fast, kinetic combat id fans expect.

> “It really is probably the most enjoyable id game from my perspective that we've ever made.” — John Carmack

- A recent press junket allotted three continuous hours of gameplay, which Carmack identified as the threshold where the open world truly unfolds. - The full experience spans two DVDs on console, with later trailers showcasing content largely drawn from the second disc. - Carmack clarifies that while id added dialogue and hub exploration, they are not positioning the game as a direct competitor to dedicated open-world RPGs like *Skyrim*.

---

[04:30](https://www.youtube.com/watch?v=4zgYG-_ha28&t=270s) Technical Director Postmortems and the "Moving Painting"

Reflecting on his role as technical director, Carmack cautions himself against turning his talk into a premature postmortem where he hyper-focuses on engineering flaws and future optimizations. While engineers naturally fixate on what could run smoother, Carmack is delighted that the final shipping product realized id's creative ambition. For Carmack, the greatest reward of building an engine platform is being stunned by what the artists and world designers achieve. He admits that he lacks the visual imagination of the art team, meaning that exploring the fully populated environments is often as startling and delightful for him as it is for any first-time player.

Journalists have described *Rage* as a "moving painting," a moniker Carmack finds particularly apt. Unlike conventional games that construct a handful of immaculate "hero" rooms specifically tailored for back-of-the-box screenshots, the art team covered terabytes of unique virtual geometry with handcrafted detail using id's "stamping" workflow. Players can stop almost anywhere across the wasteland, look in any direction, and find richly textured, non-repeating surfaces that reward visual inspection.

```mermaid flowchart LR accTitle: id Tech 5 Production Pipeline accDescr: Diagram illustrating how the underlying engine architecture enables artists to produce unique painted world data. subgraph Engine ["Engine Core"] A["id Tech 5 Architecture"] B["MegaTexture Engine (~10% of codebase)"] A --> B end subgraph Art ["Art & Design Pipeline"] C["Terabytes of Unique Asset Data"] D["Artist Stamping Workflow"] C --> D end subgraph Output ["User Experience"] E["'Moving Painting' Visual Aesthetic"] F["Solid 60 FPS Console Performance"] end B --> E D --> E B --> F ```

> “And from my point of view, the game has so many things in it that I certainly didn't imagine when we started off, or even early, you know, even three years ago, and that's been—that's always the most rewarding part as a technical director for me is I have an idea of what the platform that we're creating will let people do, but when the artists and the designers get in and they build some of these just magnificent things, it's in many ways as much of a shock to me as it is to everybody else playing the game.” — John Carmack

- Carmack self-identifies his engineering tendency to immediately dissect finished software into things that could be improved. - The artwork in *Rage* spans terabytes of uncompressed source data, detailed by environment artists and "stampers" across every sector of the map. - The visual style was characterized by game journalists as a "moving painting."

---

[06:44](https://www.youtube.com/watch?v=4zgYG-_ha28&t=404s) The Reality of MegaTexture: Trade-offs, 60 FPS, and Streaming Bottlenecks

Carmack turns to MegaTexture, the signature technology powering *Rage*’s unique look. He points out that while the press and public fixate on MegaTexture, the system constitutes only roughly 10% of the game’s code and about 25% of the overall engineering effort within an id Tech 5 codebase numbering millions of lines. However, those tens of thousands of lines are "dismayingly complicated." MegaTexture was the technical compromise that enabled a 60-frame-per-second target on Xbox 360 and PlayStation 3 hardware alongside an unconstrained, painterly art style, but it required substantial engineering sacrifices and came with inescapable physical trade-offs.

Carmack explains that the live demos at QuakeCon run on PC or Xbox 360 units installed directly to local hard drives, representing optimal streaming performance. The absolute worst-case scenario occurs on an Xbox 360 reading assets purely from an optical DVD drive without a hard drive cache. While the engine executes clever scheduling, linear read batching, and look-ahead tracking to fetch the correct texture mip-levels, physical optical drive seeks remain a hard bottleneck. A bad-case read can take up to 150 milliseconds for a single chunk, and because a single frame's scene can comprise up to a thousand unique texture tiles, streaming in every high-resolution detail from a cold optical state can take as long as 15 seconds. Carmack anticipates some criticism over texture pop-in, noting that players who deliberately spin around backwards at high controller sensitivity will momentarily catch the engine resolving lower-resolution, blurry mip-levels into focus.

> “The bottom line is still that you want a new piece of texture data on there and it can take, you know, 150 milliseconds in a bad case or something to go pull that in, and the screen might be made up of, you know, a thousand different little pieces, so in the worst case it can take 15 seconds for every last little bit of detail to come in, and I know we're going to get dinged some by that.” — John Carmack

- MegaTexture accounts for approximately 10% of the engine's code footprint and roughly 25% of the total engineering effort. - The entire id Tech 5 codebase spans millions of lines of code, with tens of thousands dedicated directly to the MegaTexture streaming and transcoding pipeline. - Target performance across contemporary console platforms (Xbox 360 and PS3) is a locked 60 frames per second. - Optical drive latency on an uninstalled Xbox 360 disc read can hit 150 milliseconds per fetch, requiring up to 15 seconds in pathological scenarios for a full scene of up to 1,000 sub-tiles to fully resolve from blur to maximum resolution.

[09:26](https://www.youtube.com/watch?v=4zgYG-_ha28&t=566s) The Engineering Tradeoffs of Virtual Texturing

Reflecting on his daily development workflow, John Carmack describes the constant tug-of-war between engineering perfectionism and practical gameplay. Sitting at his desk with Visual Studio open on one monitor and the game running on the other, twiddling the gamepad controller, he routinely spots flaws, wondering how to optimize scheduling, feed in texture hints, or improve visual fidelity. He notes that while an engineer can easily become depressed obsessing over how much better things could be built, seeing QA testers and colleagues genuinely enjoying the game brings immediate perspective. Delivering *RAGE* required deliberate engineering compromises: accepting a visible degree of texture streaming latency in order to render an expansive, unique, painterly world, while relinquishing completely general-purpose dynamic lighting.

Briefly interrupted by a glitch in the stage microphone, Carmack shifts focus to the underlying engine architecture. The virtual texturing pipeline represents the most intricate, tightly coupled, and highly optimized code within id Tech 5. Rather than handling individual assets as conventional discrete surfaces—such as an arbitrary wall map measuring 2,000 by 1,000 pixels or a coffee cup texture at 128 by 128—the engine slices every surface into uniform 128 by 128 texel blocks known as pages, managed through up to four distinct levels of data locality.

Carmack explains the philosophical tension every programmer faces when balancing technical constraints against artistic ambitions: > “Like any good engineer I can almost depress myself about how much more we can do to make things better in the future but then when I look at people playing the game just even in the office running around doing the the testing duties or whatever you know I'm back to okay that looks great I'm really thrilled to see it running that good see it behaving that way and it's you know it's always a set of tradeoffs in engineering where we you know we made these conscious decisions that we would live with some degree of textures coming in to give us this this painterly world we would give up on completely general purpose dynamic lighting.”

[11:13](https://www.youtube.com/watch?v=4zgYG-_ha28&t=673s) The Evolution from Splash Damage to Modular Art Design

The foundations of id Tech 5’s virtual texturing originated five years prior, when Carmack first implemented the concept for Splash Damage on *Enemy Territory: Quake Wars* before generalizing it for the early production of *RAGE*. Initial math suggested that the current hardware generation could easily manage the load. By setting up a physical texture cache of 4,096 by 4,096 pixels on the GPU, the engine could store approximately one thousand 128 by 128 pages. Because a typical screen displays roughly one million pixels, a sixteen-million-pixel texture pool offered a generous 16x margin, which proved completely stable in early demonstrations like the confined Dusty 8 racetrack demo.

```mermaid flowchart TD accTitle: Megatexture Content Design Approaches accDescr: Comparison of contiguous terrain meshes versus modular geometry and their impact on GPU page cache efficiency.

subgraph Ideal["Ideal Architecture: Contiguous Sheets"] A["Continuous Mesh / Facade"] --> B["Single Texture Island"] B --> C["Dense 128x128 Page Packing"] C --> D["Fits easily in 4096 x 4096 Cache"] end

subgraph Modular["Production Reality: Modular Kit"] E["Lego-style Prefabs & Props"] --> F["Thousands of Disconnected Fragments"] F --> G["Underfilled Pages & False Sharing"] G --> H["4096 x 4096 Exhaustion / Trashing"] end ```

The technology hit a major hurdle when the art team changed its production pipeline. Rather than constructing expansive, continuous terrain meshes or deformed architectural facades—termed "texture islands," which map efficiently into contiguous pages—artists transitioned to assembling scenes out of thousands of modular, Lego-style structural prefabs. When the design team approached Carmack asking for concrete polygon budgets and texture limits, Carmack gave a permissive answer that his colleagues Tim Willits and Matt Hooper continued to tease him about: > “I hemmed and hawed and I really made a really bad call and I said well you know I want to be pushed a little bit so go you know go make really cool stuff and we'll figure it out and I you know and and in the end we we pretty much did but there is a whole lot of hard work buried in making all of that stuff actually work.”

- Early virtual texturing ran with high efficiency because large, smooth meshes map into continuous texture space with minimal overhead. - Modular construction introduced thousands of disconnected sub-textures, complicating page packing and inflating the total number of required cache pages. - Providing fixed engineering guidelines to designers proved difficult due to fluid tradeoffs between triangle count, overdraw, particle effects, and dynamic lights.

[14:19](https://www.youtube.com/watch?v=4zgYG-_ha28&t=859s) Console Bottlenecks and Cache Architecture Fracturing

The structural shift from continuous landscapes to modular set pieces revealed a severe limitation of the 128 by 128 page format. In scenes featuring intricate geometry—such as an iron railing that spans only a single pixel on the screen—the virtual texturing engine must still allocate an entire 128 by 128 page to texture that sliver. Packing disparate elements together introduces false sharing and degrades anisotropic filtering quality. Consequently, the original 4K by 4K page cache became inadequate. On the PC, developers could easily expand the pool to 8K by 8K textures, as PC graphics cards possessed ample VRAM. Console platforms, however, could not afford such a brute-force approach without sacrificing mip levels and cutting visual fidelity in half.

To bring console performance up to par with the PC build, id Software faced sharp hardware asymmetries between the Xbox 360 and PlayStation 3:

Because the PS3 could not allocate an 8K by 8K texture buffer, Carmack evaluated alternatives such as packing pages across the six faces of a 2K by 2K cube map (which imposed complex shader address calculations) or using sliced 3D volume textures (which caused severe performance degradation). Ultimately, the team had to abandon their once-unified, elegant design in favor of an intricate arrangement consisting of three independent physical page caches of varying dimensions and depth complexities, separate DXT-compressed streams, and dedicated pipelines for dynamic virtual materials (VMs).

Carmack laments the closed nature of modern console platforms compared to the open PC environment: > “It pains me a lot that the that Microsoft and Sony completely disallow the ability to plug in a keyboard and you know and tweak with things it's it's even a pain for us in development that our full retail builds we can't bring down and play with debug tools and I think that's that's unfortunate into to not any particularly good benefit.”

[18:25](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1105s) The Necessity of Multi-Level Caching Over Raw Streaming

While the earliest virtual texturing prototype took only a few days to get functional, and a fully navigating level running without upfront load times was achieved in a matter of months, refining the system into a shippable commercial product took years of iteration. The core challenge lies in data bandwidth: if the engine attempted to stream individual 128 by 128 pages directly from a DVD-ROM or an optical drive, panning the camera would trigger severe streaming stalls, requiring massive batches of texture pages to be pulled synchronously from disk every time the player turned their view.

Carmack stresses the gap between a promising prototype and an engineered solution ready for retail hardware: > “So all of this complexity comes in when you go from kind of the initial cool elegant demo of something to getting it through delivering what your artists and designers want and getting it out onto a shipping project.”

- Direct reads from high-latency media like optical drives or standard hard disk drives cannot keep pace with 60 Hz rotational movement without a multi-tiered locality caching architecture. - On PC systems equipped with large quantities of system RAM, virtual texturing disguises streaming delays once assets have been viewed once and stored locally in memory.

[19:20](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1160s) Console Memory Constraints and Streaming the Wasteland

Managing memory on consoles proved far more grueling than on the PC. While the PC could lean on standard operating system buffer caches, console development required id Software to build and manage every tier of memory manually. The team implemented an internal second-layer cache designed to devour virtually all leftover console memory, serving as a rapid staging area for both texture streaming and audio data. In interior instance maps, assets fit comfortably in memory; once an asset was seen, it stayed resident and could be retrieved near-instantaneously through the transcode pipeline. However, Rage’s sprawling outdoor Wasteland environment pushed console hardware to its absolute limit, leaving far less stream file cache than Carmack wanted.

The architectural differences between the consoles created unique headaches. The PlayStation 3 proved notably tighter on memory than the Xbox 360 due to its split memory architecture, which divided its memory pool down the middle into dedicated CPU and graphics segments rather than providing a unified pool. While id nearly saturated the high-memory limits anyway—making the split itself manageable—the memory footprint of the PS3’s operating system consumed valuable megabytes that Carmack longed to reclaim for the stream file cache.

Relying directly on physical media introduced devastating latency, turning software execution into a mechanical waiting game. Blu-ray discs suffered from especially brutal seek latencies compared to standard DVDs or hard drives. As Carmack observed:

> “It’s the epitome of the physical action going on in here where so much of this is just ethereal software shoving things around, but you listen to that Blu-ray turning around as it seeks around pulling everything in like it'll be nice when we don't have that little physical element that we have to be scheduling for and working around.”

- Interior instance maps had sufficient memory headroom to keep textures resident, whereas the outdoor Wasteland severely strained console limits. - The Xbox 360 provided unified memory, while the PS3 enforced a strict split between CPU and GPU memory spaces alongside a heavier operating system memory footprint. - Optical drive mechanical seek times on DVD and Blu-ray represented the primary latency bottleneck when loading un-cached streaming assets.

---

[21:26](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1286s) Multi-Tiered Caching and Storage Realities

To prevent catastrophic stalls from optical disc seeks, id engineered an intermediate hard drive backing cache. When a player looked at a surface for the first time, texture data took the long mechanical trip from the DVD or Blu-ray and was immediately written to a high-speed scratch area on the local hard drive. On subsequent viewings, the engine pulled the asset directly from the hard drive rather than re-seeking the optical disc. This design established a strict four-level hierarchy of data locality: the physical optical media, the hard drive backing cache, the in-memory stream file cache, and finally the GPU-bound textures displayed on screen.

```mermaid flowchart TD accTitle: Rage Texture Streaming Hierarchy accDescr: The four-stage streaming pipeline moving data from physical optical media down to the GPU texture on screen.

subgraph Storage["Physical Storage"] Optical["Optical Media (DVD / Blu-ray)"] HDDCache["Hard Drive Backing Cache (Local Scratch Area)"] end

subgraph MemoryPipeline["Memory & Processing"] StreamCache["In-Memory Stream File Cache"] Transcode["Asynchronous Transcoder (HD Photo to DXT)"] GPUTexture["GPU Resident Texture / Framebuffer"] end

Platform installation policies added further friction. On the PS3, id could install select critical data directly to the hard drive, prompting ongoing negotiations between Bethesda and Sony to secure a few additional gigabytes for extra page files to smooth out the player experience. Conversely, the Xbox 360 offered no option for partial installs, requiring an all-or-nothing installation of roughly 21 to 22 gigabytes. Carmack strongly recommended the full Xbox 360 install for anyone with sufficient drive space, noting that eliminating optical seeks made an immense visual difference.

Looking back, Carmack reflected on architectural alternatives that could have mitigated streaming pop-in entirely had development time permitted:

> “The better solution for that would have been to split our page files and say okay all of the low detail stuff goes onto the hard drive cache and then all the high detail stuff stays on the Blu-ray possibly backed by the temporary hard drive cache because then you would never have the you know the grotesquely ugly cases where you just like oh you know what is that blurry mess for a quarter second that you can get when it's coming straight from optical media.”

- The multi-tiered caching pipeline reduced latency across four discrete layers: optical media, local hard drive backing cache, in-memory stream file cache, and resident GPU textures. - Xbox 360 installations required a mandatory 21–22 GB all-or-nothing footprint, while the PS3 supported partial hard drive installs. - Bethesda actively lobbied Sony during late production to grant additional hard drive allocation for Rage's streaming page files.

---

[23:26](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1406s) The Asynchronous Transcode Pipeline and Image Compression

The streaming infrastructure represented the most intricate and fragile code inside id Tech 5, juggling multiple dedicated asynchronous worker threads. One thread managed reads from the optical drive, another handled reads from the hard drive, background threads analyzed the GPU feedback buffer to determine texture page visibility, and a pool of worker threads executed real-time transcoding. Carmack noted that if storage capacity were infinite, id would have stored texture pages uncompressed so they could be streamed via unbuffered direct I/O straight into GPU memory. However, uncompressed assets would have either halved the game's world size or bloated the physical release into an absurd eight-DVD package.

To compress the massive Megatexture dataset onto standard distribution media, id adopted a derivative of Microsoft's HD Photo format. id had originally built an internal Discrete Cosine Transform (DCT) compressor, but Microsoft's technology delivered a 30% quality improvement at equivalent bitrates. This visual gain carried a steep performance penalty: decoding the HD Photo derivative demanded twice the processing horsepower. The runtime pipeline ingested these compressed streams, dispatched them across worker threads to decode into a intermediate YCoCg color space, and then re-encoded them on the fly into native DXT texture formats for the graphics card.

Reflecting on the engineering tension behind the streaming system, Carmack remarked:

> “Again it’s the most sophisticated code in there and to some degree we cringe a little bit every time we try to implement some new feature in there because it is it's at the heart of the most asynchronous threads you know all the different devices.”

- Worker threads were strictly segregated: dedicated threads for optical I/O, hard drive I/O, feedback buffer analysis, and parallel transcoding. - Storing uncompressed native textures would have required an unwieldy eight DVDs instead of the shipped multi-disc configuration. - Microsoft licensed an HD Photo derivative to id Software, providing over 30% better visual compression quality than id's custom DCT algorithm at the expense of doubling the CPU decode cost. - Textures decompressed into an intermediate YCoCg color space before being dynamically re-encoded into hardware DXT format.

---

[25:17](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1517s) PC Driver Bottlenecks and the Promise of Unified Integrated Graphics

Because Rage released on PC through Steam, the development team was able to continue tuning and optimizing the PC build past the hard manufacturing deadlines required for console disc authoring. Yet despite high-end PC hardware packing ten times the brute-force processing power of the aging consoles, Carmack found it an infuriating struggle to maintain a consistent 60 frames per second on the PC. The primary culprit was PC graphics driver overhead surrounding dynamic texture updates.

On consoles, updating a Megatexture page was trivial: the engine wrote the raw pixel memory directly into the page table by calculating an exact memory offset and executing a simple integer write. On the PC, that identical operation was routed through standard OpenGL or DirectX driver abstractions, turning into calls like `glTexSubImage2D`. Stepping through driver dispatch layers in a debugger revealed an immense amount of CPU overhead, tiling conversions, and swizzling variations across different GPU vendors. Carmack warned that if a programmer attempted to single-step through that driver code, “you'll cry you won't make it back out it'll just take forever.”

This frustration led Carmack to evaluate Intel’s integrated graphics architecture with fresh optimism. While traditionally dismissed by hardcore gamers as low-power hardware meant strictly for office applications, Intel's contemporary integrated GPUs had matured enough to run Rage internally, even if not yet at a steady 60 frames per second. Carmack argued that Intel's unified memory architecture offered an enormous structural advantage over discrete cards because it mirrored the console paradigm. If driver developers allowed direct access to texture addresses, strides, and swizzle formats, developers could bypass heavyweight driver validation loops entirely and poke updates straight into unified RAM.

Carmack challenged the historical culture of hardware abstraction that had long dominated the PC graphics market, summarizing his perspective on driver friction and hardware evolution:

> “And it is extremely frustrating knowing that the hardware that we've got on the PC is often 10 times as powerful as the consoles but it's honestly been a struggle in many cases to get the game running 60 frames per second on the PC like it does on a 360.”

- Modern PC hardware possessed roughly ten times the raw compute power of consoles, but driver overhead severely hampered 60 FPS consistency. - Console page updates bypassed driver validation by directly poking integer values and memory buffers into known physical addresses. - PC graphics APIs required calls like `glTexSubImage2D`, incurring massive software driver overhead due to vendor-specific swizzling and tiling formats. - Intel integrated graphics chips had improved enough to run Rage, presenting a compelling unified-memory architecture that Carmack hoped would eventually expose raw memory pointers directly to developers.

[28:52](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1732s) Leaky Abstractions and Archaeological Hacks in PC Drivers

John Carmack highlights the ongoing tension between clean API abstractions and the harsh realities of high-performance rendering. In DirectX, for example, the API creates the illusion that an application can simply lock a rectangular subregion of an image. Behind the scenes, however, graphics drivers frequently copy the entire texture back and forth, unswizzling and re-swizzling memory layout to satisfy the abstraction before writing it back to video memory. While high-level abstraction simplifies general software development, Carmack emphasizes that it can cripple aggressive real-time engines. Developers might read a hardware reference manual and identify a straightforward DMA transfer or memory poke that runs cleanly on consoles, only to find that doing the equivalent on a PC requires navigating deeply convoluted driver pathways.

Carmack candidly accepts personal responsibility for some of the architectural baggage still lingering in modern PC drivers. He recounts an oversight from early versions of *Quake*, where he allocated a fixed 1,000-character buffer for OpenGL extension strings, assuming that would be more than enough. As hardware capabilities expanded and extension strings grew to tens of thousands of characters, running unpatched *Quake* executables resulted in memory stomps. Driver vendors ended up hardcoding game-detection hacks specifically to intercept *Quake* and return a truncated extension list that wouldn't overrun the buffer. Carmack notes that these "archaeological reasons" explain why PC drivers are laden with special-case workarounds, forcing PC hardware to rely on brute-force power to match the low-level efficiency of consoles.

> “For a lot of things abstraction is great you want to be able to step back and say here we're doing one thing we wanted to behave just with slightly varying characteristics but when you're doing really aggressive realtime operations sometimes those abstractions will really kill you.” — John Carmack

- Drivers hide memory layout conversions like swizzling and full-texture copies when applications attempt to lock sub-rectangles. - Direct hardware operations like DMA fetches documented in hardware reference manuals are frequently obscured by PC driver complexity. - Modern drivers still contain application-detection hacks for early *Quake* builds to prevent buffer overflows from oversized `glGetString(GL_EXTENSIONS)` calls. - The brute-force performance of PC hardware often acts as a costly crutch to overcome the efficiency advantages of console-level hardware access.

---

[31:12](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1872s) Vendor Cooperation, Dynamic Resolution Scaling, and Adaptive V-Sync

Reflecting on vendor relations, Carmack notes that the hardware ecosystem is vastly healthier than it was during the *Quake III Arena* era, when around twenty different graphics companies produced chips, many of whom lacked the engineering competence to write proper drivers. Today, working with just three primary vendors—NVIDIA, AMD, and Intel—allows for high-level, productive collaboration. This cooperation was vital for solving frame pacing on *Rage*. On consoles, id Software targets a strict 60 frames per second locked to the display's swap interval, utilizing dynamic resolution scaling to downsample the rendering buffer reactively as scene complexity or particle overdraw increases. While Carmack hopes future engines can preemptively scale down before costly events like explosions occur, the current reactive system occasionally misses the 16.6-millisecond window when sudden off-screen elements appear.

```mermaid flowchart TD accTitle: Frame Timing and Adaptive V-Sync Flow accDescr: Rendering logic deciding between locked 60 FPS, resolution scaling, and tearing.

subgraph RenderLoop["Frame Execution"] A["Render Frame"] --> B{"Meets 16.6ms Target?"} end

subgraph FrameOutcome["Swap Interval Behavior"] B -- "Yes" --> C["Clean Swap at 60 FPS (No Tearing)"] B -- "Approaching Limit" --> D["Dynamically Scale Down Resolution"] D --> A B -- "No (Missed Target)" --> E{"Adaptive Tear Support?"} E -- "Traditional V-Sync" --> F["Bobble Down to 30 FPS (Noticeable Stutter)"] E -- "Negative Swap Interval" --> G["Immediate Swap with Tear Line (Maintains Input Response)"] G --> H["Resolution Scales Down; Tear Line Migrates Off-Screen"] end ```

When a frame is dropped, PC players traditionally face two bad choices: enabling standard V-Sync, which drops frame rates from 60 directly to 30 FPS and causes jarring stutter, or disabling V-Sync entirely and enduring continuous screen tearing. id Software pioneered a hybrid approach on consoles where frames stay locked at 60 FPS until a frame deadline is missed, allowing an immediate tear line for a couple of frames before dynamic resolution scaling recovers and pushes the tear line off the screen. Carmack successfully lobbied NVIDIA, AMD, and Intel to implement this behavior on PC via an extension using negative swap interval values (such as `-1`).

> “We are obsessing over some relatively unimportant things with sizes of filter kernels and the other things that graphics geeks can go on about forever, but we've got this stupid ugly tear line going down the screen or we've got this non-isochronous swap behavior; this is actually an important thing to fix.” — John Carmack

- The GPU industry has consolidated from roughly 20 chip makers during the *Quake III* era down to three major players: NVIDIA, AMD, and Intel. - *Rage* uses reactive dynamic resolution scaling to maintain 60 FPS during heavy particle overdraw and complex geometry. - The standard binary choice between severe 30/60 FPS judder and constant horizontal tearing is mitigated by adaptive tear-on-miss handling. - NVIDIA implemented negative swap intervals (e.g., `-1`) to signal "lock if possible, tear if late," an approach subsequently adopted by AMD and Intel.

---

[34:47](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2087s) Tuning PC Texture Caches and Experimental Engine Builds

Turning to the PC release of *Rage*, Carmack clarifies that while there are no radical PC-exclusive rendering features, the engine will take advantage of desktop hardware headroom. On consoles, the virtual texture cache is constrained to a 4K by 4K physical allocation, but high-end PC video cards with multiple gigabytes of VRAM can expand this cache to 16K by 16K. A cache of that size allows players to navigate substantial portions of the world without the engine ever needing to transcode additional texture pages from disk.

Beyond the initial retail build, Carmack expresses enthusiasm for releasing experimental, research-oriented executable updates that leverage *Rage*'s asset database. He likens this to the release of *GLQuake*, which was initially an unsupported drop-in executable that showcased id's hardware acceleration research using the original retail data files. Although id Software's larger corporate scale makes releasing unsupported test code more complicated, he remains eager to explore how existing production assets hold up under novel rendering techniques.

> “I'm also looking forward to the possibility of doing some almost research engine like things that may be able to leverage some of the Rage data, kind of back to the old days where GLQuake came out where it was this completely unsupported thing that you just dropped this EXE in and ran this and it kind of showed you what I was playing with technology wise.” — John Carmack

- High-end PC GPUs can expand the Megatexture physical cache from 4K x 4K (console baseline) up to 16K x 16K. - Larger physical caches dramatically reduce runtime texture transcoding overhead during movement across the wasteland. - Carmack is interested in releasing experimental *GLQuake*-style executables that repurpose *Rage* assets to demo bleeding-edge rendering pipelines.

---

[36:35](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2195s) Development Timelines, Content Pipelines, and Diminishing Returns

Carmack evaluates futuristic rendering paradigms like ray tracing, point splatting, and voxel representations, but clarifies that such concepts are far removed from current production reality. The primary bottleneck is not purely algorithmic; it is the immense cost and time required to establish a functioning content authoring pipeline. Virtual texturing was first demonstrated publicly more than five years earlier, yet turning that demo into an end-to-end production workflow—encompassing artist tools, backend crunching, data streaming, and disc distribution—consumed half a decade of intensive labor.

Because creating content pipelines is so grueling, id Software cannot afford to reinvent its toolchain with every project. Carmack points out an unsustainable trajectory in the studio's history: every successive mainline game developed internally at id Software has taken longer to complete than its predecessor. Projecting that trend forward would eventually lead to absurd multi-decade production cycles. Carmack warns that exponential trends must eventually break, and developers must carefully manage a "smooth flared landing" rather than crash. Furthermore, he reiterates his belief that real-time graphics have passed the "knee of the curve," where each incremental leap in visual fidelity yields smaller perceptible improvements despite requiring massive technological investments.

> “The cold hard truth is every game that we've done that's come out of id Software proper on our mainstream mainline has taken longer than the game before, and that cannot continue.” — John Carmack

> “If something can't go on forever it won't, and it's all a matter of how you do the landing from can't go on forever that determines how you're going to come out of it.” — John Carmack

> “I've said for years now that I think that we are past the knee of the curve in terms of what we get from graphics technology on there.” — John Carmack

- Far-future rendering approaches under research include ray tracing, voxel rendering, and surfel/splatting techniques. - Turning the initial virtual texturing demo into a shipping production pipeline required over five years of development. - Mainline id Software release cycles have grown strictly monotonically with each game, demanding an intentional slowdown of pipeline churn to avert runaway development times. - Real-time rendering has surpassed the knee of the return curve, meaning massive increases in engine complexity now yield diminishing visual payoffs.

[38:16](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2296s) Committing to 60 FPS and New Research Engines

Carmack reflects on the core engineering philosophy behind *Rage*, emphasizing that choosing a smooth 60 frames per second over a 30 FPS target was a contentious, deliberate trade-off. While 30 FPS would have allowed for far more visual spectacle, the team ultimately decided that responsiveness was worth the pain. As Carmack puts it: “that initial choice to say we can do fancier graphics, you know there are techniques that we can apply that will make the game look better, but I'd rather have twice the frame rate and I think that we are—that question of how we spend our resources, there's a lot of options on there on what we want to do with it.”

At the time of the address, the main game was essentially wrapped up, though team members remained at the office pulling all-nighters to finalize candidate builds for submission. Most remaining bugs centered on edge cases, such as handling a multiplayer invite during a physical disc swap while yanking out a console memory card. Having stepped away from the final shipping polish, Carmack had already spun up independent research engines. He expresses interest in testing the outer bounds of their existing assets—running "speed of light" calculations to see how perfect anti-aliasing and true motion blur would look using high-end PC hardware, which offers roughly ten times the raw compute power of current consoles.

- The team chose 60 FPS over 30 FPS early on, accepting severe constraints across art, design, and programming to hit the performance budget. - Final release candidates were being prepared back at the office, resolving bizarre console compliance edge cases around disc swapping and memory card removals. - High-end PCs are running *Rage* essentially as a "muscular console" without bolt-on DirectX 11 features like tessellation, which Carmack believes must be architected from day one rather than tacked on.

---

[41:25](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2485s) A Factor of a Billion: From the Atari 2600 to 192 GB RAM Builds

Looking back across computing history, Carmack notes that while he used to marvel at a factor of a million improvement since his early development days, modern workloads now span nine orders of magnitude—a factor of a billion. He describes browsing disassembled ROMs and architectural notes of the Atari 2600, a machine from his childhood operating on a mere 128 bytes of RAM and 2 KB of cartridge ROM (later expanded to 16 KB through bank switching).

To contrast this extreme scarcity, he highlights an internal production challenge at id Software: generating the massive virtual textures for *Rage*. Rebuilding all the dynamic textures initially took hours. Carmack rewrote the toolchain around huge memory-mapped files, but standard dev workstations quickly ground to a halt swapping to disk. In response, they dropped $5,000 to equip a build server with 192 gigabytes of RAM. Carmack points out that 128 bytes on the Atari 2600 compared to 192 GB in a single server represents an increase greater than one billion times, a scale unmatched in almost any other human endeavor.

```mermaid flowchart TD accTitle: Memory Scaling Over Time accDescr: Diagram contrasting Atari 2600 memory limits with id Software's Rage virtual texture build server.

subgraph Atari["Late 1970s: Atari 2600"] A1["RAM: 128 Bytes"] A2["ROM: 2 KB (Up to 16 KB via Bank Switching)"] end

subgraph Server["2011: id Software Build Rig"] B1["RAM: 192 Gigabytes"] B2["Storage: 2 Terabyte Consumer HDDs"] end

Atari -->|"Scale increase of > 1,000,000,000x (9 orders of magnitude)"| Server ```

- High-end consumer graphics cards possess at least 10 times the compute horsepower of the Xbox 360 and PlayStation 3. - Atari 2600 specs: 128 bytes of system RAM, 2 KB starting ROM, maxing out at 16 KB with costly bank-switching hardware. - *Rage* virtual texture build server: upgraded to 192 GB of RAM for around $5,000 to keep memory-mapped files entirely in physical RAM and eliminate disk thrashing. - While serial CPU clock speeds have plateaued, multi-core parallelism and GPU throughput continue to compound computational growth by multiple orders of magnitude.

---

[44:21](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2661s) Spending Massive GPU Horsepower and the Texture Detail Debate

Considering what game developers should do with surplus computing power, Carmack delineates between simple brute-force scaling and complex algorithmic tasks. Straightforward upgrades include jumping from 720p to 2560-wide PC resolutions, driving triple-monitor setups (a 10x pixel increase), pushing multi-sample fragment anti-aliasing to 16x, and widening dynamic range. Beyond those standard knobs, he ponders extreme image-processing pipelines: “there are things that are beginning to look possible on this level of hardware where I'm looking at this thinking, you know I guess we can do a full Fast Fourier Transform on the entire damn screen and do full-screen convolutions of things where instead of having our flares be these sprites and blurred things that we have on there, we can convolve the whole damn screen with this giant starburst and have every little pixel come in right.”

Carmack frankly acknowledges a common visual criticism *Rage* will face: because the game relies on unique virtual textures without secondary tiling detail maps, inspecting surfaces point-blank causes the art to appear soft or blurry. He wishes id had possessed the schedule headroom to build an uncompressed, dual-layer Blu-ray master specifically for the PlayStation 3 to max out image fidelity, though he admits the PS3's slow drive seeks and tighter available memory made that risky. Looking ahead, he suggests releasing an experimental PC DLC pack containing a single level mastered at ten times the standard bitrate (roughly 2 GB instead of 300–500 MB) to evaluate whether users notice the bump in fidelity during active gameplay.

- Brute-force hardware utilization includes 2.5K high-resolution displays, multi-monitor arrays, and 8x/16x MSAA. - FFT-driven full-screen convolutions could theoretically replace standard billboard lens flares with physically accurate diffraction starbursts, despite the enormous floating-point cost. - Without detail maps layered over the mega-textures, surfaces in *Rage* lose crispness up close compared to games relying on repeated tiling shaders. - The team considered shipping dual-layer Blu-ray discs on PS3 with looser compression, but the combination of PS3 memory limits, slow optical read speeds, and a strict production schedule prevented platform-specific assets.

[48:11](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2891s) Megatexture Data Pipeline, Compression, and View-Dependent Profiling

Carmack discusses the immense scale of the source art behind id Software’s Megatexture technology and the aggressive compression strategies required to fit *Rage* onto physical media. While the shipping game fits onto a single 20-odd-gigabyte Blu-ray disc (or three Xbox 360 DVDs), the uncompressed source assets are vastly larger. id ran into hard limits where the source art exceeded a single 256,000-by-256,000 texture atlas. Across mountains, ground stamps, and surfaces, the raw source assets represent roughly 64 gigapixels. With three image channels per texture using 12 bytes, plus mipmaps, the master source art exceeds a full terabyte of data before being baked with lighting into final level sets. Levels like the Wasteland could not fit into even a single 256k-by-256k sheet; instead, it had to be split across approximately 14 separate textures ranging from 32k to 128k, with character models fitting on 64k-by-64k sheets.

```mermaid flowchart TD accTitle: Megatexture Data Pipeline accDescr: Flow diagram showing how 1TB+ of source art is baked, profiled, compressed, and packed onto shipping game discs.

subgraph Source["Source Assets (1TB+)"] A["Raw Art: Mountains, Terrain, Stamps (64 Gpixels, 12 bytes/sample)"] B["Static & Dynamic Lighting Data"] end

subgraph Baking["Baking & Optimization"] C["Level Partitioning (Wasteland: 14 pieces, 32k–128k)"] D["Player Movement Profiling (Zillions of simulated views)"] E["View-Distance Filtering (Full res near, reduced far)"] end

subgraph Distribution["Shipped Media (~20+ GB)"] F["HD Photo / JPEG XR Compression"] G["1x Blu-ray (PS3) / 3x DVDs (360) / PC"] end

A & B --> C C --> D D --> E E --> F F --> G ```

Shipping all baked world textures uncompressed in standard RGB format would have required hundreds of gigabytes. To make the footprint manageable, id utilized HD Photo compression (JPEG XR) combined with view-dependent resolution profiling. By mapping out every valid player navigation path, id's toolset profiled millions of vantage points to calculate the exact resolution required for any given vantage point, aggressively pruning detail from surfaces the player could never reach. Carmack notes that while this strategy saved massive disk footprints, it introduced compromises: baseline profiling targeted 720p console resolutions. Consequently, high-resolution PC players who bring down the console and fly up with `noclip` will notice blurry textures on distant guard towers and unreachable rooftops because the high-resolution texture data was intentionally stripped during authoring.

- Source art assets ran past a single 256,000 × 256,000 boundary (64 gigapixels); with mipmaps, source art totals roughly 1 terabyte. - The Wasteland map alone is split into 14 distinct texture pages scaling from 32k up to 128k. - Profiling simulates millions of potential player views, aggressively degrading surfaces that cannot be closely approached by the player. - “Unfortunately the texture data just doesn't exist to have the higher quality data there so it winds up being a little bit blurrier,” Carmack remarks, acknowledging that artists were visibly downcast when first seeing their crisp PC assets crushed down by production compression.

---

[52:20](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3140s) Lighting Battles and the Friction with Post-Processing

Carmack reflects on an enduring aesthetic struggle at id Software: lighting, game darkness, and the clash between raw texture clarity and post-processing filters. For years, Carmack had waged an internal crusade against games being too dark. While developers often argue players should simply sit in a dark room with the lights off, Doom 3 suffered from vast amounts of visual detail being completely obscured in shadow. On *Rage*, id made a deliberate effort to brighten levels, but this introduced new disagreements over post-processing pipelines.

While artists and cinematic designers favored heavy post-processing color grading and tone mapping to sell atmosphere, Carmack often preferred the unfiltered rendering path. He frequently dropped the console in development builds to disable post-processing entirely, finding the clean, raw pixel detail far sharper and truer to the original art. Nonetheless, he conceded that post-effects won out for atmospheric reasons, despite destructively altering the precisely compressed megatexture pixels id's engine programmers worked so hard to preserve.

> “I lost that battle pretty clearly where there's lots of post effects going on throughout the game and lots of times it does convey the right mood and it does all of this, but it does a lot of damage to all of this data that we spent—we killed ourselves to get it compressed over there, and then to have some post-process go in and muck up all the pixels is sometimes a little bit depressing.” — John Carmack

---

[54:09](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3249s) Static Software Analysis and Scaling the Engineering Team

Transitioning from asset authoring to software engineering practices, Carmack details his recent, eye-opening experiences using automated static code analysis tools on *Rage*. As id Software grew from a tiny team—where Carmack and a single right-hand programmer wrote essentially the entire codebase—to a department where the internal `id-programmers` email alias reached 49 people, managing a multi-million-line codebase required radically different standards. Carmack highlights how programming language disputes often resemble "religious wars," where developers insist that error-prone constructs are safe in the hands of skilled engineers, but automated checkers reveal systemic pitfalls across large teams regardless of individual talent.

During early evaluations, the commercial static-analysis vendor Coverity scanned the *Rage* codebase and reported roughly 100 potential issues as a sales pitch. Although Coverity praised id's codebase as exceptionally clean compared to the industry average, they requested around $50,000 for their suite. id initially deferred purchasing, but Carmack later explored alternate compilers and tools, discovering that Microsoft Research had integrated advanced `/analyze` static analysis checks directly into their compiler. While standard Visual Studio reserved these tools for high-end enterprise tiers, Microsoft included them out of the box in the Xbox 360 development kit—a pragmatic choice, Carmack observes, because platform holders bear immediate public blame for crashing console games in a way they do not for unstable PC desktop software.

- The internal id programmer distribution alias expanded to 49 recipients across two large production teams and two smaller project units. - The *Rage* engine codebase encompasses multiple millions of lines of code. - Coverity identified approximately 100 issues on its initial evaluation pass and asked roughly $50,000 for the tool suite. - Microsoft bundled advanced static analysis (`/analyze`) into the standard Xbox 360 SDK while restricting it to top-tier enterprise Visual Studio packages on desktop Windows. - “I guess you can draw the conclusion that Microsoft figures they're not going to get blamed for buggy PC apps, but they will shoulder some blame for buggy 360 apps so they're going to make these tools that make significant differences,” Carmack observes regarding Microsoft's developer tooling priorities.

[58:01](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3481s) Static Code Analysis and the Statistical Nature of Software

Carmack strongly urges developers to embrace static analysis tools, especially Microsoft's `/analyze`, which is provided free for Xbox 360 developers: “I'll say this quite clearly with no hesitation: any 360 developers that are listening to this, if you're not using /analyze, you are making a mistake.” id Software had previously addressed around 100 issues surfaced by Coverity, but after adding many new programmers and expanding the codebase, turning on Microsoft’s analysis tool flagged hundreds of additional items. While some findings drew defensive pushback from programmers insisting their logic secretly guaranteed safety, many uncovered genuine bugs—such as code checking a pointer for null in one branch but forgetting to check it lower down. Seeing hundreds of these confirmed issues fundamentally reshaped Carmack's view of software reliability.

Traditional engineering relies on reliability theory, assessing material spreads, yield strengths, tensile tolerances, and failure estimates. Software, by contrast, is often viewed as strictly deterministic—assuming no uninitialized variables or randomized memory, it either functions or fails given a specific input. However, Carmack points out that across millions of lines of code written by dozens of developers, software failure exhibits a distressingly statistical distribution. Even if execution is deterministic, the human development process is heavily statistical, as every engineer inevitably injects errors.

```mermaid flowchart TD accTitle: Statistical Realities of Software Scaling accDescr: Transition from small deterministic programs to large-scale multi-developer codebases requiring static analysis.

subgraph SmallScale["Small-Scale Projects"] A["Individual Developer / Small Team"] --> B["Deterministic Mental Model"] B --> C["Ad-hoc Bug Bashing"] end

subgraph LargeScale["Scaled Production"] D["Millions of Lines of Code"] --> E["Statistical Inevitability of Bugs"] F["Dozens of Programmers"] --> E E --> G["Static Analysis Enforcement (/analyze, PVS-Studio)"] G --> H["Zero Warnings as Errors Policy"] end

C -.->|"Codebase Grows"| D ```

[01:00:43](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3643s) Developer Habits, Copy-Paste Errors, and Team Practices

Before diving deep into static analysis, Carmack conducted a personal experiment by logging his own coding errors—ignoring minor initial compile errors and recording only bugs that slipped past first execution and surfaced days, weeks, or months later. The data exposed definite behavioral patterns. A frequent culprit was handling coordinate sets ($x, y, z$ or $x, y, z, w$): the ubiquitous shortcut of copying a line, pasting it repeatedly, and manually swapping axes. In a six-month stretch, this practice introduced three persistent errors into his own code, such as corrupting an image's alpha channel because a $z$ was not properly updated to a $w$, causing the blue channel to be read instead. While one occurrence can be dismissed as an anomaly, repeated instances represent systemic trends that demand better techniques like loops, templates, or objects to eliminate copy-paste habits altogether.

These vulnerabilities scale dangerously as codebases age. Carmack warns his team that code written today will likely still be running somewhere a decade from now, just as fragments of original Quake code still survive in modern game titles. Maintenance compounds this risk. A programmer writing game logic might assume certain invariants (like an active target not being another player), but a subsequent developer adding new features later in the function may lack full context, triggering edge-case crashes when conflicting actions align—such as changing weapons while simultaneously falling to one's death and being crushed by a tracking vehicle.

- Carmack tracked his personal post-compilation logic errors over a six-month period to uncover flawed programming habits. - Repetitive axis copy-pasting ($x, y, z, w$) caused multiple silent regressions, including undetected alpha-channel image corruption. - Invariants checked at the top of long routines frequently get bypassed or invalidated by subsequent feature additions written lower down. - Even obsolete engines leave footprints: fragments of Quake code from 1996 remain embedded in games released 15 years later.

[01:02:43](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3763s) Zero-Tolerance Warnings and the Tool Pipeline: From /analyze to PC-lint

To protect large codebases over time, id Software adopted a strict zero-tolerance build policy: Microsoft `/analyze` is permanently enabled, treating all warnings as fatal build errors. Carmack argues that even when a tool issues a false positive on code that is technically sound, the warning should be heeded rather than suppressed: “If the analyzer can't figure it out, other programmers probably won't immediately figure it out and it will cause problems.” While dynamic scripting and loose typing have their place for quick prototyping where getting things running fast matters, long-lived production systems require rigid safety. To prevent games from taking eight years to develop, teams must adopt better programming language practices and rigorous automated tooling alongside solid design and content pipelines.

Beyond Microsoft's tools, Carmack expanded his analysis pipeline to include PVS-Studio and PC-lint. He had evaluated PC-lint version 7 around the development of Quake III Arena when id had only three programmers working in pure C, but at the time it did not trigger a lasting conversion to the practice. Returning to it on their modern C++ codebase, id achieved a state that was completely clean of warnings under both Microsoft `/analyze` and PVS-Studio. However, PC-lint represented a much tougher challenge due to its very high noise-to-signal ratio and pedantic rule set.

- Microsoft `/analyze` and PVS-Studio runs were enforced as continuous, zero-warning gates on the build systems. - Warnings that require convoluted mental proofs to explain indicate overly complex logic that should be refactored for clarity. - PC-lint (dating back to original Unix lint) was initially tested by Carmack during Quake III Arena's development, but its value only became indispensable with larger teams and C++ architectures. - While `/analyze` and PVS-Studio offered actionable signals, PC-lint introduced a significantly higher noise-to-signal ratio across the engine.

[01:06:54](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4014s) Code Quality, Scripting Pitfalls, and Static Analysis

Reflecting on the final stages of shipping *Rage*, John Carmack admits his disappointment at being unable to triage every single warning flagged by static analysis. Thousands of warnings remained in the codebase. While many stemmed from patterns where variables were guaranteed to be initialized elsewhere, Carmack recognizes that dismissing them as harmless is an exercise in hand-waving: buried inside those thousand warnings are genuine defects waiting to trigger. This experience reinforced a core lesson id Software took away from *Doom 3*: embedded script interpreters are fundamentally detrimental to game development in terms of debugging, code stability, and raw performance. Carmack challenges the popular industry dogma that game development requires a dynamically typed, free-form scripting language so that non-programmers can build game logic.

Carmack argues bluntly that allowing non-programmers to write scripting logic produces codebases that inevitably break down at scale. Even with modern hardware that is a million times faster than past machines, execution overhead remains a critical concern. During the final month of *Rage*’s production, id Software was forced to rewrite parts of their Flash-based user interface in native C++ because ActionScript evaluation inside the GUI was consuming multiple milliseconds per frame. Because processing cycles remain a scarce budget, Carmack prioritizes strict, static compile-time guarantees over dynamic flexibility. His ultimate ambition is to construct analysis pipelines rigorous enough to formally guarantee that a game cannot crash with an unhandled exception during execution.

“You know, one of the big lessons of a big project is you don't want people that aren't really programmers programming; you'll suffer for it,” Carmack notes, stressing the long-term maintenance disaster of treating game scripting lightly.

- Static analysis left thousands of unaddressed warnings in *Rage* due to schedule pressure, masking potential real-world failure cases behind benign false positives. - Dynamic scripting languages fail both on performance and software engineering grounds; even UI Flash/ActionScript scripting consumed multiple milliseconds per frame until rewritten in C++. - *Rage* phased out the majority of legacy *Doom 3* scripting, relying directly on native in-engine code for heavy lifting.

[01:09:16](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4156s) SuperScript in Doom 4, Functional Concepts, and C++ Subsetting

Looking forward to *Doom 4*, Carmack describes id Software's alternative to third-party scripting environments: an internal system termed "SuperScript." SuperScript is a constrained dialect implemented directly within C++. It combines fiber-based execution—granting gameplay scripters the convenience of cooperative yields, sleeps, and cleanly scheduled events—with native execution speed and strict static type checking. Carmack intends to push this philosophy even further by enforcing a rigorously constrained subset of C++ across the studio's entire development pipeline. This drive originates from a statistical realization about software teams: mistakes are authored daily by even the most gifted engineers, and raw developer skill cannot replace structural compile-time safety nets.

While Carmack expresses strong personal admiration for pure functional programming languages like Haskell and OCaml, he admits they are not practical for primary game development. Across a team of roughly 50 engineers, retraining staff, resolving unfamiliar performance regressions, and managing industry hiring pipelines would present insurmountable hurdles. Instead, he advocates restricting 95% of the codebase to an ultra-safe, Java-like subset of C++ that statically bans unchecked arrays, uninitialized pointers, and use-after-free conditions. Only tiny, hyper-optimized performance loops would retain access to raw, unconstrained C++ semantics. Carmack acknowledges that internal code policies mean nothing unless tools physically forbid bad idioms, as anti-patterns inevitably slip past human review over multi-year production cycles.

“The very best programmers always make mistakes, and this is something that I've really internalized: that no matter how good you think you are, you are making mistakes all the time, and you have to have structures around you to try and help you limit the damage that your mistakes will cause,” Carmack emphasizes.

```mermaid flowchart TD accTitle: Subsetting C++ Codebase Architecture accDescr: Segregation of a game engine into a large constrained safe C++ subset and a tiny hyper-optimized native core.

subgraph CoreEngine["Engine Architecture"] direction TB subgraph SafeDialect["95% of Codebase: Safe C++ / SuperScript"] A["Fiber-based Task Scheduling"] B["Java-like Safety Invariants"] C["Checked Arrays & Safe Pointers"] D["Static Lifetime & Null Analysis"] end

subgraph PerfDialect["5% of Codebase: Hyper-Tuned Engine Core"] E["Unrestricted C++ & SIMD Intrinsics"] F["Twitchy, Cache-Tuned Inner Loops"] end end

SafeDialect -->|"Calls via strict interfaces"| PerfDialect ```

[01:12:37](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4357s) Development Cadence, Studio Growth, and the "Old Man Carmack" Era

Surveying the broader development cycle of *Rage*, Carmack reflects on the cost of targeting extreme technical ambition. Programming remained the critical path throughout production. While pushing rendering boundaries was exciting, Carmack observes that had id Software scaled back their technological goals slightly, they could have shipped two full titles in the six-year span between *Doom 3* and *Rage*. In hindsight, he wishes the studio had built an intermediate title on id Tech 4—such as an earlier *Doom 4* release cycle every three years—rather than enduring a multi-year commercial hiatus. While external partner studios like Raven Software delivered *Quake 4* and *Wolfenstein* during that gap, id Software now insists on producing its flagship releases entirely under its own roof.

This shift in internal scope has transformed id Software into a company of over 200 employees, absorbing large-scale internal quality assurance, localization, and multiplatform delivery pipelines that previously belonged to publishing partners. Carmack notes the milestones that converged around this period: id Software’s 20th anniversary, the 15th anniversary of *Quake*, and his own 40th birthday. Acknowledging a recent graphics article that poked fun at him as "Old Man Carmack," he accepts his evolution along the archetype spectrum from young prodigy to industry elder statesman. Yet he firmly rejects nostalgia for the small-team eras of the 1990s, maintaining that he is far more effective as an engineer today than he ever was in the past. To satisfy his appetite for compact, low-overhead software engineering, Carmack carves out dedicated time every year to work hands-on with mobile projects.

“I'm really a remarkably unsentimental person; I don't spend a lot of time thinking about the good old days, because I see this a lot: the good old days are right now,” Carmack explains, affirming his satisfaction with *Rage* and his personal output.

- id Software expanded past 200 employees, bringing multiplatform certification, QA, and localization pipelines completely in-house compared to the single-platform disc delivery of *Doom 3*. - Carmack regrets the six-year gap between major internal releases, noting that leveraging id Tech 4 for an immediate follow-up game would have stabilized production cadence. - Annual mobile development projects serve as an essential creative and technical outlet, allowing Carmack to build complete projects with small-team immediacy under ZeniMax.

[01:16:15](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4575s) Mobile Development, Software Rasterizers, and the Generational Shift

Carmack reflects on managing his time between primary engine development and mobile side projects. While his nominal plan was to limit mobile experiments to roughly 10% of his schedule, he broke that budget significantly during the production of the *Rage* iOS app. Historically, his involvement in mobile was confined to a retro detour where he would reconstruct techniques from scratch—such as building a software rasterizer or writing for DirectX 7–class GPUs—before handing the engine over the wall for the mobile team to turn into a complete game. However, because the iOS app would be the public's very first glimpse of *Rage*, id Software decided that Carmack would personally stay with the title through release. This resulted in several months away from id Tech 5, leaving him completely detached from Xcode or mobile development ever since.

Looking back at retro programming proved deeply satisfying for Carmack. Given four days, he was able to sit down and write a complete software rasterizing engine, realizing that years of accumulated wisdom allowed him to craft far cleaner, more effective solutions than he did in the early 1990s. This contrast between old and new paradigms resurfaced during id's recent office move. Browsing bookshelves of legacy manuals, Carmack spotted a Commodore VIC-20 reference guide he had carried around since age twelve. A younger developer remarked that modern programmers might never match the intimate machine-level connection possessed by Carmack and Robert Duffy, who knew every hardware register intimately. Carmack countered that today's engineers accomplish extraordinary things by orchestrating web frameworks and complex data pipelines across modern infrastructure. Even if contemporary systems involve twenty layers of abstraction between the programmer and the silicon, he embraces the progress and refuses to play the role of an aging cynic complaining about the youth: “I'm not yet a grumpy old man about kids these days not knowing how to program their assembly language and and all this.”

[01:18:53](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4733s) The Enduring Value of Extreme Resource Constraints

Despite his enthusiasm for modern high-level tools, Carmack maintains that learning to operate within tight resource boundaries is an irreplaceable discipline. Modern game production still demands intense optimization to fit within console footprints, even though contemporary hardware outstrips historical supercomputers. Carmack points out the absurd reality that a modern mobile phone is vastly more capable than a Cray supercomputer, yet the industry runs mundane tasks across bloated abstraction layers simply because it remains the most practical path forward.

For a brief period, early cell phones revived strict limitations, forcing id to compress titles like *Doom RPG* into a 128 KB footprint while optimizing Java bytecode. Yet within the single development cycle of *Rage*, handheld platforms skyrocketed from primitive feature phones to gigahertz multi-core processors with gigabytes of RAM, rendering extreme 128 KB micro-optimizations largely obsolete. Carmack laments the loss of that discipline and expresses admiration for demoscene hackers competing in 64 KB demo competitions. To recapture that problem-solving ethos, he envisions establishing an arbitrary, retro target platform:

```mermaid flowchart TD accTitle: Retro Platform Pedagogical Workflow accDescr: A concept where developers target 32-bit legacy consoles to rediscover low-level system engineering.

subgraph HardwareTarget ["Standardized Archaic Platform"] A["Legacy 32-bit Console (PS1 / Nintendo 64)"] B["No Quirky Hardware Strict Resource Ceilings"] A --- B end

subgraph DevelopmentTasks ["Exploratory Engineering"] C["Revisit Core Software (Browsers, Mail Clients)"] D["Team Game Jams (Atari 2600 Sprint)"] end

subgraph EducationalOutcome ["Pedagogical Goal"] E["SCA for Programmers: Historic Systems Mastery"] end

HardwareTarget --> DevelopmentTasks DevelopmentTasks --> EducationalOutcome ```

Carmack imagines developers adopting widely produced 32-bit consoles like the original Sony PlayStation or Nintendo 64—systems powerful enough to run real programs without bizarre architecture traps, yet small enough to force radical creativity when building modern software such as web browsers or mail clients. He jokes that this initiative would function as a creative anachronism society for engineers: “I'm thinking this would be kind of like the Society for Creative Anachronism for programmers—instead of bashing each other with foam swords, you're playing on archaic hardware.” While he acknowledges his packed schedule will likely prevent him from ever organizing it, he loves the idea of giving his programming staff an open schedule window to write an Atari 2600 game purely as an educational exercise.

- The *Doom RPG* mobile era required fitting an entire role-playing title into a 128 KB application footprint. - Mobile computing transitioned from basic feature phones to multi-gigahertz pocket machines carrying gigabytes of RAM within the span of *Rage*'s development cycle. - The 64 KB demoscene remains an inspiration for extracting maximum artistic and technical expression from severe artificial limits.

[01:22:08](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4928s) Internal Onboarding, Tool Complexity, and the Vanishing Mod Community

Carmack addresses growing pains in studio culture and developer onboarding. Historically, id Software relied on a ruthless sink-or-swim approach: new hires were assigned a desk, shown the source code repository, and expected to become self-sufficient immediately. While self-driven engineers thrived by building isolated test cases and discovering the architecture independently, Carmack concedes that this pipeline is inefficient for an expanding company. This onboarding friction is especially punishing in content creation. Artists arriving with extensive experience in the Unreal Engine discover that their workflows do not translate to id's internal toolset, where there are neither polished SDKs nor commercial books to guide them.

This friction mirrors a distressing industry-wide shift away from grassroots game modding. Although id plans to ship the world editor alongside *Rage*, Carmack is realistic about its limited community utility: players can easily tweak entity layers and rearrange monster placements, but constructing an entirely original MegaTexture from scratch requires immense computing power, time, and specialized technical knowledge. The loss of an active mod scene deprives id of its traditional talent pipeline, leaving Carmack mourning the era when independent hobbyists mastered id's toolchains before ever stepping foot in the studio: “It does sadden me that that that we don't have that anymore, and that means we don't have the pool of people to to draw on.”

[01:23:53](https://www.youtube.com/watch?v=4zgYG-_ha28&t=5033s) Announcing the Open-Source Release of id Tech 4 (Doom 3)

The discussion of open codebases leads Carmack into a major announcement: ZeniMax Media has granted official approval to release the complete source code for *Doom 3* (id Tech 4) before the end of the year. The announcement draws enthusiastic applause from the QuakeCon audience. Carmack praises ZeniMax's progressive posture, noting that id had previously tested the waters by releasing open-source code for *Doom Classic* on iOS and *Wolfenstein: Enemy Territory*.

Freeing the id Tech 4 codebase required overcoming internal hurdles, primarily because commercial titles derived from the engine remained active in the marketplace. Both *Prey 2* (heavily modified) and Splash Damage's *Brink* relied on architectures descended from id Tech 4. Because of these commercial dependencies and the studio's laser focus on shipping *Rage*, Carmack clarifies that no engineer will be pulled off bug fixes, testing, or triage to prepare the code drop until *Rage* is finished and out on store shelves: “Obviously, we're not going to put any effort into this until *Rage* is out the door on the street; programmers are not going to be pulled off of even testing or triage or anything to to do this, but the okay has been given and it will be happening.” The legal team still needs to review the repository, dot every i, and cross every t, but Carmack highlights how supportive the corporate culture has been—sharing an anecdote from the previous ZeniMax Christmas party, where an in-house attorney approached him directly to express how personally meaningful she felt id's open-source heritage was for the wider community.

[01:25:18](https://www.youtube.com/watch?v=4zgYG-_ha28&t=5118s) Open Source Legacy and the Call to the Industry

Reflecting on the impending release of the *Doom 3* source code, John Carmack shares his pleasant surprise at how enthusiastically the legal department embraced the idea. Having anticipated corporate hesitation, he admits to doing a double take when corporate counsel and executives reacted positively. As Carmack explains, “ZeniMax has been really, really supportive of this and, you know, I almost put this out as a challenge to some of the other software companies.” He points out that numerous industry peers sit on seminal, classic codebases that could easily be published for the wider public. Releasing such software provides enormous educational value for aspiring young programmers, benefits the broader enthusiast community, and cements a company's historical legacy.

Carmack acknowledges that internally, open-sourcing code was not always universally accepted without friction. During the early days of id Software, team members debated whether freely distributing their engines gave away valuable competitive advantages or inadvertently assisted market rivals. In hindsight, however, Carmack views that debate as completely settled, noting: “There's no doubt at this point that the legacy of of the open source software has been a really good thing for id and I'm really happy that we're able to kind of continue that going forward.”

He wraps up his address by pointing out how digital distribution platforms have dramatically simplified experimenting with open-source game engines. In earlier eras, interested developers who did not already own an original boxed copy had to dig through clearance bins or search retail shelves for vintage media to obtain required game assets. With platforms like Steam offering sales, players and programmers can immediately grab the necessary *Doom 3* game data online, pair it with the newly freed source code, and start hacking away. With that final encouragement, Carmack closes out his keynote to enthusiastic applause.

- **Corporate Backing:** ZeniMax’s legal and executive teams fully backed Carmack’s plan to release the *Doom 3* source code. - **Industry Challenge:** Carmack challenges other legacy game studios to release the source code of their seminal classic titles to educate upcoming software engineers. - **Digital Convenience:** Digital distribution on Steam eliminates the historical friction of hunting down old retail discs just to acquire engine assets.

## Notable quotes > [01:06:54](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4014s) You know, one of the big lessons of a big project is you don't want people that aren't really programmers programming; you'll suffer for it. — John Carmack

> [36:35](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2195s) The cold hard truth is every game that we've done that's come out of id Software proper on our mainstream mainline has taken longer than the game before, and that cannot continue. — John Carmack

> [01:02:43](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3763s) If the analyzer can't figure it out, other programmers probably won't immediately figure it out and it will cause problems. — John Carmack

> [58:01](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3481s) I'll say this quite clearly with no hesitation: any 360 developers that are listening to this, if you're not using /analyze, you are making a mistake. — John Carmack

> [36:35](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2195s) I've said for years now that I think that we are past the knee of the curve in terms of what we get from graphics technology on there. — John Carmack

> [01:12:37](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4357s) I'm really a remarkably unsentimental person; I don't spend a lot of time thinking about the good old days, because I see this a lot: the good old days are right now. — John Carmack

> [31:12](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1872s) For a lot of things abstraction is great you want to be able to step back and say here we're doing one thing we wanted to behave just with slightly varying characteristics but when you're doing really aggressive realtime operations sometimes those abstractions will really kill you. — John Carmack

> [01:25:18](https://www.youtube.com/watch?v=4zgYG-_ha28&t=5118s) There's no doubt at this point that the legacy of of the open source software has been a really good thing for id and I'm really happy that we're able to kind of continue that going forward. — John Carmack

## Mentioned John Carmack, Rage, id Software, QuakeCon, QuakeCon 2011, The Elder Scrolls V: Skyrim, id Tech 5, MegaTexture, Xbox 360, PlayStation 3, Microsoft Visual Studio, Splash Damage, Enemy Territory: Quake Wars, Dusty 8, Tim Willits, Matt Hooper, Sony, Microsoft, Bethesda, HD Photo, Steam, OpenGL, DirectX, DirectX 11, Intel, NVIDIA, AMD, Quake, Quake III Arena, GLQuake, Doom 3, Microsoft Research, Coverity, Atari 2600, PC-lint, PVS-Studio, JPEG XR, Robert Duffy, ZeniMax Media, Raven Software, Doom 4, Doom Classic, Doom RPG, Quake 4, Wolfenstein, Wolfenstein: Enemy Territory, Brink, Prey 2, id Tech 4, SuperScript, Haskell, OCaml, C++, Java, Flash, ActionScript, Commodore VIC-20, Sony PlayStation, Nintendo 64, Cray, Xcode, iOS, Unreal Engine, Society for Creative Anachronism

## Video description As tradition goes, id's co-founder and technical director, John Carmack, kicks things off with his keynote address.

[Source](https://www.youtube.com/watch?v=4zgYG-_ha28)

中文简报

QuakeCon 2011：约翰·卡马克主题演讲卡马克对《狂怒》（Rage）及 id Tech 5 引擎历时六年的开发过程进行了详尽的技术复盘，详细阐述了虚拟纹理的架构妥协、主机端 60 帧的性能目标以及多级存储缓存设计。他深入探讨了软件工程规范，主张采用静态代码分析、更安全的 C++ 子集，并在《毁灭战士 4》（Doom 4）中以 SuperScript 取代嵌入式脚本语言。在反思工作室成长与行业变迁时，他强调了严苛硬件限制具有持久的教育价值，随后宣布即将开源完整的 id Tech 4（《毁灭战士 3》）代码库。《狂怒》研发历时六年，需要通过多线程管线配合复杂的四级缓存与即时转码，才能在主机上以稳定的 60 帧流式传输不重复的巨幅纹理（MegaTexture）资产。 (0:30) 卡马克强烈主张将微软的 /analyze 等静态分析工具集成到日常构建管线中，并推行零容忍的致命警告策略，他援引了数百万行代码库在统计学上的错误发生率来证明其必要性。 (58:01) 为了减少运行时脚本错误，id Software 为《毁灭战士 4》开发了 SuperScript——一种基于纤程的原生 C++ 方言，相比动态脚本语言，它在编译期推行严格的类型安全检查。 (69:16) ZeniMax Media 已正式批准在《狂怒》商业发售后开源完整的 id Tech 4（《毁灭战士 3》）源代码，延续了 id 长期以来的开源传统。 (83:53)

Reading summary

At QuakeCon 2011, id Software technical director John Carmack reviewed the technical compromises and production lessons from the six-year development of Rage, arguing that delivering modern interactive fidelity requires disciplined multi-tiered caching, strict compile-time software engineering, and a deliberate flattening of ever-expanding development timelines. MegaTexture Trade-Offs and Multi-Tiered Streaming (6:44) To transcend traditional corridor-shooter environments and deliver a 'moving painting' aesthetic at a locked 60 frames per second, id Software developed the id Tech 5 MegaTexture virtual texturing pipeline. Rather than recycling modular repeating surfaces, the system handles terabytes of unique, uncompressed source assets sliced into uniform 128-by-128 texel pages. However, Carmack highlighted that virtual texturing comprised only about 10% of the codebase while demanding 25% of the overall engineering effort, introducing severe data streaming bottlenecks and visible texture pop-in during fast rotational camera movements. Because optical drives suffer from latency bottlenecks—with worst-case disc seeks reaching 150 milliseconds—id engineered a strict four-level locality cache: physical discs (DVD or Blu-ray), a local hard drive backing scratch area, an in-memory stream cache, and resident GPU buffers. To squeeze massive world data onto retail media without halting execution, the engine utilized an asynchronous worker thread pool that decoded a Microsoft HD Photo derivative into YCoCg space and transcoded it into GPU-native DXT formats in real time, accepting doubled computational decoding costs for a 30% bandwidth reduction. PC Driver Overheads and Architectural Inefficiencies (25:17) Despite PC hardware providing approximately ten times the compute power of contemporary consoles, maintaining a stable 60 frames per second on the PC proved exceptionally difficult. Carmack attributed this to driver-level CPU overhead during dynamic texture updates. While consoles allowed direct integer memory writes into virtual page tables, standard PC graphic APIs required dispatching through abstracted driver routines like glTexSubImage2D, which triggered excessive tiling conversions, memory swizzling, and hidden texture copies behind the scenes. Carmack noted that modern PC drivers remain burdened with 'archaeological hacks,' citing an early Quake bug where he allocated a fixed 1,000-character OpenGL extension string buffer, forcing subsequent GPU vendors to hardcode special-case string truncations to avoid application memory stomps. Due to these driver layers degrading low-level hardware control, Carmack expressed optimism toward unified memory models in integrated GPUs, such as Intel's graphics architectures, which inherently avoid discrete PCIe transfer overheads. Static Code Analysis and Engineering Discipline (54:09) As id Software scaled from small development pods to an internal programming staff of 49 engineers managing millions of lines of code, Carmack revised his perspective on software reliability. While software execution is theoretically deterministic, he argued that multi-developer production behaves statistically, with human errors distributing predictably across sprawling codebases. Tracking his own defects revealed recurrent structural slip-ups, such as coordinate axis copy-paste bugs that escaped initial compilation. In response, id instituted a zero-tolerance policy for compiler warnings, leveraging Microsoft's /analyze and PVS-Studio as mandatory automated build gates. Carmack also rejected dynamically typed game scripting engines, citing performance and stability issues that forced the team to rewrite parts of Rage's Flash ActionScript UI in native C++ late in production. For Doom 4, id pursued 'SuperScript,' an internal fiber-based system implemented as a constrained, memory-safe subset of C++ designed to provide compile-time safety guarantees without the performance regressions of third-party virtual machines. Production Cadence, Diminishing Returns, and Open Source (36:35) Carmack cautioned that id Software’s trend of every successive mainline game taking longer to complete—peaking at six years for Rage—is economically unsustainable. He warned that real-time graphics have passed the 'knee of the curve,' where exponential increases in development time and hardware resources yield diminishing visible returns to the player. Shifting asset pipelines to massive unique textures also had unintended side effects, drastically raising the technical barrier to entry and eroding the studio's traditional community modding pipeline. Balancing these industry changes, Carmack announced that parent company ZeniMax Media approved the full open-source release of the Doom 3 (id Tech 4) engine codebase before the end of the year, scheduled to ship as soon as Rage completed retail release. Carmack defended the commercial legacy of open-sourcing id's historic engines, urging the broader game industry to archive and release classic codebases to serve educational and public software preservation needs. Carmack concluded that long-term studio viability relies on curbing unchecked development timelines, constraining codebases through automated analysis and safe programming subsets, and accepting performance trade-offs to protect frame rate, while continuing to preserve engineering knowledge through open-source software releases.

精炼阅读摘要

John Carmack在QuakeCon 2011演讲中反思了《Rage》长达六年的研发历程，阐释了团队为在主机端实现锁定60 FPS与独特“动态油画”美学所付出的严苛工程代价。他指出图形技术的跨越已越过边际效应拐点，大型研发团队必须告别过度膨胀的技术野心与低效动态脚本，全面转向以自动化静态分析、语言安全子集与多级缓存体系为核心的现代工程方法论。《Rage》设计定位与60帧性能取舍 (0:30) Carmack回顾，《Rage》历经整整六年开发，旨在打破id Software由狭窄走廊和怪物突袭构成的传统射击游戏刻板印象。游戏大幅重构了节奏体验，在约三小时线性流程后才逐渐展开包含荒野、载具驾驶及NPC交互的开放世界。在立项初期，团队便坚决确立了60帧（每帧16.6毫秒预算）的目标。Carmack承认，若妥协至30帧，美术本可呈现更丰富的视觉特效，但团队权衡后认定操作响应与流畅度具有决定性价值，为此在程序架构与美术管线上承担了严酷的性能约束。虚拟纹理架构与多级存储缓存机制 (6:44) 驱动《Rage》非重复手绘世界的核心技术是MegaTexture（虚拟纹理），该系统占id Tech 5约10%代码及25%工程量，内部耦合度极高。系统将地表切分为统一的128×128纹素页面，但当美术团队由连续地形网格转向模块化预制件拼装时，细碎几何体导致页面利用率骤降并引发GPU缓存频繁抖动。受限于架构瓶颈——PS3显卡缺乏原生8K分配支持且内存被CPU与GPU对半分隔，Xbox 360亦显存紧绷，主机基准物理缓存被迫锁定在4K×4K。为缓解光盘读取高达150毫秒寻道延迟造成的严重卡顿，id构建了包含实体光盘、硬盘回写缓存、内存流式缓存与显存表面的四级缓存层级。多线程架构协同光驱与硬盘异步I/O，并将派生自微软HD Photo格式的数据转码为YCoCg色彩空间，最终实时压入DXT格式供显卡渲染。Carmack坦承，从光驱冷启动完全加载高精度细节最长可达15秒，玩家高速转动视角时难免会短暂目睹低精度纹理逐渐清晰的过程。 PC驱动瓶颈与图形算力边际效应 (25:17) Carmack指出，尽管高端PC拥有十倍于老旧主机的原始计算力，但在维持纯粹60帧时却极其艰难，主要瓶颈在于PC图形驱动在动态贴图更新（如glTexSubImage2D）上的巨大抽象开销、平铺转换以及厂商驱动层的历史包袱。驱动层甚至留存了专门针对早期《Quake》固定字符缓冲区的规避补丁。这使Carmack对英特尔核芯显卡的统一内存架构抱有期待，因其结构上更接近主机无驱动冗余的底层内存直写模式。面对渲染负载波动，引擎在主机端结合动态分辨率缩放与自适应垂直同步（Adaptive V-Sync），在复杂场景下即时降采样以守住16.6毫秒窗口。Carmack强调，实时图形已跨过收益曲线的拐点，光线追踪与体素等设想受制于高昂的内容创作流水线成本而难以快速普及；内部主流作品研发周期代代递增的趋势不可持续，工业界必须学会平稳着陆。静态代码分析与软件工程统计学 (54:09) 随着id Software工程团队由早期的两三人扩张至49人规模，数百万行代码的管理要求范式转移。Carmack提出，在庞大团队与漫长周期中，软件故障呈现出统计学分布——即便代码逻辑在理论上确定，但人类工程师的编写过程本质上是概率性出错的。通过记录自己半年内逃脱编译检查的缺陷，他发现大量Bug源于三维坐标复制粘贴为四维向量时未将z改为w等常见不良习惯。为此，id在工程构建中对微软/analyze与PVS-Studio推行“零警告容忍”政策，将所有警告视作致命编译错误阻断构建。Carmack批驳了游戏界推崇嵌入式动态脚本语言以便非程序员参与逻辑的偏见，指出《Rage》在发售前一个月不得不将消耗数毫秒的Flash UI关键逻辑由ActionScript紧急重写为原生C++。针对《Doom 4》，id规划了名为“SuperScript”的纤程C++微方言，主张未来将95%的代码限制在类似Java的安全C++子集中，彻底通过工具链消除空指针、越界与悬空指针。开发门槛、MOD断代与开源倡议 (82:08) 团队扩张与工具复杂化带来了文化阵痛。虽然《Rage》附带关卡编辑器，但因MegaTexture的烘焙涉及数以太字节的超大纹理生成与海量算力，普通爱好者已无法在个人电脑上独立创作全新地貌。MOD门槛的剧增切断了id直接从社区吸纳成熟人才的传统路径，新员工上手内部专有工具链的难度也大幅增加。演讲尾声，Carmack宣布ZeniMax已正式批准在《Rage》发售后开源《Doom 3》（id Tech 4）的全部源代码。他赞赏了母公司法务团队的开放态度，并向全行业发出呼吁，倡导商业游戏公司公开发布具备历史价值的老旧引擎代码，为下一代程序员提供学习样本，让技术遗产反哺整个软件生态。 Carmack的演讲全面总结了《Rage》背后的工程取舍与反思。他断言，随着计算算力跨越数个数量级以及画质感知收益的持续收窄，依靠个人英雄主义编写底层黑魔法或无节制扩张技术野心的时代已经终结；游戏工业若要摆脱开发周期持续膨胀的泥潭，核心命题必须转向严格的静态分析检查、安全的语言子集约束，以及稳健可持续的内容生产管线。

Detailed notes — zh

## Background 该视频由 YouTube 官方频道 QuakeCon 于 2011 年 8 月 5 日发布。根据页面简介，这是 QuakeCon 的传统开场环节，由 id Software 联合创始人兼技术总监 John Carmack 带来主题演讲，分享团队技术动态与行业思考。 ## TL;DR 在长达近一个半小时的演讲中，John Carmack 深度剖析了历时六年打造的新作《狂怒》（RAGE）及其背后的 id Tech 5 核心引擎技术。他坦诚分享了在主机与 PC 上推行 MegaTexture（巨型纹理）架构所面对的 60 FPS 权衡、驱动层开销、物理介质寻道瓶颈与多级缓存挑战，并反思了开发周期过长与研发管线失控的问题。此外，他还详细阐述了团队规模化后引入静态代码分析（如微软 /analyze 与 PC-lint）提升代码可靠性的经验，探讨了从雅达利 2600 到现代硬件的算力跃迁与教育价值，并正式宣布将在年内开源《毁灭战士 3》（Doom 3）的完整源代码。 ## Atmosphere & style 整场演讲呈现出一种极致硬核、坦荡真诚且不加修饰的“工程师布道”质感。Carmack 抛弃了浮夸的商业宣讲套路，以超高密度的信息流和极快的语速，在底层代码、内存架构与工程反思之间行云流水般穿梭。面对技术妥协与研发失误，他毫不掩饰自我剖析的勇气；而当谈及算力跃迁、底层极客精神与开源传统时，言语间又洋溢着纯粹的技术热情与自豪感，让听众仿佛置身于一场顶级计算机图形学与软件架构大师的现场复盘会。 ## Bulletin - [00:02](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2s) id Software 耗时整整六年研发的《狂怒》（RAGE）正式亮相，团队通过 MegaTexture（巨型纹理）技术在当代主机上实现了全手绘风格与稳定 60 FPS 的兼顾，但代价是接受局部纹理流送迟滞并放弃了完全通用的动态光照。 - [25:17](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1517s) PC 平台的图形驱动抽象层与多层格式重排带来了严重的 CPU 开销，Carmack 呼吁借鉴主机底层的直通访问机制，并看好集成显卡统一内存架构在绕过黑盒驱动上的潜力。 - [34:51](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2091s) Carmack 警告团队与行业不能再陷入“每款游戏开发周期都翻倍”的泥潭，宣布《毁灭战士 3》（Doom 3）源代码将于 2011 年内正式开源，并呼吁更多老牌游戏厂商开放经典代码资产。 - [58:01](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3481s) 面对规模化团队的代码质量失控风险，id Software 确立了严苛的静态分析准则，推行“将警告视为错误”，并在新项目中探索严格受限的 C++ 语法子集以杜绝隐蔽缺陷。 ## Key takeaways - [00:02](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2s) 《狂怒》打破了 id Software 过去经典的幽闭走廊与跑轰射击刻板印象，在保留手核射击手感的同时引入开阔世界、载具与城镇探索等丰富层次。 - [04:31](https://www.youtube.com/watch?v=4zgYG-_ha28&t=271s) MegaTexture 技术的直接代码仅占引擎整体的约 10%，却消耗了团队约 25% 的研发精力，成功将数 TB 级的未压缩手绘资产呈现在游戏中。 - [06:17](https://www.youtube.com/watch?v=4zgYG-_ha28&t=377s) 在物理介质读取瓶颈下，DVD 光盘极端寻道时间可达 150 毫秒，光盘直接读取时最坏可能需要 15 秒才能完全锐化加载全部场景细节。 - [12:15](https://www.youtube.com/watch?v=4zgYG-_ha28&t=735s) 引擎早期基于连续网格和 4K 物理缓存设计，但美术团队转向模块化“乐高式”拼装后引发严重的缓存碎片化与虚假共享问题，迫使底层架构复杂化并拆分为多张贴图流送。 - [19:20](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1160s) 为了平滑光盘与硬盘的机械寻道延迟，引擎构建了四级局部性缓存架构，并利用微软授权的 HD Photo 衍生高压缩比算法在工作线程中实时转码至 GPU 格式。 - [28:52](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1732s) PC 图形驱动因维护高级抽象而执行频繁的像素重排与数据拷贝，加上历史上为了兼容老旧《Quake》缓冲区溢出而植入的特例补丁，构成了严重的性能黑盒包袱。 - [31:08](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1868s) 针对垂直同步的两难困境，Carmack 游说 NVIDIA 与 AMD 引入“负数帧交换间隔”，实现了 60 帧时严格同步、掉帧时允许即时撕裂并动态降分辨率补偿的自适应方案。 - [34:51](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2091s) id Software 主线作品开发时间呈现不可持续的指数级膨胀趋势，从技术原型到工业化管线耗时过长，团队必须主动平稳减速以实现研发软着陆。 - [41:15](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2475s) 计算机算力在 Carmack 职业生涯跨度内实现了逾十亿倍（9 个数量级）的跃迁，单核频率见顶后算力增量完全来自多核心并行与 GPU 通用计算。 - [58:01](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3481s) 软件可靠性在团队规模扩大和代码达数百万行后呈现统计学失效特征，纯粹依靠个人谨慎无法杜绝复制粘贴漏改等典型惯性缺陷。 - [01:02:43](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3763s) id Software 在构建系统中推行警告即错误的严苛规则，并全面引入微软 `/analyze` 与 PVS-Studio，要求代码如果无法被工具理解就必须直接重写。 - [01:06:54](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4014s) 《Doom 3》以来的教训证明动态脚本解释器弊大于利，Carmack 主张在 C++ 中限定安全的语法子集，通过编译器与工具链在编译期杜绝空指针和越界访问。 - [01:22:08](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4928s) 随着现代引擎与资产管线复杂度暴增，传统游戏 MOD 社区逐渐式微，游戏工业失去了过去赖以选拔核心研发人才的天然储备池。 - [01:23:53](https://www.youtube.com/watch?v=4zgYG-_ha28&t=5033s) 在母公司 ZeniMax 法务部门的全力支持下，《毁灭战士 3》源码在排除在研项目冲突后于年内正式开源，历史证明开源策略显著树立了技术声誉而非削弱商业壁垒。 ## Detailed walkthrough ### [00:02](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2s) 六年磨一剑：《狂怒》（RAGE）突破 id Software 传统范式在现场观众热烈的掌声与欢呼声中，id Software 联合创始人兼技术总监 John Carmack 登台发表演讲。他感慨地表示，过去这么多年，大家总是在这里听他谈论团队正在做什么、在思考什么，而今年大家终于能够直接走到展区，亲手试玩团队耗时整整六年打造的全新力作——《狂怒》（RAGE）。Carmack 提到，他这两天大部分时间都泡在试玩区，脸上挂着大大的笑容，看着玩家们沉浸其中。长期以来，id Software 仿佛成了某种特定游戏类型的刻板代名词：第一人称射击、跑轰（run-and-gun）、幽闭的走廊以及冷不防蹦出来的怪物。虽然这个类型正是由 id 开创并引领了很长时间，但外界常常认为 id 只能做这样的游戏。因此在构思《狂怒》时，团队立下了极具野心的目标，试图挑战大量过去从未涉足的新领域。Carmack 坦言，回过头看，既然这部作品花了整整六年时间，团队难免会反思是否当初不该如此野心勃勃，或许做一些更有经验的事情会走得更顺；但他坚信，直面硬仗并坚持攻克难关最终让所有人受益，最终呈现出的品质令人极其自豪。 - **开发周期**：整整 6 年潜心研发。 - **类型跨越**：打破 id 经典的“走廊突突突与跳杀怪物”模式，融入更为开阔的世界与丰富玩法。 - John Carmack 谈到研发雄心与反思时说道：“In hindsight knowing that it took six years we would look back and say maybe we shouldn't have been quite as ambitious maybe we should have you know done a few more of the things that we already had plenty of experience doing but in the end everybody gets the benefit of you know we picked hard battles we fought through all of them and in the end I think we did a really damn good job on it where the things that we set out to do.” --- ### [01:51](https://www.youtube.com/watch?v=4zgYG-_ha28&t=111s) 展台试玩与游戏节奏：从快节奏射击到开阔世界的渐进体验现场面对数千名热情玩家，却只有几十个试玩机台，这让 Carmack 既希望所有人都能摸一摸手柄、体验一下高帧率与丝滑操作的快感，又担心走马观花的玩家无法体会到游戏的精髓。《狂怒》的每个关卡固然都很有趣，玩家也可以利用开发者菜单随意挑关突突突，但若想真正理解这款游戏的魅力，非得花上几个小时不可。Carmack 提到两周前的媒体试玩活动：记者们坐下来玩了整整三个小时，才刚刚进入游戏的核心阶段，了解世界的架构、各种可选玩法，并在大门正式开启时完全被吸引住，到了必须交出手柄的时间甚至依依不舍地喊着“再给我一分钟”。 Carmack 透露，最新的宣传片展示了大量只有在第二张 DVD（即游戏后半程）才会出现的内容，体量极其庞大。在 Carmack 眼中，《狂怒》可能是 id 历史上他个人最享受的一款作品。他坦言自己虽然玩过自家的所有作品，但他从来不是那种能在死亡竞赛（Deathmatch）里连打 8 个小时的狂热竞技玩家；而《狂怒》张弛有度的节奏恰好切中了他的喜好——既有纯粹的恐怖与紧迫感，又有在城镇中探索、交流的缓冲地带。虽然 id 绝无意把《狂怒》做成能直接去跟《上古卷轴5：天际》（The Elder Scrolls V: Skyrim）相提并论的深度冒险 RPG，但团队在这次开发中认识到，可以在保留 id 经典动作手感的基础上引入更多层次，而且这些层次并不会破坏硬核射击本身的乐趣。 - **媒体深度试玩**：连续游玩 3 小时才刚刚接触到世界完全展开的阶段。 - **光盘载体与内容规模**：游戏容量达到 2 张 DVD，后半段拥有海量全新内容。 - **游戏节奏设计**：在高强度的极端战斗与城镇探索、NPC 交互之间取得平衡。 - 谈及自身的游玩偏好与节奏，John Carmack 直言：“It really is probably the most enjoyable id game from my perspective that we've ever made.” --- ### [04:31](https://www.youtube.com/watch?v=4zgYG-_ha28&t=271s) 技术的载体与艺术家的想象：“动态画作”般的视觉奇迹作为一个硬核工程师，Carmack 笑称自己随时都想开启“事后剖析（Postmortem）”模式，挑剔代码哪里还能优化、结构怎样改进；但他必须克制这种本能，因为团队确实达成了最初设想的几乎每一个目标。更重要的是，最终呈现的许多惊艳内容远远超出了他在项目立项乃至三年前的预想。他认为担任技术总监最令人心潮澎湃的时刻，莫过于亲眼看着艺术家和关卡设计师利用自己搭建的底层技术平台，创造出令人瞠目结舌的奇观。媒体曾用“动态油画（moving painting）”来形容《狂怒》的画面，Carmack 非常认同这个说法。在游戏中，玩家哪怕在激战之余停下脚步四处张望，也能发现周围并不是只有特意为了印在包装盒背面而打造的“展示样板间”，而是几乎每一个角落都浸透了美术人员和贴图印章师（Stampers）的心血。整个游戏包含了数以 TB 计的美术资产，其构建的细腻度与视觉冲击力让 Carmack 自己都深感震撼。 ```mermaid flowchart TD accTitle: id Tech 5 MegaTexture Workflow and Tradeoffs accDescr: 展示MegaTexture技术从数TB未压缩资产到运行时流送及优缺点的整体逻辑 subgraph ASSETS["资产生成阶段"] A["数 TB 级手绘美术与贴图资产"] --> B["MegaTexture 预处理与虚拟贴图切片"] end subgraph ENGINE["id Tech 5 核心引擎 (MegaTexture 占约10%代码)"] B --> C["智能调度与线性批处理读取"] C --> D["虚拟贴图运行时流送系统"] end subgraph OUTPUT["运行表现与权衡"] D --> E["优势: 60 FPS 丝滑帧率 + 动态油画质感"] D --> F["劣势: DVD寻道延迟(最坏150ms)导致贴图迟滞加载(最长约15s)"] end ``` - **数据资产规模**：数 TB 级的贴图与环境细节覆盖全图。 - **代码占比**：MegaTexture 相关的直接代码仅占数百万行代码库中的数万行（约 10% 的代码量，约 25% 的工作量）。 - John Carmack 在赞美美术团队的创造力时感叹：“I don't have that resolution of imagination that the artists can do where they can build these worlds that are just so fabulous.” --- ### [06:17](https://www.youtube.com/watch?v=4zgYG-_ha28&t=377s) 核心架构决断：MegaTexture 的优势、代价与流送极限谈到《狂怒》最标志性的技术特色，几乎所有人都会立刻联想到 MegaTexture（巨型纹理技术）。尽管它在代码库中仅占约 10% 的体量，却承载了大约 25% 的研发精力，并且是让游戏在当代主机硬件上既能保持 60 FPS 稳定帧率、又能呈现全手绘风格的绝对功臣。然而，这种近乎折磨的复杂设计也伴随着不可忽视的技术妥协和运行挑战。 Carmack 深入剖析了数据流送（Streaming）的现实表现。现场试玩的版本均为 PC 或已安装到硬盘的 Xbox 360，这代表了最佳的读取性能；而最糟糕的极端情况则是无硬盘的 Xbox 360 直接从 DVD 光驱实时读取所有贴图。即使引擎做了极其先进的智能寻址、批处理和线性排队，光驱磁头一次糟糕的物理寻道仍可能耗费长达 150 毫秒。如果一个复杂画面由上千个微小的贴图碎片拼接而成，在最极端的情况下，可能需要长达 15 秒才能让所有细节完全加载锐化。Carmack 自嘲道，如果要故意让画质崩坏，最直接的方法就是把视角灵敏度调到最高，背对着某个未加载的城镇角落走过去，然后猛一回头——玩家肯定会看到糊成一片的贴图慢慢变清晰。尽管这种物理限制客观存在，但 id 通过大量的优化工作将其对游玩体验的影响降到了最低，在绝大多数正常游玩场景下，画面呈现依然令人惊艳。 - **最差运行工况**：Xbox 360 仅靠 DVD 光盘读取，无硬盘缓存。 - **硬件延迟数据**：光盘极端寻道时间约为 150 毫秒；极端情况下整个场景的最高精度细节完全补齐可能长达 15 秒。 - **设计权衡**：以局部贴图流送迟滞（Texture Pop-in）为代价，换取全平台稳定的 60 FPS 与绝无重复平铺的手绘艺术世界。 - 面对流送机制不可避免的缺陷，John Carmack 坦率地指出：“And I know we're going to get dinged some by that there are going to be people that I you know that run up and if you want the recipe to make it look as bad as possible it's kind of back your way into something with a high sensitivity you know walk around backwards through town then flip around and look at something that you haven't had any chance to do and it'll come in it'll be blurry and it'll work its way in and that's just the reality of the way the technology works that we have to deal with.” ### [09:26](https://www.youtube.com/watch?v=4zgYG-_ha28&t=566s) 工程师的完美主义困境与图形权衡 John Carmack 谈到他在办公室里的日常开发状态：桌上一侧屏幕放着 Visual Studio，另一侧屏幕运行着游戏《狂怒》（Rage）。他握着手柄微调视角，脑子里总会冒出挑剔的想法，觉得画面的某些地方还不够完美，总想着能不能通过优化调度算法、给系统加入某种提示来把渲染效果做得更好。作为一名追求极致的工程师，他坦言自己常常陷入一种近乎沮丧的情绪中，因为脑海中总有太多未来能够继续改进的技术细节。然而，每当他看到测试人员在办公室里拿着手柄畅快跑图、执行日常测试任务时，心态便会立刻扭转回来，对游戏流畅的运行表现与行为响应感到由衷的高兴。工程开发的本质始终是一系列的取舍。为了赋予《狂怒》那种极具手绘质感与独特美术风格的庞大世界，id Software 团队做出了明确的妥协：接受纹理在流式加载时可能出现的一定程度延迟进场现象，并彻底放弃了完全通用的动态光照系统。 > “I can almost depress myself about how much more we can do to make things better in the future but then when I look at people playing the game just even in the office running around doing the the testing duties or whatever you know I'm back to okay that looks great I'm really thrilled to see it running that good see it behaving that way and it's you know it's always a set of tradeoffs in engineering where we you know we made these conscious decisions that we would live with some degree of textures coming in to give us this this painterly world we would give up on completely general purpose Dynamic lighting.” —— John Carmack - 现场花絮：演讲中途麦克风音频系统出现故障，Carmack 调侃道“麦克风系统报了个 bug”，随后稍作调整继续演讲。 - 技术取舍：以牺牲完全动态光照和容忍局部材质流式延迟为代价，换取全场景独一无二的超高细节手绘纹理世界。 --- ### [10:32](https://www.youtube.com/watch?v=4zgYG-_ha28&t=632s) MegaTexture 的分块机制与早期架构假设负责将材质切片调入内存的核心代码，是整个引擎中最复杂、耦合度最高且经过最极致优化的底层模块，内部针对纹理加载设计了多达四层的局部性缓存机制。在最贴近硬件的层级上，整个世界的材质不再是传统的“一堵 2000×1000 像素的墙”配上“一个 128×128 像素的咖啡杯”，而是被彻底打碎并划分为尺寸完全一致的纹理分页（Texture Pages），统一为 128×128 像素的数据块。这项技术源自 Carmack 大约五年前为 Splash Damage 制作《深入敌后：雷神战争》（Enemy Territory: QUAKE Wars）时的开发，随后在《狂怒》项目早期被泛化为通用引擎技术。当年团队通过数据测算认为，当世代的主机和 PC 硬件能够原生支持 4096×4096 尺寸的物理材质缓存；如果将这样一张大图切分为约 1000 个 128×128 的分页，屏幕分辨率大约为 100 万像素，而 4K 缓存提供了约 1600 万像素的容量，整整 16 倍的裕量足以覆盖视野内的所有绘制需求。在早期的封闭赛道演示（例如数年前展示的“Dusty 8”环形赛车场）中，这套系统运行极快、数据完全装得下，看似很快就能定型完善。 ```mermaid flowchart TD accTitle: MegaTexture 物理分页映射逻辑 accDescr: 展示场景纹理切分为 128x128 块并放入 4K 物理缓存的映射关系 subgraph WorldScene ["游戏世界几何体与材质"] LargeWall["建筑墙面 (统一网格)"] Prop["道具表面 (地面/载具等)"] end subgraph VirtualTiling ["分页切片划分"] P1["128 x 128 分页数据块"] P2["128 x 128 分页数据块"] P3["128 x 128 分页数据块"] end subgraph PhysicalCache ["GPU 物理材质缓存 (4096 x 4096)"] CacheSlots["~1000 个 128x128 分页槽位 (提供 1600 万像素容量，屏幕视野仅需 100 万像素)"] end LargeWall --> P1 LargeWall --> P2 Prop --> P3 P1 --> CacheSlots P2 --> CacheSlots P3 --> CacheSlots ``` - 分页规格：全场景材质统一裁切为 128×128 像素的块。 - 早期物理缓存：4096×4096 像素，包含约 1000 个分页槽位。 - 视野裕量比：屏幕分辨率约为 100 万像素（720p/1080p 区间），4K 纹理物理缓存提供 1600 万像素，理论上拥有 16 倍的过采样与缓冲余量。 --- ### [12:15](https://www.youtube.com/watch?v=4zgYG-_ha28&t=735s) 乐高式建模与“放开限制”的技术灾难早期 MegaTexture 技术最适配的美术工作流是将贴图如同一张大床单一样“包裹”在连续的地形或大型立面上，形成单一连续的“纹理岛”（Texture Island），这种方式性能极高且极其流畅。然而，制作人 Tim Willits 和 Matt Hooper 经常拿之后发生的一件事开 Carmack 的玩笑：美术人员开始改变管线，采用由无数微小、模块化的“乐高积木片”拼凑场景。原本整齐连贯的大型网格变成了成千上万个彼此断开的孤立材质微元。随着拼装场景越来越复杂，关卡设计师们要求程序员给出确切的指标边界与规范指南，询问究竟能放多少多边形和材质。面对这种提问，Carmack 解释称底层性能是由多边形数量、动态物体、粒子重绘（Overdraw）与纹理开销互相动态制约的，极其复杂，无法简单用一个数字回答。但在设计师们一再要求“给个数字”的逼迫下，Carmack 坦承自己当时做了一个非常糟糕的决定：他出于想借机倒逼技术突破的心态，告诉美术和设计团队“放手去做最酷的东西，回头我们在引擎里想办法解决”。这一放权导致后续工程团队不得不埋头耗费数年心血去收拾海量碎片化资产带来的性能残局。 > “The designers were beginning to say well we need some guidelines and some limits how many what can we do tell us what our guidelines are and as a programmer that's always a really hard thing to have a designer come up and say because the answer is it's really complicated... and everybody's like give us a number and I hemmed and hawed and I really made a really bad call and I said well you know I want to be pushed a little bit so go make really cool stuff and we'll figure it out.” —— John Carmack --- ### [14:19](https://www.youtube.com/watch?v=4zgYG-_ha28&t=859s) 缓存碎片化、平台内存鸿沟与架构拆分当美术构建出充满复杂栏杆与精细零碎物件的宏大布景时，4K 物理缓存的设计彻底崩溃。由于系统的最小分配单元必须是整整一个 128×128 像素的物理分页，哪怕远处的栏杆在屏幕上仅占一个像素的厚度，引擎也必须为了它调入整整一页材质。尽管引擎尽力将邻近碎块打包塞进同一张分页以减少浪费，但这引发了严重的虚假共享（False Sharing），并严重制约了各向异性过滤（Anisotropic Filtering）的表现。单个 4K×4K 缓存迅速捉襟见肘。在 PC 平台上，显卡显存充裕，解决办法只需暴力将缓存拉大到 8K×8K；但当代码移植到 Xbox 360 和 PlayStation 3 时，画质骤降了一半，Mipmap 严重丢失。在硬件限制下，各大平台的兼容方案变成了一场恶梦： | 平台 | 显存/纹理硬件特性与应对策略 | 局限性与最终方案 | |:--- |:--- |:--- | | **PC** | 显存极大，可直接开启 8K×8K 材质物理分页。 | 无法直接进行底层显存交错与别名复用（Aliasing）。 | | **Xbox 360** | 硬件上支持 8K×8K 纹理寻址；如果自主控制可进行内存重叠复用。 | 物理内存总量不足，无法直接常驻完整的 8K×8K 缓存。 | | **PlayStation 3** | 完全不支持原生 8K×8K 纹理采样。尝试过 Cube Map（6 面 2K×2K，寻址复杂）及 3D 体积纹理（切片寻址导致性能崩塌）。 | 彻底摒弃单一优雅大缓存架构，改用多张独立贴图流式加载。 | 由于主机硬件的硬性制约，Carmack 原本设计的那套所有数据顺畅汇入单一虚拟化纹理池的优雅架构被彻底打破。最终交付的引擎中充斥着妥协：系统被迫拆分成三张不同尺寸、不同深度复杂度的物理页面图像，其中有的使用单一 DXT 压缩，有的包含三张 DXT 图层，动态物体的虚拟材质（Virtual Materials, VIM）也必须独立分支处理。Carmack 感慨道，最初写出虚拟纹理原型只用了几天，搭出第一个无需预先加载整个关卡贴图的 Demo 只用了几个月，但为了满足美术与设计需求并让游戏顺利在所有主机上压盘发售，他们整整付出了数年的高强度工程攻坚。 > “We start off with this wonderful beautiful elegant virtualized system everything flows into all of this multiple pages and it's nice and clean and sounds good and we wind up with three different page images of different sizes and different depth complexities... all of this complexity comes in when you go from kind of the initial cool elegant demo of something to getting it through delivering what your artists and designers want and getting it out onto a shipping project.” —— John Carmack - 开发者痛点：Carmack 吐槽微软与索尼严格禁止零售版主机插入键盘呼出控制台或调试工具，导致开发人员甚至无法在正式版光盘上快速调出调试工具排查问题，而 PC 玩家则能随意打开控制台检视 MegaTexture 的内部切片与分页流式状态。 - I/O 延迟瓶颈：由于纹理被极度碎片化，如果直接从 DVD 光盘甚至机械硬盘进行随机小分页寻址，玩家只要稍稍转动视角就会遭遇巨大的拉取延迟（I/O Lag），必须在物理分页之前依赖更深层级的内存中间缓存系统进行平滑调度。 ### [19:20](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1160s) 主机端内存吃紧与多级纹理流式缓存架构在 PC 上操作系统自带页面缓冲缓存（buffer cache），处理起来相对轻松；但移师主机平台后，id Software 必须亲自接管并手动管理一切底层内存。团队构建了自己的二级缓存层，几乎吞噬了主机上所有可用的剩余内存空间——先加载当前必需的数据，剩下的每一个字节都拿来做纹理流式文件缓存（stream file cache），甚至连音频数据也共用这块内存。如果系统可用内存充裕，玩家只要看过一眼某处场景，数据便会驻留在缓存中，再次调用时速度极快；在许多独立的副本关卡（instance maps）里，这种机制表现非常顺畅。然而荒原（the Wasteland）大型户外场景成为了真正的极限压力测试用例。在这里，要把所有内容塞进主机内存极其困难，流式文件缓存的空间捉襟见肘。两款主流主机的内存架构差异更放大了这一痛点： - **PlayStation 3 的内存劣势**：PS3 采用了硬性切分的内存空间（Split Memory Space），一半固定划给图形渲染，另一半划给 CPU。虽然《RAGE》在高内存用量时本就会将图形显存打满，切分比例本身没有造成致命伤害，但 PS3 操作系统占用的额外内存较多，直接挤占了宝贵的流式文件缓存。 - **物理介质寻道的瓶颈**：如果数据无法驻留在内存中，就必须从硬盘甚至光盘（DVD 或更慢的 Blu-ray）读取。John Carmack 感叹道，软件开发在很多时候像是在空灵的代码世界中调度数据，但当听到蓝光光驱在物理层面疯狂转动、寻道并读取数据时，那种机械硬件的延迟成了系统性能的最大掣肘：“Like it'll be nice when we don't have that little physical element that we have to be scheduling for and working around.”（要是哪天我们再也不用为了那个机械物理部件去费心调度和妥协，那就太好了。）为了避免最恶劣的卡顿延迟，引擎引入了一套四级局部性缓存架构（Four levels of locality）： ```mermaid flowchart TD accTitle: RAGE 纹理数据四级缓存与转码流向 accDescr: 从光盘物理介质经过硬盘备份缓存、内存流式缓存，最终转码上传至 GPU 显存并在屏幕上显示 subgraph Storage ["物理存储层"] A["光盘介质 (DVD / Blu-ray)"] B["硬盘备份缓存 (Hard Drive Backing Cache)"] end subgraph SystemRAM ["主机内存层"] C["流式文件缓存 (Stream File Cache)"] D["转码线程管线 (Transcode Pipeline)"] end subgraph GPUVRAM ["图形渲染层"] E["GPU 物理纹理 (GPU Textures)"] F["屏幕输出 (Display Screen)"] end A -->|"首次读取 (长延迟寻道)"| B A -.->|"未写入硬盘时直接回退"| C B -->|"后续极速重载"| C C --> D D -->|"解包并重编码至 DXT"| E E --> F ``` - **四级局部性流程**：数据首次从光盘（DVD/蓝光）以极长寻道耗时读入，接着被回写至硬盘上的高速连续区作为“硬盘备份缓存”；下次再次需要时直接从硬盘拉入内存的“流式文件缓存”；最后送入转码管线解压并重编码，写入 GPU 真正访问的纹理内存，最终渲染投射到屏幕上。 ### [22:06](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1326s) 主机硬盘安装策略与多线程转码的工程挑战面对光盘读取瓶颈，最理想的手段是将数据预装到本地硬盘，但 Xbox 360 与 PS3 的策略机制截然不同： - **Xbox 360 的“全或无”限制**：微软系统不支持部分纹理安装，只能全盘安装 21 到 22 GB 的完整内容，耗时非常漫长。不过 Carmack 强烈建议 360 玩家有条件一定要装：“If you've got it and you're going to play it on a 360, that's the way to go; it makes a significant difference, everything comes in without having to hit optical media.”（如果你有硬盘空间而且打算在 360 上玩，那绝对是不二之选；它能带来脱胎换骨的改变，所有资源都无需再访问光盘。） - **PS3 的部分安装与商业谈判**：PS3 允许部分安装关键数据，此时发行商 Bethesda 正在全力跟索尼施压谈判，试图争取在玩家硬盘上多咬下几个吉字节的空间，以便多装下一个分页文件（page file），进而显著改善运行体验。 - **设计反思（分页切分）**：Carmack 坦承，如果早些时候有更多时间，更优的设计是将分页文件剥离——把所有低细节的基础纹理固化在硬盘缓存中，而高细节纹理留在蓝光光盘上（辅以临时硬盘缓存背书）。这样玩家就永远不会在转身时遭遇长达 1/4 秒、丑陋至极的纹理模糊过程。这套流式解算逻辑是整个游戏中最复杂精密、也最让人提心吊胆的底层代码： - **高并发异步线程系统**：该系统涉及多个高度异构的线程，包括专职读取 DVD 的线程、专职读取硬盘的线程、分析回读缓冲区（feedback buffer）以计算可见性需求的线程，以及大量的并发转码工作线程。 - **存储空间与算法取舍**：如果存储空间无限，最佳做法是以原生 GPU 纹理格式平铺存储，直接发起非缓冲读取（unbuffered read）直塞 GPU。但由于不能让玩家背负 8 张 DVD 的换盘地狱，盘片内容必须经由 Microsoft 授权的高压缩率 HD Photo 衍生算法进行高倍率压缩。 - **性能与开销的代偿**：相比 id 早期自研的 DCT 算法，微软的算法在光盘空间内带来了 30% 以上的画质优势，但代价是消耗整整两倍的解算算力。数据读入后由多个工作线程解压至 YCoCg 等色彩空间，随后必须实时将其再次重编码压缩为显卡硬件能够理解的 DXT 纹理格式。 ### [25:17](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1517s) PC 平台的驱动开销困境与集成显卡的底层突破尽管主流 PC 的硬件性能往往是当代游戏主机的 10 倍以上，但 Carmack 透露，要把 PC 版《RAGE》优化到像 Xbox 360 那样稳如磐石的 60 帧每秒，在工程上堪称一场苦战。核心症结并不在硬件算力，而在 PC 平台的**驱动层开销（Driver Overhead）**： - **主机的极致裸机访问**：在主机平台上更新虚拟纹理页面极其直接——引擎申请到新数据页后更新页表，往往只需计算出偏移量，然后直接往内存里写入一个整数（`int`）即可完成指针映射。 - **PC API 的多层损耗**：在 PC 上执行同样的操作，必须调用底层图形接口（如 OpenGL 的 `glTexSubImage2D`）。Carmack 形象地吐槽：“If you're a programmer and you start single-stepping through that, you'll cry, you won't make it back out, it'll just take forever.”（如果你是个程序员，试图去单步调试那个函数，你会哭出来的；你陷在里面根本出不来，它耗费的时间实在太长了。）造成这一局面的根源在于 PC 必须兼顾极其多样的内存架构，不同显卡芯片在平铺（tiling）和交叉混洗格式（swizzling formats）上各自为政。不过，产业生态正在显现转机，硬件厂商开始释出推动内存格式标准化的信号，而 Carmack 对英特尔（Intel）近年集成显卡（核显）的进步给予了极高关注： - **核显的潜力与统一内存架构**：尽管玩家长期以来把英特尔集成显卡当作只能运行文字处理软件（Word）的附赠品，甚至习惯对其嗤之以鼻，但《RAGE》已经在当前一代英特尔硬件上跑了起来。集成显卡天生具备主机式的统一内存（Unified Memory）架构。 - **绕过抽象层的底层愿景**：既然 CPU 和核显处于同一块物理内存中，Carmack 主张开发者应当可以直接拿到纹理的物理基地址、步长（stride）和内存混洗格式，然后直接通过 CPU 内存写入将纹理推过去。 - **传统图形界的思想阻力**：尽管英特尔已初步认可该方向，但传统图形学领域的老派开发者仍然对暴露内部硬件格式极为抗拒。PC 图形界长期习惯在驱动背后偷偷做黑盒操作与层层抽象，而在 Carmack 看来，正是这种黑盒文化给 PC 3D 图形工业带来了无穷无尽的性能痛苦与折磨。 ### [28:52](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1732s) 硬件抽象的漏洞与 PC 驱动的“历史考古” DirectX 等图形 API 在设计上常常假定开发者可以锁定图像的一个矩形区域，但这种抽象并不完全符合底层硬件的实际运作方式。在许多情况下，图形驱动程序背后的实际操作极为繁琐：它需要将整张纹理在内存与显存之间拷入拷出，反复进行像素重排（Re-swizzling），表面上维持着统一的 API 假象，随后再执行逆向操作将其写回显存。这种设计成了典型的“有漏洞的抽象”（Leaky Abstraction）。在常规编程中，抽象机制让开发者能够忽略具体细节、获得统一的行为特性，但在面对极致的实时计算时，这种抽象层往往会带来致命的开销。在主机平台运行顺畅的代码，一旦移植到 PC 上，即便硬件参考手册标明底层可以直接通过 DMA 抓取数据或写入寄存器，驱动程序为了兼容抽象层也必须执行极其迂回复杂的工作区绕行（Workarounds）。 ```mermaid flowchart TD accTitle: PC显卡驱动抽象层的开销与主机直接访问对比 accDescr: 对比传统PC抽象API隐藏的数据复制重排与主机的直接DMA操作 subgraph PC ["PC 平台 (高开销抽象)"] A["API 调用: 锁定局部矩形"] --> B["驱动在后台将整张纹理拷出"] B --> C["执行像素重排 (Re-swizzling)"] C --> D["开发者修改数据"] D --> E["执行逆向重排并写回显存"] end subgraph Console ["主机平台 (底层直通)"] F["游戏引擎调度"] --> G["直接 DMA 抓取与内存直写"] end ``` 谈及驱动中为何充斥着如此多的特例补丁，John Carmack 坦率地自我检讨，指出自己当年的失误也是促成这一现象的“罪魁祸首”之一。他回忆道，自己在编写早期版本的《Quake》时，为了获取 OpenGL 扩展字符串（Extension String），草率地分配了一个大约 1000 字符的固定缓冲区，心想这足以容纳所有扩展名称。然而随着显卡技术的演进，驱动支持的扩展字符串膨胀到了数万字符，直接导致缓冲区溢出并踩踏内存。显卡厂商为了确保老游戏能够正常运行，不得不暗中在驱动中加入针对旧版《Quake》的检测补丁，一旦识别到该游戏，就强制返回一段经过裁剪的短字符串。Carmack 直言：“所以 PC 驱动里塞满了这类东西是有原因的，这完全是历史考古遗留问题；但令人无奈的是，它们不得不依赖如此压倒性的暴力手段，才能弥补相比主机所缺失的底层优势。” - 核心矛盾：高级抽象抹平了硬件差异，但在毫秒必争的实时图形渲染中，驱动背后的整纹理拷贝与格式重排会带来巨大延迟。 - 历史技术债：早期《Quake》用 1000 字节缓冲区接收 `glGetString(GL_EXTENSIONS)` 导致溢出，迫使 NVIDIA、AMD 等厂商在驱动内硬编码特征检测代码，返回兼容的缩短版扩展列表。 --- ### [31:08](https://www.youtube.com/watch?v=4zgYG-_ha28&t=1868s) 帧率交换间隔、动态分辨率与自适应垂直同步与《雷神之锤 3》（Quake III Arena）时代多达 20 家图形芯片厂商混战、驱动质量良莠不齐的局面相比，Carmack 对如今行业只剩下三家主流图形厂商（NVIDIA、AMD、Intel）的现状感到十分欣慰。现代厂商的技术人员具备高度专业素养，能够与游戏开发者展开深入的技术对话，并在关键瓶颈上迅速达成共识。在主机平台的开发中，id Software 全力保证游戏严格以 60 FPS 随帧交换间隔（Swap Interval）同步刷新。为了维系这一目标，引擎内置了实时监控与动态分辨率缩放（Dynamic Resolution Scaling）机制，一旦检测到渲染管线即将超过帧预算，便会在后台平滑降低渲染分辨率。目前这套系统仍以响应式机制为主，在遇到视野外突然冲入的爆炸或大量粒子过度绘制（Particle Overdraw）等无法预测的突发场景时，依然可能会丢帧。 Carmack 重点分析了传统 PC 游戏在垂直同步（V-Sync）上的两难处境：要么强制锁定帧交换，在帧率跌破 60 FPS 时瞬间暴跌至 30 FPS，产生令人极其难受的卡顿与往复跳跃（Bobbling）；要么彻底关闭同步，任由撕裂线（Tear Line）切割屏幕，而撕裂恰恰是现代高速 PC 游戏中最刺眼的画面瑕疵之一。针对这一痛点，id Software 率先在主机上实现了兼顾流畅度与画面完整性的折中方案：只要维持在 60 FPS 就严格锁定垂直同步，一旦发生掉帧，允许画面产生短暂撕裂，配合动态分辨率适配，在几帧之内迅速将撕裂线推回屏幕顶端并恢复锁定。Carmack 成功游说了 NVIDIA 和 AMD 将该策略引入 PC 驱动： > “我们可以无休止地争论一些相对无关紧要的事情，比如滤波核心的尺寸，以及图形极客们能永远聊下去的各类话题；但我们眼前正有一条愚蠢丑陋的撕裂线横贯屏幕，或者承受着非等时性的帧交换问题，而这才是真正需要去解决的大事。” —— John Carmack 最终，NVIDIA 迅速设计了一个略带黑客风格但极其高效的接口规范——直接利用“负数帧交换间隔”（Negative Swap Intervals）来表达“在能达到目标帧率时进行同步交换，否则允许撕裂”的自适应逻辑，AMD 也随即跟进支持。 - 动态分辨率设计：主要通过监控渲染时间动态调整画面分辨率，未来希望从“响应式调节”演进为“预判式调节”（例如在触发大型爆炸逻辑时预先降级渲染）。 - 自适应垂直同步规范：定义负数 swap interval（例如 `-1`），让显卡在 60 FPS 时锁定垂直同步，掉帧时退化为即时刷新并产生撕裂，避免硬性腰斩至 30 FPS。 --- ### [34:51](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2091s) PC 版《狂怒》调优、引擎实验与不可持续的开发周期在《狂怒》（Rage）PC 版本的近期规划中，开发团队并没有堆砌激进的 PC 专有渲染特效，而是致力于针对不同硬件配置进行关键参数微调。针对配备数吉字节（Multi-Gigabyte）大容量显存的现代显卡，团队计划将主机端使用的 4K×4K 物理纹理缓存提升至 16K×16K，使绝大部分高频使用的贴图能够长期驻留显存，从而大幅减少运行过程中的纹理转码（Transcoding）次数。此外，Carmack 表达了自己想要重启类似当年《GLQuake》研究型实验引擎的想法：当年他直接抛出一个未经官方技术支持的独立可执行文件，利用原有游戏数据展示尖端图形技术。虽然如今公司规模已非往日可比，推出完全不受支持的实验版本存在一定风险，但他依然非常渴望探索在不推翻现有管线的前提下，将当前的《狂怒》资源推向视觉极限。 Carmack 谈到，尽管体素（Voxels）、光线追踪（Ray Tracing）、表面飞溅点渲染（Splatting）等非多边形渲染技术充满吸引力，但重新打造一整套内容生产管线的代价过于高昂——光是《狂怒》所采用的虚拟纹理（Virtual Texturing），从最初的技术演示到最终落地生产就耗费了整整五年时间。更关键的是，id Software 的主线游戏研发耗时呈现出指数级增长的危险态势，这种每一作都比前作花费更长时间的研发模式已经逼近极限。Carmack 总结道： > “冷酷无情的事实是，id Software 本部主线上产出的每一款游戏，其研发耗时都比前作更长，而这种情况是绝对不能继续下去了。” —— John Carmack 他强调，如果一条趋势线表明团队未来需要耗费三十年才能做出一款游戏，那么这种增长必然会终止。真正决定公司命运的，不是能不能无限膨胀，而是当“无法继续维持”的时刻到来时，团队如何通过平稳减速实现软着陆，避免硬着陆导致的毁灭性坠毁。这也深刻影响了 id Software 对未来技术研发路径的战略权衡：行业在图形技术上的边际收益已经越过了曲线拐点，单纯堆砌画面已不再是唯一的驱动力。 - 物理纹理缓存扩展：PC 版计划利用大显存将 Cache 纹理从主机的 4096×4096 扩大到 16384×16384，显著消除转码压力。 - 研发周期反思：虚拟纹理从演示到工业化耗时超过 5 年，促使团队重新审视内容管线与生产周期的边际效益。 ### [38:16](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2296s) 坚守 60 FPS 与开发末期的“研究型引擎”探索谈到《狂怒》（RAGE）在技术规格上的权衡，John Carmack 坦言，团队完全可以把画面做得更华丽，做成市面上绝大多数竞争对手那样的 30 帧游戏，但他们在早期就做出了坚持 60 帧的艰难抉择。这是一场痛苦的拉锯战，给美术、关卡设计和程序团队带来了巨大的折磨与煎熬，但走到今天，每个人都对这个决定感到无比欣慰。Carmack 直截了当地指出：“我们可以做更花哨的画面，有各种技术能让游戏看起来更棒，但我宁愿要两倍的帧率。” 眼下游戏的主体开发已经完工，不过办公室里依然有同事在通宵达旦地赶工制作送审候选版本（Submission Candidates），处理各种边缘极端情况——比如在换盘的瞬间，有人发来多人联机邀请，同时玩家又拔掉了记忆卡，系统该如何响应。随着核心工作的移交，Carmack 最近抽身出来，新开了一个小项目写代码，折腾几个研究性质的原型引擎。这些研究虽然不会拿去重新做主机认证，但未来很可能转化为 PC 平台的额外技术探索。他非常想看看，如果利用现有的游戏素材，在不计成本的前提下把抗锯齿和动态模糊做到“光速级”的极致完美，究竟能带来多么惊艳的效果。 - **PC 算力过剩**：PC 拥有主机 10 倍以上的硬件性能，但《狂怒》在 PC 上基本只被当成一台“肌肉更强劲的主机”使用，并未加入 DirectX 11 曲面细分（Tessellation）等技术；Carmack 强调自己不赞成这种后期生硬拼凑（bolt-ons）的做法，这类架构必须从一开始就通盘设计。 - **送审修罗场**：团队仍在修补像“换盘 + 拔记忆卡 + 收到联机邀请”这类罕见崩溃 bug，以确保各平台一次性通过认证。 --- ### [41:15](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2475s) 十亿倍算力跃迁：从 Atari 2600 到 192GB 服务器内存当凝视当今顶尖显卡那近乎疯狂的算力时，Carmack 常常忍不住微笑并惊叹不已。往年他常提自己职业生涯见证了算力翻一百万倍（从早年第一款游戏到现在），但一两个月前，他在查阅自己出生前后的技术史时，发现这个跨度其实达到了整整“十亿倍”（9 个数量级）。他在互联网上研究了童年时代的雅达利 Atari 2600 编程、ROM 和反编译代码，感叹那台极其原始的机器当年仅有 128 字节的 RAM，早期卡带 ROM 只有 2KB，后期即便用了高级的 Bank 切换技术也才勉强达到 16KB。回到《狂怒》的生产流程中，烘焙动态虚拟纹理（Virtual Textures）曾经耗时长达数小时。Carmack 重写了这套工具，改用海量的内存映射文件（memory-mapped files）来加速，结果导致普通机器疯狂进行内存分页交换（swapping）。为了探明物理极限，团队干脆采购了一台服务器，直接塞满了 192GB 的物理内存——整台机器花费约 5,000 美元，甚至比他们早年花 10,000 美元买的工作站还要便宜。从 128 字节跃升到 192GB，从 2KB 卡带跃升到如今满大街的 2TB 硬盘，Carmack 惊叹于这种在其他领域根本见不到的十亿倍跨越。 ```mermaid flowchart LR accTitle: 十亿倍存储与算力对比 accDescr: 对比雅达利2600与2011年构建服务器的内存及存储容量，展示跨越9个数量级的增长。 subgraph S1["雅达利 2600 时代 (童年)"] direction TB A["RAM: 128 字节"] B["ROM: 2KB ~ 16KB"] end subgraph S2["《狂怒》生产管线 (2011年)"] direction TB C["服务器 RAM: 192GB"] D["日常存储: 2TB 硬盘"] end S1 -->|"容量膨胀逾 10 亿倍 (9个数量级)"| S2 ``` - **摩尔定律的分野**：单核串行时钟频率的提升已经基本见顶，未来的增量将完全来自于海量多核心并行与 GPU 计算架构。 - **巨大的资源支配问题**：面对未来翻倍乃至数个数量级增长的算力，游戏开发者最核心的问题是到底拿这些硬件红利来做什么。 --- ### [44:20](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2660s) 消耗算力的狂想与《狂怒》纹理分辨率的现实局限在审视如何消耗 PC 和次世代主机的算力时，常规操作无非是把分辨率从 720p 拔高到 2.5K 甚至组多屏（吞掉 3 到 10 倍性能）、拉满 4x/8x/16x MSAA，或者提升 HDR 动态范围。但 Carmack 提出了一个更前卫、甚至“近乎犯罪般浪费浮点性能”的技术设想：“我想我们完全可以对整张屏幕执行快速傅里叶变换（FFT），做全屏卷积运算，这样镜头的眩光就不再是现有的贴图精灵和模糊效果，而是把全屏与巨大的星芒做卷积，让每一个像素都精准呈现。” 讨论完技术狂想后，Carmack 主动谈及《狂怒》即将面临的现实批评：玩家如果把脸贴在墙壁上，会发现纹理变得模糊。由于虚拟纹理系统没有额外叠加细节贴图（Detail Maps），某些局部的实际分辨率甚至低于纯粹使用重复平铺贴图（Tiling Textures）的传统游戏。造成这一现状的核心瓶颈依然是物理介质： - **光盘介质的束缚**：Carmack 预测短期内没有任何介质能取代蓝光，而 DVD 更是迫使《狂怒》必须换盘。 - **跨平台一致性与 PS3 的遗憾**：Carmack 坦言虽然这话可能被断章取义，但他确实后悔没能把 PS3 的双层蓝光光盘空间彻底撑满。如果当时改变压缩比、保留更多细节，PS3 版本的贴图质量本可以大幅提升；但现实是编译管线早已卡在生死线边缘，盲目冒进可能导致整个项目翻车，加之 PS3 的可用内存最少、蓝光光驱寻道时间最慢，实际收益仍存变数。 - **PC 高码率实验构想**：他希望未来能在 PC 上推出一款 DLC 试水，将某个单关的编码码率提高 10 倍，把原本 300MB~500MB 的数据撑大到 2GB，以此验证在正常游玩状态下，超高贴图码率到底能带来多大肉眼可见的画质提升。 ### [48:11](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2891s) 巨型纹理的数据吞吐与源数据规模《狂怒》（RAGE）在发行时虽然被压缩到了能够容纳在单张 Blu-ray 光盘（约 20 多 GB）或三张 Xbox 360 DVD 内，但其原始资产的规模却大得惊人。John Carmack 解释说，构建巨型纹理（MegaTexture）所用的全部源美术资产——包括山体、地面和各类印章（stamps）等——其分辨率甚至撑爆了一张 $256,000 \times 256,000$ 像素的纹理画布。这相当于 640 亿像素（64 Gigapixels）的源数据，每个像素由 3 幅包含 3 到 4 个通道的图像组成（共计 12 字节），再加上 Mipmap，光是用于烘焙关卡纹理的源美术资产就达到了 1 TB。当这些源美术与光照烘焙组合成最终输出时，规模依然极其庞大。游戏中最大的关卡输出尺寸约为 $128,000 \times 128,000$；动态角色通常能塞进 $64,000 \times 64,000$ 的贴图中；而辽阔的废土（Wasteland）则被切成了 14 个区块，尺寸从 32k 到 128k 不等，甚至单张 256k 贴图都无法装下。如果直接以未经压缩的 RGB 格式打包发布，整款游戏的数据量将轻松突破上百吉字节。 ```mermaid flowchart TD accTitle: MegaTexture Data Pipeline accDescr: 巨型纹理从原始资产到最终打包的管线流程 subgraph Source["原始资产阶段"] A["源美术资产\n(山体、地形、印章)"] B["64 Gigapixels / 12 字节像素\n加上 Mipmap 约 1 TB"] A --> B end subgraph Baking["烘焙与切块"] C["结合静态光照进行烘焙"] D["关卡贴图: 最高 128k x 128k\n动态角色: 64k x 64k\n废土环境: 拆分为 14 个区块"] B --> C C --> D end subgraph Compression["压缩与优化"] E["HD Photo / 专有压缩算法"] F["基于玩家视点的可见性分析\n(低精度远景)"] G["最终分发体积\n1x Blu-ray / 3x DVD (~20+ GB)"] D --> E D --> F E --> G F --> G end ``` ### [50:35](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3035s) 视点分析优化、PC 画质妥协与后期特效争议为了将上百 GB 的纹理塞入光盘，id Software 除了使用类似 HD Photo 的高压缩比算法外，还采用了基于玩家可达区域的视点分析技术（profiling）。系统会采样数以亿计的玩家视角，仅对玩家能靠近的区域烘焙高分辨率纹理，而对远处无法到达的表面（例如屋顶或守卫哨塔的顶端）分配极低的分辨率。这一优化以 720p 主机分辨率为基准，导致在高端 PC 上用高分辨率显示器游玩并开启穿墙控制台指令（noclip）飞到高处时，屋顶纹理会显得非常模糊。这在开发阶段让习惯了在 PC 原生环境下创作的美术人员感到非常沮丧。与此同时，画面的视觉风格也引发了内部争议。id 过去常因画面“过于昏暗”而饱受批评，艺术家往往坚持让玩家在全黑的房间里体验，但 Carmack 极力主张提高亮度让玩家能看清细节。但在后期处理（post-processing）特效的使用上，Carmack 坦言自己彻底输掉了辩论。许多团队成员喜爱后期效果营造的氛围，但 Carmack 认为这些模糊、滤镜等后期特效破坏了引擎团队历经千辛万苦压缩保留下来的清晰像素。 > “在现实中，人们往往在玩《毁灭战士 3》（Doom 3）时，一半的内容根本看不清楚。因此我们做出了自觉的努力去提亮画面，但《狂怒》开发过程中发生的一些情况是：我们有了真实的光照，紧接着又加上了后期处理特效……每次我调出控制台关掉后期处理时，我都会觉得‘哇，这样看起来好多了，画面锐利、清晰，细节尽收眼底，色彩也没有被弄得乱七八糟’，但很显然我输掉了这场辩论。” —— John Carmack - **视点优化缺陷**：在 300 万像素（约 1440p 或更高）的 PC 显示器上，无法近距离接触的场景物体因源数据分辨率不足而显得失真模糊。 - **高画质包设想**：Carmack 提到，如果未来有机会为 PC 版制作超高质量纹理下载包（super quality pack），弥补被压缩或降低精度的资产，将会是非常理想的补偿方案。 - **后期特效代价**：后期处理虽然增强了废土的末日氛围感，但在技术层面上不可避免地劣化了巨型纹理千方百计保留的高清细节。 ### [54:09](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3249s) 规模化团队下的静态代码分析与微软工具随着团队规模的急剧扩大，id Software 已经从早年由 Carmack 和一两名助手包揽核心底层代码的模式，转变为拥有多个项目组、代码邮件列表（Alias）涵盖 49 人的中大型软件工程组织。面对数百万行的庞大代码库，仅凭“编写优秀软件”这种模糊的主观追求，已经难以杜绝语法和逻辑层面的隐患。不同的程序员拥有不同的编码风格，而关于某种语言特性的争辩往往会上升到“只有糟糕的程序员才会写出 Bug”的阵营宗教战争。为了用更科学的方法提升质量，Carmack 在过去两三年间深入研究了静态代码分析工具（Static Code Analysis）。起初，静态分析服务商 Coverity 为 id 提供了测试，从庞大的代码库中仅扫描出了大约 100 个问题，并盛赞该代码库的质量远高于行业平均水平。尽管 Carmack 对团队的技术水准感到自豪，但面对 Coverity 高达 50,000 美元的软件授权报价，团队决定暂时搁置采购，转而探索其他方案。 Carmack 随后把目光投向了微软。微软研究院（Microsoft Research）将其实验室技术产品化，内置到了编译器的 `/analyze` 选项中。虽然在 PC 平台该功能往往被捆绑在售价高达 10,000 美元的 Visual Studio 超级旗舰版本中，但微软却慷慨地将其免费内置给了所有 Xbox 360 SDK 开发者。Carmack 幽默地推测，这或许是因为微软不在意 PC 应用是否多 Bug，但绝不希望 Xbox 360 平台出现崩溃游戏来损害主机的声誉。 - **团队协作与代码量**：id 内部的开发团队分为两个主力大组和两个小组，数百万人次编辑与提交积累了数百万行代码，无法再依靠纯肉眼审查来保证绝对安全。 - **商用工具试用**：Coverity 提供的代码分析验证了 id 代码的高可靠性（仅挑出约 100 处潜在风险），但 5 万美元的价格使其在当时未被立即采纳。 - **主机平台专享福利**：Xbox 360 SDK 开发者标配的代码分析功能极大降低了主机端由于指针越界、未初始化变量等低级错误引发的系统级死机几率。 ### [58:01](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3481s) 引入微软代码分析工具与软件可靠性的统计学本质约翰·卡马克（John Carmack）重点强调了微软分析工具（`/analyze`）对 Xbox 360 开发者的价值。他毫不保留地发出警告：“我可以毫不犹豫地明确说，任何正在听这个演讲的 360 开发者，如果你没有使用 analyze，那你正在犯一个错误。”（“I'll say this quite clearly with no hesitation: any 360 developers that are listening to this, if you're not using analyze, you are making a mistake.”）虽然在此之前团队刚用 Coverity 清理出大约 100 个问题，但随着代码量膨胀和新程序员加入，首次开启微软的静态分析工具时，依然扫出了成百上千个潜在隐患。尽管程序员们本能地辩解“那不是真正的错误，我知道自己在写什么，上面的逻辑能保证不会出错”，但实际排查中充斥着“上方做了空指针检查，下方却漏掉了”的真实失误。当这种错误在代码库中重复出现成百上千次时，卡马克彻底转变了对编程与软件可靠性的认知。卡马克借传统工程学对比了软件开发的本质差异。传统结构工程（如机械、土木）在评估材料可靠性时，依据的是极限抗拉强度、屈服强度分布以及公差累加，从而建立一套成熟的可靠性理论。有人争辩说软件是完全确定性的（deterministic）——只要没有未初始化变量或随机内存，给入相同输入就必定得到相同输出，根本不存在传统物理材料的随机疲劳失效。然而卡马克反驳道，一旦代码库达到数百万行、团队拥有数十名开发者时，系统的失误率便呈现出一种令人沮丧的统计学分布（distressingly statistical nature）。即使软件执行本身是确定性的，但人类编写和维护软件的过程却完全是一个充满随机概率的统计过程。 ```mermaid flowchart TD accTitle: 软件开发从确定性执行到统计学失效的转变 accDescr: 图表展示了小规模代码的确定性特征在大团队和数百万行代码下转化为统计学失误概率的过程。 subgraph Deterministic ["确定性执行视角"] Input["相同输入"] --> Code["程序逻辑分支"] Code --> Output["确定输出 (无随机未初始化变量)"] end subgraph Statistical ["统计学开发流程"] Team["数十位开发者"] --> Lines["数百万行代码"] Lines --> Bugs["编码失误概率分布"] Bugs --> Crashes["复杂的罕见崩溃"] end Deterministic -.->|"代码规模急剧膨胀"| Statistical ``` - 微软静态分析工具对 Xbox 360 开发者免费提供，开启后直接揭示出数百个潜在隐藏 Bug。 - 最典型的报错场景是“潜在空指针访问”：开发者虽然在函数前半段小心防范，却在后半段由于疏忽漏掉了校验。 - 软件工程在规模化之后，缺陷的爆发遵循统计学规律，而非纯粹的确定性受控逻辑。 --- ### [01:00:45](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3645s) 个人错误日志记录与复制粘贴反模式在全面拥抱静态代码分析之前，卡马克做过一项有趣的自我实验：建立一份长期的“个人编码错误日志”。他排除了编译报错或刚跑起来就直接崩溃的初级错误，专门记录那些自以为已经编写完好、却在数天、数周乃至数月后才被暴露出来的隐性逻辑缺陷。持续记录后，他从自己的编码习惯中发现了惊人且反复出现的模式。最经典的教训发生在处理数字元组（如 X、Y、Z 坐标）的场景。开发者普遍习惯写完一行涉及 X 的逻辑，直接复制粘贴两遍，再手工将第二行改为 Y、第三行改为 Z。卡马克统计发现，在长达半年的时间里，有三次严重的隐蔽错误正是由这种“复制粘贴并修改变量”的习惯导致的。例如在处理图像色彩通道时，由于没有将变量 Z 修改为 W，导致 Alpha 通道悄悄拷贝了 Blue 通道的数据；由于这个 Alpha 通道此前从未被显示查看过，该缺陷潜伏了很久才被察觉。卡马克指出，一次失误可以归为偶然异常，但出现两三次就代表形成了某种系统性趋势。要彻底根除这类错误，绝不能指望程序员每次保持高度警惕，而必须改用循环、模板（templates）或面向对象封装等机制，从语法和结构上消除开发者复制粘贴代码的冲动。 - 个人错误日志仅记录“开发阶段以为正常、后续才浮出水面”的实质逻辑缺陷。 - 半年内发生 3 起因 `x, y, z, w` 变量复制漏改引发的恶性隐蔽 Bug（如 Alpha 通道被错赋为 Blue 通道）。 - 靠纯粹的个人自律无法避免惯性失误，唯有重构模式（如泛型、抽象、循环结构）才能阻断犯错途径。 --- ### [01:02:43](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3763s) 严苛的构建标准与代码长生命周期的维护挑战 id Software 对静态分析推行了极其严苛的规范：开启所有警告并将“警告视为错误”（Warnings as Errors）。只要静态分析器报出任何警告，游戏就无法完成编译和运行。有时程序员会争辩分析器的判断并不准确，代码通过复杂的外部逻辑能确保安全；卡马克则会严肃地劝诫团队：“‘如果你还得向我专门解释这段逻辑，也许你该做的是改写这部分代码。’”（“‘If you had to explain that to me, maybe you should change the way the code is working.’”）他的核心逻辑在于：如果连静态分析器都无法理清其前置条件，未来的其他程序员也绝不可能瞬间看懂，这迟早会在后续维护中酿成大祸。卡马克坦言，单打独斗的小型原型项目可以使用动态类型语言快速乱写（hack），但大型商业引擎的代码寿命超乎想象。他告诫团队中的程序员，现在写下的代码在十年后很可能仍以某种形式在运行，即便是当时的现代游戏中，依然能翻到初代《Quake》的零星代码行。大型项目中最典型的崩溃正是来源于“前置条件的破坏”：某个函数最初假设目标敌人只能是非玩家角色，但数年后另一名程序员为了增加新功能，在未梳理上下游条件的情况下直接在下方加了一段逻辑，最终导致在“玩家坠亡的同时被敌方载具碾压且恰好切换武器”这种极端罕见的交叠状态下，游戏直接崩溃。 - 编译规则硬性要求：分析器警告一律视同错误，不清除警告禁止运行游戏。 - 难以被静态分析工具理解的代码等同于“可读性极差”，必须通过重写来降低心智负担。 - 代码库生命周期极其漫长（当代引擎中甚至残留着初代《Quake》代码），后人维护时极易破坏早期的前置假设条件（preconditions）。 --- ### [01:04:58](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3898s) 进阶工具链探索：从 PVS-Studio 到远古巨兽 PC-lint 面对技术挑战，卡马克强调团队不能再用八年的漫长时间去交付下一款游戏。为了在缩短开发周期的同时维持激进的技术突破，程序员不仅要对自己的代码抱有自豪感，更必须借助各种严苛的工具手段。在彻底跑通微软 analyze 并做到零警告后，卡马克进一步引入了第三方静态分析器 PVS-Studio，随后又翻出了静态分析界的古老鼻祖——PC-lint。卡马克回忆起一段趣事：他在自家的壁橱里偶然翻出了一张第 7 版 PC-lint 的光盘。这让他回想起在开发《Quake 3》的时代，全团队只有三名程序员在用纯 C 语言编写代码，当时他也曾试运行过 PC-lint，虽然觉得它对提升代码质量有帮助，但当时并没有坚持用下去，也未曾体验到如今这种被静态分析彻底“震撼洗礼”的顿悟感。现阶段 id Software 的引擎在微软 analyze 和 PVS-Studio 两个工具下已经做到了“像刮水刀刮过一样一尘不染、全无报错”（squeegee clean error free）。然而 PC-lint 则完全是另一头凶猛的巨兽，它的信噪比要高得多，充斥着海量极其吹毛求疵（pedantic）的语法与风格警告，彻底驯服它需要付出更为艰难的努力。 - id Software 确立的效率底线：绝不能在下一款游戏的开发周期上再耗费 8 年时间。 - 研发代码在微软 analyze 和 PVS-Studio 两个自动化分析体系下均已实现 100% 零警告通过。 - PC-lint 源自早期 Unix 系统的 lint 工具，针对 C/C++ 提供极其详尽但信噪比偏低的极度挑剔检测。 ### [01:06:54](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4014s) 代码质量与开发实践的经验教训 John Carmack 坦诚地谈到了他在代码库中处理警告（warnings）的挫败感。尽管他非常希望在交付前清理所有警告，但面对成千上万条记录，即便其中许多可以归因于初始化逻辑等可控因素，仍难以排除其中埋藏的致命隐患。他意识到，试图通过“挥手示意”来忽略这些潜在问题是不够的，因此团队正在努力从源头编写更高质量的代码。他提到《Doom 3》的一个重要教训：脚本解释器（script interpreters）在性能、调试和开发层面都是弊大于利的。虽然人们常争辩动态类型语言能为非程序员提供便利，但 Carmack 的观点非常明确：“One of the big lessons of a big project is you don't want people that aren't really programmers programming, you'll suffer for it.” Carmack 进一步指出，尽管系统性能比过去提升了百万倍，但性能瓶颈依然存在且令人惊讶。在《Rage》开发的最后阶段，团队甚至被迫将部分 Flash GUI 组件转换为 C++，因为脚本逻辑的开销达到了毫秒级别。这种性能的现实让他更加渴望对代码质量实施严格的保证，目标是实现一种通过深度分析就能确定“游戏绝对不会发生任何类型的异常”的状态。为了实现这一点，他在《Doom 4》中引入了“Super Script”，这实际上是一种在 C++ 中运行的受限子集，既保留了脚本语言在任务调度上的便利（如 fiber 协作），又具备了 C++ 的性能和类型安全。 ### [01:09:44](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4184s) C++ 子集的必要性与程序员的局限性 Carmack 表达了对“严格限制 C++ 方言”的偏好，他认为无论程序员水平多高，错误都是不可避免的。他不仅将这种错误视为必然，还将其内化为开发流程的核心考量：“No matter how good you think you are, you are making mistakes all the time, and you have to have structures around you to try and help you limit the damage that your mistakes will cause.” 他理想中的开发环境是在编译时（compile-time）尽早发现问题。他曾认真考虑转向函数式编程语言（如 Haskell 或 OCaml），但考虑到行业现实、团队规模（当时有 49 人）以及招聘和性能方面的挑战，这并非可行的路径。因此，他提议在 C++ 的基础上实施严苛的约束，使其更像“Java 子集”：禁止未检查数组、禁止未初始化指针、禁止使用释放后的内存等。他强调，仅仅靠口头约定是不够的，必须通过工具分析整个代码库，仅在极少数对性能极其敏感的区域放行，而在绝大部分业务逻辑中强制执行这些安全准则。 ### [01:12:37](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4357s) 对未来开发节奏的展望 Carmack 回顾了过去六年未发布游戏的时间跨度，并对此进行了深刻反思。他认为团队在《Rage》开发中投入了太多的性能冗余，如果能适度放宽，本可以在同一时间内推出两款游戏。他直言不讳地表达了遗憾：“If you could turn back time, what I wish we had done is taken something with id Tech 4, done another game, and just rolled right into a Doom 4 there while Rage was under development and have a game every three years.” 他强调，公司不希望再次进入那种漫长的等待期。此外，他分享了对公司规模扩张（已超过 200 人）和开发环境变化的看法。现在的 id Software 需要在公司内部处理多平台移植和集成工作，这增加了巨大的额外负担。在谈到被记者称为“Old Man Carmack”以及从“年轻天才”向“行业老手”的转变时，他表现得非常务实且不感伤。他反复向记者强调：“I don't spend a lot of time thinking about the good old days because the good old days are right now.” 他认为自己现在是比以往更好的程序员，并享受着目前的游戏开发工作，包括他每年在移动项目上投入的宝贵研究时间。 ### [01:16:15](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4575s) 移动端开发预算超支与技术回顾约翰·卡马克（John Carmack）谈到了他在移动端项目上的时间分配。他通常会留出 10% 的精力来处理这些旁支项目，但在早期开发《狂怒》（Rage）的 iOS 应用时，他稍微超出了这一预算。从历史经验来看，移动端开发更像是卡马克的“复古时光”。在那些日子里，他可以重新钻研如何编写软件光栅化器，或者如何在类似于 DX7 级别的早期 GPU 上进行编程。过去，他通常在完成这些底层技术后，直接将代码“扔过墙”交给移动团队，由他们去构建出一款很酷的游戏。然而，由于 iOS 版的《狂怒》将是公众首次看到该 IP 实际运行的载体，公司决定让卡马克全程跟进该项目，直至其顺利出货。这导致他有几个月的时间完全无法顾及主平台项目。自该应用发布以来，卡马克表示自己再也没有碰过 Xcode 或进行过任何移动端开发，因为之前的投入确实严重超出了他原本规划的时间预算。 “从历史上看，移动端开发的工作方式是，我进去享受我的复古时刻，重新挖出如何编写软件光栅化器，或者如何在 DX7 级别的 GPU 上进行编程，然后我把代码‘扔过墙’，移动团队就会用它开发出一款很酷的游戏。” —— 约翰·卡马克 * 卡马克通常只将 10% 的时间分配给移动端和旁支项目。 * 为了确保《狂怒》iOS 版的品质，卡马克打破了时间预算，全程参与直至出货，导致数月未接触主项目。 * 自《狂怒》iOS 版发布后，卡马克因时间补偿原因未再接触 Xcode 或进行移动端开发。 --- ### [01:17:07](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4627s) 机器的亲密接触与两代程序员的对比回顾这些老旧技术让卡马克感到十分有趣。在很多情况下，凭借多年的经验积累，他的大脑在潜意识里依然在思考年轻时遇到过的那些难题。他曾尝试在短短四天内为项目手写一个软件光栅化引擎，并顺利完成了开发。这段经历让他意识到，尽管没有额外的硬件资源，他如今写出的代码确实比当年要好得多。在最近一次公司搬迁办公室的过程中，卡马克在书架上发现了一本 Commodore VIC-20 的参考手册，这本手册他从 12 岁起就一直带在身边。公司里的一位年轻员工看到后感叹道，像卡马克和罗伯特·达菲（Robert Duffy）这一代人，由于对机器的寄存器和底层细节了如指掌，拥有与机器“亲密接触”的独特感知，而年轻一代程序员可能永远无法体会到这种感觉。卡马克对此持乐观态度，他认为虽然现代开发在程序员和机器之间隔了 20 层抽象，但这正是技术进步的体现，它赋予了现代程序员极高的开发效率。 “是的，但新一代人可以在网页上把各种东西联系在一起，进行令人惊叹的数据访问，并利用现代工具和基础设施做出绝对不可思议的事情。没错，你和机器之间确实隔了 20 层‘垃圾’，但这能让你做出惊人的成就，这很好，这就是进步。” —— 约翰·卡马克 * 卡马克在搬迁办公室时，发现了一本他从 12 岁起就一直保留的 Commodore VIC-20 参考手册。 * 年轻员工认为老一代程序员对底层寄存器的掌控力是现代程序员难以企及的。 * 卡马克强调自己并非抱怨“现在的孩子不懂汇编”的固执老头，他非常认可现代多层抽象带来的高效率。 --- ### [01:18:53](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4733s) 资源受限平台的独特价值与“程序员的创意复古协会” 尽管现代设备性能强大，但卡马克认为资源约束在今天依然至关重要。在开发《狂怒》时，团队为了让游戏适应主机的硬件限制付出了巨大努力。如今的手机性能已经超越了早期的 Cray 超级计算机，虽然人们用它来处理许多平凡且低效的日常事务，但这依然是正确的演进方向。卡马克曾以为手机会长期保持资源受限的状态（例如当年为《毁灭战士 RPG》在 128KB 的限制下优化 Java 字节码），但移动端硬件的发展速度超乎想象，如今口袋里的设备已经配备了吉赫兹（GHz）级处理器和吉字节（GB）级内存，使得 128KB 的优化经验不再那么实用。尽管如此，卡马克依然认为在人为设定的极端限制下（如 64KB Demo 比赛）进行开发具有极高的教育价值。他甚至认真思考过，应该选择一款产量达数百万台的经典 32 位主机（如 PlayStation 1 或 Nintendo 64），在不面对古怪硬件的前提下，尝试在上面编写现代应用（如网页浏览器或邮件客户端）。他幽默地将这种设想称为程序员的“创意复古协会”（Society for Creative Anachronism），用古老硬件上的代码切磋来代替中世纪的泡沫剑决斗。 “我实际上花了不少时间思考这个问题，我认为正确的方法是选择一款产量达数百万台的老旧主机，比如 PS1 或任天堂 Ultra 64 级别的设备，它们是 32 位系统，你可以在上面编写真正的程序，而不需要处理极其古怪的硬件，你只需回到过去，重新审视诸如‘你如何在这个空间里编写一个网页浏览器或邮件程序’之类的问题。我想这有点像程序员的‘创意复古协会’。” —— 约翰·卡马克 * 现代手机的性能已超越 Cray 超级计算机，但由于层层低效的抽象，它们被用于处理许多平凡的日常事务。 * 卡马克曾为《毁灭战士 RPG》（Doom RPG）优化过 128KB 的 Java 字节码，但如今移动端设备已跃升至吉赫兹处理器和吉字节内存。 * 他提议让团队在闲暇时尝试为雅达利 2600（Atari 2600）开发游戏，作为一种极具教育意义的思维训练。 --- ### [01:22:08](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4928s) 团队扩张、新手培训与 Mod 社区的消逝随着 id Software 的规模不断扩大，公司在员工培训和入职引导上面临着不小的挑战。长期以来，公司的文化一直是“不沉即游”（自生自灭）——新员工入职后直接分到办公桌，拉下源码，然后被要求立刻产生生产力。虽然有些优秀的人才在这种环境下如鱼得水，迅速摸索出系统架构并写出测试用例，但这显然不是最有效率的管理方式。这种挑战在内容开发（美术和策划）方面尤为突出。许多新员工此前习惯了 Unreal Engine 等商业引擎，对 id Software 的内部技术一无所知，而公司又无法提供完善的 SDK 或市面上的商业教程。更糟糕的是，行业大趋势的变化使得 id Software 失去了过去赖以吸收人才的 MOD 社区。虽然公司计划发布《狂怒》的关卡编辑器，但这很难再掀起波澜，因为像 MegaTexture（巨型贴图）这样的技术过于庞大和复杂，普通玩家很难独自完成如此高工作量的创作。 “这真的就像是‘不沉即游’，有人被录用后，大家会说：‘好吧，这是你的办公桌，这是你获取源码的方法，现在快让自己产生生产力吧。’” —— 约翰·卡马克 ```mermaid flowchart TD accTitle: id Software 团队扩张与人才管道挑战 accDescr: 展示了 id Software 在失去 MOD 社区后，新员工入职面临的“自生自灭”困境。 A["新员工入职 (来自 Unreal 等外部引擎)"] --> B["缺乏完善 SDK 与商业书籍"] B --> C["'不沉即游' (自生自灭) 的入职模式"] D["MOD 社区衰落 (如 MegaTexture 过于复杂)"] --> E["失去高质量人才储备池"] C --> F["团队生产力爬坡缓慢"] E --> F ``` * 新员工（尤其是习惯了 Unreal Engine 的美术和策划）在进入 id Software 后，由于缺乏完善的 SDK 和商业书籍，面临极大的技术跨越鸿沟。 * 《狂怒》的关卡编辑器虽然会发布，但由于 MegaTexture 技术过于复杂，普通玩家很难制作出完整的 MOD。 * MOD 社区的衰落导致 id Software 失去了过去赖以生存的高质量人才储备池。 --- ### [01:23:53](https://www.youtube.com/watch?v=4zgYG-_ha28&t=5033s) 《毁灭战士 3》源码开源的承诺与进展在演讲的最后，卡马克宣布了一个令全场欢呼的消息：《毁灭战士 3》（Doom 3）的源代码确定将于今年（2011年）正式开源。他特别赞扬了母公司 ZeniMax 在开源态度上的开明。此前，他们通过在 iOS 上开源《毁灭战士经典版》（Doom Classic）以及释放《敌区：雷神战争》（Enemy Territory: Quake Wars）和《德军总部》的相关源码进行了试水，效果良好。不过，由于目前仍有在研项目（如高度修改版的《掠食 2》和《边缘战士》）在使用基于 idTech 4 的引擎技术，开源工作需要格外谨慎。卡马克明确表示，在《狂怒》正式发售并上架之前，他不会抽调任何程序员（哪怕是负责测试或分流的人员）来处理《毁灭战士 3》的源码整理工作。目前法务部门已经批准了这一计划，只需做好最后的细节对接。卡马克还分享了一个温馨的轶事：在去年 ZeniMax 的圣诞派对上，法务部门的一位女士特意走过来，向他表达了自己对公司坚持开源项目的支持和赞赏。 “许可已经批准，这一定会发生。我们必须确保法务部门做好所有的细节对接，但这里还有一个有趣的细节：在去年 ZeniMax 的圣诞派对上，法务部门的一位女士特意走过来对我说，她认为我们做开源是一件非常重要的事情。” —— 约翰·卡马克 * 《毁灭战士 3》的源代码确定将于 2011 年内开源。 * 由于《掠食 2》（Prey 2）和《边缘战士》（Brink）等在研或刚发布的游戏仍基于高度修改版的 idTech 4 引擎，开源工作需要谨慎处理。 * 为了不影响《狂怒》的冲刺和测试，任何程序员在《狂怒》正式发售前都不会被抽调去处理开源代码的整理工作。 ### [01:25:18](https://www.youtube.com/watch?v=4zgYG-_ha28&t=5118s) 开源传统、ZeniMax 的支持与对业界的呼吁约翰·卡马克（John Carmack）谈及母公司 ZeniMax Media 及其法务部门对开源经典代码的态度时，流露出由衷的惊喜与欣慰。他笑着回忆道，当法务部门的律师们也认为开源代码是一件好事时，他甚至惊讶得愣了一下，而 ZeniMax 展现出的全力支持让他备受鼓舞。卡马克借此机会直接向整个游戏软件行业发起呼吁，认为许多老牌开发商完全可以效仿这一做法，公开那些具有里程碑意义的经典老代码。这些代码不仅能赢得玩家社区的喝彩，更能成为年轻程序员汲取经验的绝佳学习资料，为整个生态带来全方位的长远益处。回顾 id Software 当初确立开源策略的历程，卡马克承认早年团队内部曾充满分歧与争辩。当时有人质疑公司是否拱手送出了太多商业机密，或者会不会在无形中资助、扶持了潜在的竞争对手。但时至今日，历史已经给出了明确的答案——开源不仅没有削弱公司，反而铸就了 id Software 极其宝贵的文化与技术遗产。正如卡马克所强调的：“There's no doubt at this point that the legacy of of the open source software has been a really good thing for id and I I'm really happy that we're able to kind of continue that going forward.” 在演讲的尾声，卡马克提到了数字发行带来的便利性。在以往的年代，每次 id Software 公布底层源代码，爱好者如果手头没有原版光盘，往往必须大费周章地去实体店的打折处理箱里翻找老游戏数据；而如今随着 Steam 特惠的普及，任何人都能轻松在线购买《毁灭战士3》（Doom 3）的数据资源，并立即着手编译和把玩引擎代码。在一片轻松掌声中，卡马克以一句真挚的感谢结束了本届 QuakeCon 的主题演讲。 - **法务支持与行业倡议**：ZeniMax 积极支持开源老代码，卡马克公开挑战其他软件厂商，呼吁大家向社区开放早期的经典技术资产。 - **开源遗产的正向回报**：彻底打消了早年关于“泄露技术优势、资助竞争对手”的顾虑，开源已成为 id Software 品牌最坚实的技术声誉来源。 - **获取数据的便利演进**：对比昔日在旧货箱中翻找实体光盘的窘境，Steam 等数字分发平台极大降低了开发者上手研究《毁灭战士3》开源引擎的门槛。 ## Notable quotes > [01:12:37](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4357s) I don't spend a lot of time thinking about the good old days because the good old days are right now. — John Carmack > [01:09:44](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4184s) No matter how good you think you are, you are making mistakes all the time, and you have to have structures around you to try and help you limit the damage that your mistakes will cause. — John Carmack > [01:02:43](https://www.youtube.com/watch?v=4zgYG-_ha28&t=3763s) 如果你还得向我专门解释这段逻辑，也许你该做的是改写这部分代码。 — John Carmack > [01:06:54](https://www.youtube.com/watch?v=4zgYG-_ha28&t=4014s) One of the big lessons of a big project is you don't want people that aren't really programmers programming, you'll suffer for it. — John Carmack > [34:51](https://www.youtube.com/watch?v=4zgYG-_ha28&t=2091s) 冷酷无情的事实是，id Software 本部主线上产出的每一款游戏，其研发耗时都比前作更长，而这种情况是绝对不能继续下去了。 — John Carmack > [01:25:18](https://www.youtube.com/watch?v=4zgYG-_ha28&t=5118s) There's no doubt at this point that the legacy of of the open source software has been a really good thing for id and I I'm really happy that we're able to kind of continue that going forward. — John Carmack ## Mentioned John Carmack, id Software, RAGE, MegaTexture, Tim Willits, Matt Hooper, Robert Duffy, Xbox 360, PlayStation 3, PC, OpenGL, DirectX, Microsoft, Sony, Bethesda, ZeniMax Media, NVIDIA, AMD, Intel, Splash Damage, Enemy Territory: QUAKE Wars, Doom, Doom 3, Doom 4, Doom RPG, Doom Classic, Quake, Quake III Arena, GLQuake, Prey 2, Brink, The Elder Scrolls V: Skyrim, Coverity, PVS-Studio, PC-lint, Visual Studio, Atari 2600, Commodore VIC-20, PlayStation 1, Nintendo 64, Cray, Unreal Engine, Steam, iOS, Xcode ## Video description As tradition goes, id's co-founder and technical director, John Carmack, kicks things off with his keynote address. [Source](https://www.youtube.com/watch?v=4zgYG-_ha28)

Source quotes

[72:37] John Carmack: I don't spend a lot of time thinking about the good old days because the good old days are right now. [69:44] John Carmack: No matter how good you think you are, you are making mistakes all the time, and you have to have structures around you to try and help you limit the damage that your mistakes will cause. [62:43] John Carmack: 如果你还得向我专门解释这段逻辑，也许你该做的是改写这部分代码。 [66:54] John Carmack: One of the big lessons of a big project is you don't want people that aren't really programmers programming, you'll suffer for it. [34:51] John Carmack: 冷酷无情的事实是，id Software 本部主线上产出的每一款游戏，其研发耗时都比前作更长，而这种情况是绝对不能继续下去了。 [85:18] John Carmack: There's no doubt at this point that the legacy of of the open source software has been a really good thing for id and I I'm really happy that we're able to kind of continue that going forward.

Source quotes

[66:54] John Carmack: You know, one of the big lessons of a big project is you don't want people that aren't really programmers programming; you'll suffer for it. [36:35] John Carmack: The cold hard truth is every game that we've done that's come out of id Software proper on our mainstream mainline has taken longer than the game before, and that cannot continue. [62:43] John Carmack: If the analyzer can't figure it out, other programmers probably won't immediately figure it out and it will cause problems. [58:01] John Carmack: I'll say this quite clearly with no hesitation: any 360 developers that are listening to this, if you're not using /analyze, you are making a mistake. [36:35] John Carmack: I've said for years now that I think that we are past the knee of the curve in terms of what we get from graphics technology on there. [72:37] John Carmack: I'm really a remarkably unsentimental person; I don't spend a lot of time thinking about the good old days, because I see this a lot: the good old days are right now. [31:12] John Carmack: For a lot of things abstraction is great you want to be able to step back and say here we're doing one thing we wanted to behave just with slightly varying characteristics but when you're doing really aggressive realtime operations sometimes those abstractions will really kill you. [85:18] John Carmack: There's no doubt at this point that the legacy of of the open source software has been a really good thing for id and I'm really happy that we're able to kind of continue that going forward.

Original transcript

[0:02] [Applause] [0:06] [Music] [0:12] please give a huge round of applause to [0:14] John [0:18] [Applause] [0:18] [Music] [0:21] carac good luck thank [0:23] [Music] [0:28] you [0:30] all right it is really great to be here [0:32] this year it's been so many years where [0:35] we talk about what we're working on what [0:37] we're doing what we're thinking about [0:39] and actually have it now where you can [0:40] go over and play rage what we've spent [0:42] six years working on and if uh if you've [0:45] seen me I've been spending a lot of time [0:47] over there just watching people play [0:48] generally with a big old grin on my face [0:51] where we had so much that we set out to [0:53] do on this that was different than what [0:54] we had done before I mean ID had been [0:57] almost a a stereotype of what you do [0:59] first person shooter runand gun [1:01] corridors monsters jumping out at you [1:03] this type of thing that we invented this [1:05] genre and we followed it for a long ways [1:08] but people thought that was what you [1:10] know that was all that we were doing and [1:11] with rage we set out to be really pretty [1:14] ambitious to do a lot of things that we [1:16] had never done before and in hindsight [1:17] knowing that it took six years we would [1:19] look back and say maybe we shouldn't [1:21] have been quite as ambitious maybe we [1:23] should have you know done a few more of [1:25] the things that we already had plenty of [1:26] experience doing but in the end [1:28] everybody gets the benefit F of you know [1:30] we picked hard battles we fought through [1:32] all of them and in the end I think we [1:34] did a really damn good job on it where [1:37] the things that we set out to do yeah [1:49] thanks and it's kind of a tough [1:51] situation here where we've got thousands [1:53] of people here and we've got a couple [1:55] dozen stations that people can play on [1:57] over there on the one hand I would like [1:59] everybody to get a taste of the game to [2:00] sit down and just jump in and see how it [2:02] feels kind of experience the the high [2:04] frame rate and the smooth interactions [2:06] and all this stuff but I also want to [2:08] see the game is so much more than the [2:10] sum of its parts where every level is [2:12] fun you can jump on I think they've got [2:14] the dev menus there you can pick any [2:15] level jump into it and kind of blast [2:17] your way through it and have a good time [2:19] but you really don't get the sense of [2:21] what the game's about unless you sit [2:22] down and really spend hours with it and [2:25] it was great this last press set of [2:27] things that we did a couple weeks ago [2:29] where we had them sit down for 3 hours [2:31] and you start the game you play for 3 [2:33] hours and you're really only breaking [2:34] into sort of the meat of the game by [2:36] that point you've been introduced to the [2:38] things that are there the stuff that you [2:39] can do and you're finally opening up [2:41] that's the point where the world opens [2:43] up to you and you can see all these [2:45] other things that you can do and it was [2:47] you know it's great to find these places [2:49] where you've got people where like okay [2:50] time to go you need to be leaving like [2:52] one minute one minute you know staying [2:54] on the game so uh I'm hoping that a few [2:56] people will basically Camp some of the [2:58] stations over there and you know run [2:59] your way through the whole game tag team [3:01] through it and see all the awesome stuff [3:04] in there where like the new trailer uh [3:06] shows a bunch of things that you really [3:07] only get to on the second DVD sort of [3:09] the second half of the game and there is [3:11] so much there um it's it really is [3:15] probably the most enjoyable GID game [3:18] from my perspective that we've ever made [3:21] I you know I've played all of our games [3:23] to degrees but I was never one of the [3:25] people that could spend eight hours like [3:27] death matching you know I know there's a [3:28] lot of you out there but that was never [3:31] I kind of like my take on our games but [3:33] the pacing on rage allows us to go ahead [3:36] and have a game where you have moments [3:38] of abject Terror and intensity and it's [3:41] it's nicely balanced by the areas where [3:43] you're going through you're exploring or [3:45] you're talking in town doing these [3:46] things and we learned a lot through this [3:49] process and by no means are we ready to [3:51] be stood up next to Skyrim or something [3:53] as an adventure game and that's not what [3:54] we're doing but there it is clear at [3:58] this point that there are benefit IAL [4:00] things that we can add to the gameplay [4:01] experience where we take everything that [4:03] was fun and good about classic ID games [4:06] and you can do these other things that [4:07] that add additional layers to it that [4:09] don't take anything away there are a lot [4:12] of design choices where you have to make [4:13] fundamental decisions are you this type [4:15] of game or are you this type of game if [4:17] you do this you're going to annoy some [4:18] of these other people uh but there are [4:21] also some things that are just pure wins [4:22] where you can add this on people can [4:24] ignore it or they can they can go ahead [4:26] and dive into it and get a lot more out [4:28] of it um you know there are there are [4:31] lots of aspects to the game that I I [4:34] have to I have to caution myself when I [4:37] do this because I'm tempted to go all [4:38] postmortem on the game at this point and [4:40] say look over as an engineer I'm like oh [4:43] this could have been better we should [4:44] have done this this way we can make this [4:46] so much better you know we can improve [4:47] this in the future but in the end we hit [4:50] everything we really set out to do with [4:52] the with the game it took a lot longer [4:54] than we expected but everything that we [4:56] kind of envisioned pretty much made it [4:58] into the game and and from my point of [5:00] view the game has so many things in it [5:02] that I certainly didn't imagine when we [5:05] started off or even early you know even [5:07] three years ago and that's been that's [5:09] always the most rewarding part as a [5:11] technical director for me is I have a an [5:14] idea of what the platform that we're [5:16] creating will let people do but when the [5:18] artists and the designers get in and [5:20] they build some of these just [5:21] magnificent things I you know it's in [5:25] many ways as much of a shock to me as it [5:26] is to everybody else playing the game [5:28] you know I don't have [5:30] you know I don't have that resolution of [5:32] imagination that the artist can do where [5:35] they can build these worlds that are [5:36] just so fabulous and the game you know [5:39] when I'm playing the game you can be [5:40] into the game having such a a great time [5:42] running through it blasting at things [5:44] but practically anywhere you can stop [5:47] look around and just soak in that the [5:49] world it's like it's a one of the uh [5:51] depressed people called it a moving [5:52] painting and I really like that where [5:54] you can you can stop and see and how the [5:56] artists and the Stampers practically [5:58] every area it's not just the showpiece [6:01] room that you make the screenshot for [6:02] for the back of the box but we have [6:05] terabytes of data that are just gone [6:07] through plastered with all this [6:08] tenderloving care throughout the game [6:10] and there's some really fabulously [6:12] beautiful areas in it that are that are [6:14] really rewarding to look at and it [6:17] doesn't the core technical decision [6:20] that's gone into all of this and I [6:22] always hesitate to to make too much of [6:24] this because people like to latch on to [6:26] it but the the megatexture technology is [6:28] the signature thing that [6:30] that people latch on to as the [6:31] differentiation but it's important to [6:33] realize that that is you know it's maybe [6:36] 10% of the code which is maybe 25% of [6:40] the effort that goes into the game so [6:41] it's this tiny tiny part but it is the [6:44] thing that makes the game standout where [6:46] it gives it its super high performance [6:48] on the console generation of hardware [6:50] and it gives it the kind of painterly [6:52] look at things but it's I I will spend [6:55] some time going over some of the details [6:57] and the tradeoffs on there because we [7:00] had to make conscious choices on that it [7:02] got us what we wanted in the end it got [7:04] us this moving painting at 60 frames per [7:06] second with this evocative art style [7:08] through everything but we did have to [7:10] make some significant sacrifices and [7:13] overcome a lot of challenges to actually [7:15] make that happen uh sometimes I look at [7:18] it and say it's clearly the most [7:20] sophisticated part of the code again [7:21] there's millions of lines of code in the [7:24] software code base now and you know only [7:26] tens of thousands of them are sort of [7:28] directly related to this but it is [7:31] dismayingly complicated in many ways all [7:34] the things that we had to go through to [7:36] make this vision of this painted world [7:39] happen uh when you you know after this [7:41] you'll all be Mega texture experts and [7:43] you can point out the flaws and details [7:44] of of this when you're looking at the [7:46] games uh but there's performance [7:49] characteristics that impact the game uh [7:51] the versions that are playing over there [7:53] are either PC or 360 installed to the [7:56] hard drive U so this is sort of the the [7:58] good case performance performance for [8:00] streaming in all the data uh there's a [8:02] spectrum of behavior that you can expect [8:04] where the worst behavior that you'll get [8:07] is if you take a DVD on a 360 without [8:10] any hard drive which means that every [8:12] texture that you pull in has to come in [8:15] off of the DVD uh we do a bunch of smart [8:18] stuff to go ahead and know where all the [8:19] textures are schedule all the reads [8:21] batch them up try and read linearly but [8:24] the bottom line is still that you want a [8:26] new piece of texture data on there and [8:28] it can take I you know 150 milliseconds [8:31] in a bad case or something to go pull [8:33] that in and the screen might be made up [8:35] of you know a thousand different little [8:37] pieces so in the worst case it can take [8:40] 15 seconds for every last little bit of [8:42] detail to come in and I know we're going [8:44] to get dinged some by that there are [8:46] going to be people that I you know that [8:48] run up and uh if you want the the recipe [8:51] to make it look as bad as possible it's [8:53] uh kind of back your way into something [8:55] with a high sensitivity you know walk [8:57] around backwards through town then flip [8:59] around and look at something that you [9:00] haven't had any chance to do and it [9:02] it'll come in it'll be blurry and it'll [9:03] come in work its way in and that's just [9:06] the the reality of the way the [9:07] technology works that we have to to deal [9:09] with but we do an awful lot of work to [9:12] try and make this not an issue and the [9:14] great thing is that when you sit back [9:16] and you know you watch uh I'm having a [9:18] great time over there looking at a dozen [9:20] screens playing rage and you look at it [9:22] and it looks great and I catch myself [9:24] doing this even at the office where I'm [9:26] sitting at my desk with Visual Studio on [9:28] one side and the game on the other and [9:30] I'm looking at something and twiddling [9:32] the controller and I'm thinking to [9:33] myself oh this looks awful can't we do [9:35] better at making something here getting [9:38] this in better scheduling this putting [9:39] some hint in on that and you know I can [9:43] like like any good engineer I can almost [9:44] depress myself about how much more we [9:46] can do to make things better in the [9:48] future but then when I look at people [9:50] playing the game just even in the office [9:52] running around doing the the testing [9:53] duties or whatever you know I'm back to [9:56] okay that looks great I'm really [9:58] thrilled to see it running that good see [9:59] it behaving that way and it's you know [10:02] it's always a set of tradeoffs in [10:04] engineering where we you know we made [10:06] these conscious decisions that we would [10:09] live with some degree of textures coming [10:11] in to give us this this painterly world [10:13] we would give up on uh completely [10:16] general purpose Dynamic [10:21] lighting [10:23] okay bug in the [10:28] mic we have a report of a bug in the [10:30] microphone system so we'll see if this [10:32] is [10:32] better so um aside from the actual the [10:36] raw nature of it as far as bringing the [10:39] the textures in in these little pieces [10:41] the code that does this is certainly the [10:43] most intertwine sophisticated and highly [10:46] optimized code in the engine where [10:49] there's actually up to four levels of [10:51] locality for how these textures come in [10:54] at the uh at the closest level to the [10:56] hardware everything is broken up into [10:58] the these little blocks of textures i [11:01] instead of being one wall That's 2,000 [11:03] by 1,000 and a coffee cup that's 128 by [11:06] 128 everything is uniformly divided up [11:09] into pages of textures you 128 by 128 [11:12] blocks and it's interesting how this has [11:14] gone from five years ago when I first [11:17] sort of did this technology originally I [11:19] did something for Splash damage for [11:21] enemy territory and then I generalized [11:23] it for our early work in [11:25] Rage we ran the numbers and we looked at [11:28] it and said well okay this current [11:29] generation of Hardware you can have [11:31] textures that are 4,096 by 4,096 so we [11:35] break that up into you know 1,000 128 by [11:38] 128 pages and that should be able to [11:40] cover everything that we want to do [11:42] where you know you've got about a [11:44] million pixels on the screen and 16 [11:45] million pixels there 16x should be [11:48] sufficient margin for us and in the [11:51] early things that we did like the the [11:53] many years ago demos of the dusty 8 [11:55] racetrack where you run around um it's [11:58] reasonably confined area all that was [12:00] working quite well it seemed that um we [12:03] had the numbers it was going pretty [12:05] quickly um all the data set seemed to [12:07] fit and uh and it looked like the [12:10] technology was going to settle down [12:11] reasonably quickly we had sets of [12:13] optimizations that we had to do but one [12:15] of the the somewhat fateful things that [12:19] happened uh a little bit after that and [12:21] Tim and Matt Still uh rib me a little [12:24] bit about this where the artist started [12:26] designing things that weren't these sort [12:28] of big deformed facades uh which is the [12:31] most comfortable thing for the [12:32] technology like if you if you want this [12:34] megatexture stuff to work great work [12:36] efficiently you take sort of a a big [12:38] sheet and push it around something so [12:40] that you've got uh one we call it a [12:42] texture Island one contiguous area of [12:45] textures on there and it's super [12:46] efficient at doing that it works really [12:48] well runs extremely fast but the artist [12:51] started building some really impressive [12:53] scenes using different construction [12:55] techniques where they would build all [12:57] these little modular Lego pieces and [12:59] throw them together and then instead of [13:01] having this great big sort of terrain [13:04] mesh of things built up into building [13:06] facades we have thousands and thousands [13:09] of disconnected little pieces of [13:10] textures and we're like okay we can we [13:13] can deal with this we'll Lay Them All [13:15] Out crunch them together and see what we [13:16] get out of this and it was starting to [13:19] look a lot more challenging and the the [13:22] designers were beginning to say well we [13:24] need some guidelines and some limits I [13:27] you know how many what can we do tell us [13:29] what our gu our guidelines are and as a [13:31] programmer that's always a really hard [13:33] thing to have a designer come up and say [13:34] because the answer is it's really [13:36] complicated I you know you can have a [13:38] lot of triangles here if I you know if [13:40] you don't have a lot of Dynamics and you [13:42] can trade off like your overdraw with [13:44] your particles against uh you know your [13:46] texture load here if you flatten all of [13:48] this out you can have a ton of triangles [13:50] and you know I would go on like this and [13:52] everybody's like give us a number um and [13:55] I I hemmed and haw and I really made a [13:58] really bad call and I said well you know [14:00] I want to be pushed a little bit so go [14:02] you know go make really cool stuff and [14:04] we'll figure it out and I you know and [14:08] and in the end we we pretty much did but [14:10] there is a whole lot of hard work buried [14:13] in uh making all of that stuff actually [14:16] work um to get back to the the kind of [14:19] layers of complexity on all of this so [14:22] at the top level we've got this 4K by 4K [14:26] page of textures all broken up into [14:27] little blocks and those are all puzzle [14:30] piece fit around on the screen and PC [14:32] guys will be able to you know you'll be [14:35] able to bring down the console and turn [14:36] all the little debug tools and peek at [14:38] how these textures are actually broken [14:40] up uh it pains me a lot that the that [14:43] Microsoft and Sony completely disallow [14:45] the ability to plug in a keyboard and [14:48] you know and tweak with things it's it's [14:49] even a pain for us in development that [14:51] our full retail builds we can't bring [14:53] down and play with debug tools and I [14:55] think that's that's unfortunate into to [14:57] not any particularly good benefit um but [15:01] as it is only PC people get to tweak [15:02] around with with that stuff but so on I [15:07] yeah I'll [15:12] get so at its best the areas like five [15:16] years ago I was thinking things would [15:18] turn out if you're in the Wasteland and [15:19] you're in a canyon and it's you know [15:22] you've got the cool sunlet stuff up [15:24] there if you look at it you can kind of [15:26] look around and say okay I've got this [15:28] wall here I've got my 80° field of view [15:31] I can look around and pretty much your [15:33] entire view you could turn 360° and all [15:36] of that fits in that sort of 4K by 4K [15:39] set of pages so once they're loaded in [15:41] you flip around and everything looks [15:43] great all the time uh it runs into more [15:45] problems when you get into these really [15:47] sophisticated scenes where the thing [15:50] that hurts us if you've got the floor [15:52] underneath you you can clearly see this [15:54] is broken up okay 128 pixels this block [15:57] here this takes up this much memory [15:59] everything's great what's a problem is [16:01] when you look at this awesome set piece [16:03] over there and you've got all these tiny [16:05] little things where there's no page the [16:08] minimum page size is this block of 128 [16:11] by 128 pixels if you've got a railing [16:13] that occupies one pixel on the screen [16:15] you may still need a full page wrapped [16:18] around that even if you're only seeing [16:19] one slice of it uh we do our best to go [16:22] ahead and pack things in nearby and I [16:25] you know and try to to minimize complete [16:28] wastage like that but it also gives us [16:29] some false sharing and limits what we [16:31] can do with anisotropic filtering and [16:33] all of these things so the bottom line [16:35] is it turns out that the single 4K by 4K [16:38] page wasn't nearly enough and on the PC [16:41] you just crank it up and you say well [16:42] I'm going to use 8K by 8K Pages because [16:45] all the video cards are you know have [16:46] plenty of memory now and that's what you [16:48] do and we built a lot of the game like [16:50] that and then when we're like okay now [16:52] it needs to actually work on the 360 and [16:54] the PS3 and people start looking it's [16:57] like oh this is like it's half the [16:59] detail that it was on the PC this is [17:01] missing myip levels and all that and we [17:03] go through this process of saying well [17:05] uh the 360 can actually support an 8K by [17:08] 8K texture we wouldn't really have [17:10] enough RAM to do that but if I was left [17:12] my own on that we'd allocate that space [17:14] and then overlay other things in the the [17:16] parts of the texture we're not using all [17:18] that great stuff you can't do on PCS [17:20] because you're at too much of a distance [17:21] from the hardware but the PS3 uh doesn't [17:24] even have that capability at all so [17:26] you're stuck with these odd Notions of [17:29] well do we try and put them in a cube [17:31] map so we can have six sides maybe a six [17:33] side 2K by 2K but the addressing on that [17:36] would be a huge pain do we try using a [17:38] 3D texture with multiple slices but then [17:40] the performance Goes to Hell on there [17:43] and we wound up with multiple [17:45] independent images where we start off [17:47] with this this wonderful beautiful [17:49] elegant virtualized system everything [17:51] flows into all of this multiple pages [17:53] and it's nice and clean and sounds good [17:56] and we wind up with three different page [17:58] images of different sizes and different [18:00] depth complexities and uh some of them [18:02] have uh just one dxt image some of them [18:05] have three uh the Vim uh the virtual [18:07] materials on the dynamic things are [18:09] handled separately so all of this [18:11] complexity comes in when you go from [18:13] kind of the initial cool elegant demo of [18:16] something to getting it through [18:18] delivering what your artistan designers [18:20] want and getting it out onto a shipping [18:22] project so lots and lots of work went [18:25] into doing that about making this thing [18:27] that originally was not that complicated [18:30] uh the initial you know it was only a [18:33] small number of days to do the first [18:34] sort of virtualization of texturing and [18:37] you know a few weeks to a few months to [18:39] get something where like okay look this [18:40] level's running with virtual textures it [18:42] doesn't load anything at the start but [18:44] it's taking years and years to get to [18:46] the point where we have all the [18:49] capabilities that we really want so here [18:53] we are at the point with all these [18:54] broken up Little Tex little uh texture [18:57] blocks on there if we loaded them [18:59] directly from the DVD or even the hard [19:01] drive at that point you would have a [19:03] significant lag you'd be going around [19:06] every time you turned a little bit it [19:07] would have to bring in a whole row of [19:09] pages and that doesn't work particularly [19:12] well we started off on the PC with that [19:14] where if you have a ton of memory and [19:17] you look at everything once after you've [19:18] gone through it it stays sort of in your [19:20] buffer cache and that's not too terribly [19:22] bad but on the consoles we had to manage [19:25] everything ourselves so we have our own [19:28] second layer cache that sucks up pretty [19:30] much all the available memory in the [19:32] consoles where we load in the stuff that [19:34] we need and then every bit of extra [19:35] memory is available for caching this uh [19:38] we wound up also using that for audio [19:40] caching so uh if something's present in [19:44] there if you've got lots of memory then [19:46] it comes back in super fast it has to go [19:48] through the transcode pipeline but uh a [19:51] lot of the instance Maps if you're [19:53] playing things that aren't the Wasteland [19:55] we've got quite a bit of memory that [19:57] fills it up and once you've sort of [19:58] looked at something it stays in their [20:00] resident and comes in really quickly but [20:03] the Wasteland was our real push case on [20:05] here where it was hard to just get that [20:07] to fit at all on the consoles and we [20:10] don't have nearly as much stream file [20:12] cache as we would like and this is an [20:14] area where uh the PS3 has a good bit [20:18] less memory available than the 360 [20:20] because it's got a split memory space [20:23] where instead of saying well you use as [20:25] much textures as you want and the rest [20:26] of it's available for other things you [20:28] say half of it is available for graphics [20:30] and half of it is available for CPU [20:33] stuff which turns out not to be that bad [20:35] for us because we almost completely on [20:37] our high memory case Max that out so it [20:40] didn't hurt too much but their operating [20:42] system takes uh a good chunk of extra [20:44] memory that we wish that we could use [20:46] for stream file cache on there but still [20:49] once you got everything in memory that [20:51] works pretty good but if you're coming [20:53] straight from the hard drive then the [20:55] first time you walk into everything [20:56] you're or from the DV worst case or [20:59] Blu-ray even worse in terms of uh total [21:01] latency time um you know you're stuck [21:04] with this very long have to go it's it's [21:08] the epitome of the physical action going [21:10] on in here where so much of this is just [21:12] ethereal software shoving things around [21:14] but you listen to that Blu-ray turning [21:16] around as it seeks around pulling [21:17] everything in like it'll be nice when we [21:19] don't have that little physical element [21:21] that we have to be scheduling for and [21:22] working around so to avoid the worst [21:26] cases in that we added another level of [21:29] caching where we have a hard drive [21:31] backing cache where the first time you [21:33] look at something it takes the long trip [21:35] in from the DVD or the Blu-ray then it [21:37] gets written back out to a fast area on [21:40] the hard drive so we can bring it back [21:42] in the next time from the hard drive [21:44] instead of from the DVD so it's sitting [21:46] in the Stream file cache then eventually [21:47] it gets transcoded and put onto the [21:50] actual texture that the GPU touches that [21:52] then puts it onto the screen so four [21:55] levels of locality there before it gets [21:57] to the screen Optical media hard drive [21:59] backing cache uh stream file cache [22:02] texture and it gets yet more complicated [22:06] by the fact that on systems that do have [22:08] a hard drive on the PS3 and uh in [22:11] particular we get to install some of our [22:14] textures to the hard drive on the 360 we [22:17] don't have a partial install option It's [22:18] All or Nothing which is kind of [22:20] unfortunate which means you have to [22:21] install 21 22 gigs of stuff which takes [22:24] a long time but if you've got it and [22:26] you're going to play it on a 3 that's [22:28] the way to go it makes a significant [22:30] difference everything comes in without [22:32] having to hit Optical [22:33] media uh on the PS3 we install some of [22:36] the important things on there and we're [22:38] still negotiating with Sony on exactly [22:40] how much space that we can take um so [22:43] bethesda's kind of trying to twist arms [22:45] to say it's like well you can give us a [22:46] couple more gigs because we'll be able [22:48] to then stick this other page file on [22:50] here and that'll be uh you know that'll [22:51] make that part of the experience that [22:53] much better uh to start touching on one [22:56] of the if only we had a little bit more [22:57] more timer had worked on it earlier the [23:00] better solution for that would have been [23:02] to split our page files and say okay all [23:05] of the low detail stuff goes onto the [23:07] hard drive cache and then all the high [23:09] detail stuff stays on the Blu-ray uh [23:12] possibly backed by the the temporary [23:14] hard drive cache because then you would [23:16] never have the you know the grotesquely [23:17] ugly cases where you just like oh you [23:19] know what is that blurry mess for a [23:22] quarter second that you can get when [23:24] it's coming straight from Optical media [23:26] but that's I again it's the most [23:28] sophisticated code in there and to some [23:30] degree we cringe a little bit every time [23:32] we we try to implement some new feature [23:34] in there because it is uh it's at the [23:36] heart of the most asynchronous threads [23:39] you know all the different devices [23:41] there's one thread that's dealing with [23:42] reading from the DVD one thread reading [23:44] from the the hard drive there's [23:46] additional threads doing the analysis of [23:48] the feedback buffer to figure out what [23:50] it needs to do then there's a bunch of [23:52] threads doing the transcoding where it [23:54] comes in if we had Infinite Space I we [23:58] would have just stored everything out [23:59] directly as it was going to go into the [24:00] texture you know that would have been [24:02] great you could do an unbuffered read [24:03] directly off of the file directly into [24:05] the texture and the GPU could be using [24:07] it immediately but unfortunately that [24:10] would have meant that the game would [24:11] have been either less than half the [24:13] current size or you know you don't want [24:15] a deck of eight DVDs to play a game [24:17] there uh and that's sort of the data set [24:19] that we would be looking at there so we [24:22] have on uh on distribution media [24:25] everything is compressed using an HD [24:27] photo uh derivative on there and we [24:29] actually Microsoft gave us a license to [24:31] use uh stuff derived from their uh their [24:34] code base for that which I which was a [24:37] really good thing on there we were we [24:39] had our own DCT based version but it [24:42] just was this significant 30% or more [24:45] not as good as what we could get from [24:47] there so 30% of the quality that we were [24:49] able to pack onto there onto the [24:51] existing discs uh is due to having a [24:54] more sophisticated encoding method but [24:56] of course that also means it takes twice [24:58] the processing power to do that so we [25:00] have all this work where we bring this [25:02] in comes in in this HD photo derivative [25:05] gets sent out to a whole bunch of [25:06] threads decompressed to a you know ycg [25:09] color space on there but then we have to [25:11] recompress it and re-encode it to dxt [25:14] for the uh for the actual video cards on [25:17] there and that's one of the things that [25:18] there's a number of things that we may [25:20] get to do on future PC releases for [25:23] potential higher quality uh I'm hoping [25:26] that uh the PC version will will Street [25:29] the same time the other versions but [25:31] because it's a i it's a steam release on [25:33] that we get to work on the PC version [25:35] longer so we're hoping to get uh a good [25:38] bit more tuning in on that before we [25:40] finally get it out and it is extremely [25:42] frustrating knowing that the hardware [25:45] that we've got on the PC is often 10 [25:47] times as powerful as the consoles but [25:49] it's honestly been a struggle in many [25:51] cases to get the game running 60 frames [25:54] per second on the PC like it does on a [25:56] 360 uh you know a lot of its driver [25:59] overhead issues where there's so much [26:02] that we do in the game that all of this [26:04] Dynamic texture updating where on the [26:07] console we say all right we've got a new [26:09] page of data we put that page in there [26:11] and then we update the page table that [26:12] points to that and on the console that [26:15] may just be a matter of writing an INT [26:18] to a memory it's like here's the texture [26:20] let's calculate exactly where this part [26:21] of the page table is and then we just [26:23] poke it right in there on the PC that [26:26] turns into you know potentially a text [26:29] sub image 2D and if you're a programmer [26:32] and you start single stepping through [26:33] that you'll cry you won't make it back [26:35] out it'll just take forever it'll be [26:38] going in there and that's where we're [26:39] looking at that on the console we just [26:41] we put the memory in there we just [26:43] that's what it is that's where it goes [26:45] and we stick it there uh you know and [26:48] there's reasons why PCS are like that [26:51] they have to work with very different [26:52] memory architectures you know the tiling [26:54] and swizzling formats are different [26:56] between them uh [26:58] but we may be seeing some light at the [27:00] end of that tunnel where there have been [27:02] enough kind of hints from the relevant [27:04] vendors that maybe it is time to start [27:07] standardizing on some inmemory footprint [27:09] and formats so that PCS can be a little [27:12] bit more efficient at some of this and [27:14] especially we're leaning on Intel where [27:17] I Intel's current Graphics Hardware is [27:20] getting decent uh you know it's not [27:23] going to you know it's not going to be a [27:25] I mean this is the embedded Hardware [27:26] that everybody has just dismissed you've [27:28] forgotten you had it in your uh in your [27:30] systems because you went out and you [27:31] bought a serious uh you know Nvidia or [27:34] AMD video card on there but I you know [27:38] it's been there for running people's [27:40] word apps and whatever for a long time [27:42] but each generation it gets better and [27:45] at the current generation we have rage [27:47] running on the Intel Hardware now it's [27:50] not 60 frames per second yet but we're [27:52] looking at this as it's not yeah people [27:54] still laugh when Intel hard uh [27:56] integrated graphics comes up but it's [27:58] not going to be long before you are [28:00] really going to be able to actually use [28:02] that and I know that's I you know that's [28:04] certainly making the the dedicated video [28:06] card manufacturers a little bit antsy on [28:09] some level because there's clear Trends [28:11] going on there but the important aspect [28:13] from that is because it's an integrated [28:14] memory part unified memory there's no [28:17] reason that it shouldn't be like a [28:18] console it's all in one same set of [28:21] memory I should be able to get the [28:22] address of that texture I should be able [28:24] to get the stride and the Swizzle format [28:27] and say all right I want my texture [28:29] update I'm just going to go push it in [28:31] there and we have sort of notional buyin [28:34] from Intel that this is a good direction [28:35] I mean oldtime graphics people still um [28:39] you know they cringe at the idea of [28:40] exposing internal formats uh there's you [28:43] know long culture of being able to do [28:45] things behind people's back that really [28:47] has led to a lot of grief in the PC [28:49] graphics industry the fact that I you [28:52] know direct X sort of pretended you [28:53] could lock a rectangle of an image but [28:56] what happened in most cases what behind [28:58] was behind your back drivers were like [29:00] copying the whole texture in and out re [29:02] swizzling it pretending it was like this [29:03] for you and then doing the inverse to [29:05] put it back into video memory and that's [29:07] where it's a leaky abstraction it's [29:10] where we're trying to pretend that all [29:12] these Graphics Hardware behaves in a [29:14] certain way when they really don't and [29:17] for a lot of things abstraction is great [29:18] you want to be able to step back and say [29:21] here we're doing one thing we wanted to [29:23] behave just with slightly varying [29:25] characteristics but when you're doing [29:27] really aggressive realtime operations [29:30] sometimes those abstractions will really [29:31] kill you and it's I you know it's [29:34] happened to us over and over again where [29:36] we take something it's working fine on [29:37] the consoles uh there are these open [29:39] questions of well do you want to use [29:41] parameter buffers texture reads all [29:43] these different possible ways that you [29:45] might go about doing it and I can look [29:47] at a a hardware reference manual and say [29:49] well it should be able to just dma fetch [29:51] the stuff in like this that should be [29:52] able to be poked in here um but often [29:55] they have to go through incredibly [29:57] convoluted things in the driver to work [30:00] around that and there's good reasons why [30:03] that stuff happens I mean one of the [30:05] things that I you know that I'm to blame [30:07] for that I I regret a lot is there are I [30:11] there are hacks in all current Graphics [30:13] drivers to identify whether you're [30:15] playing early versions of Quake because [30:17] I did things like uh when I was getting [30:19] the extension string I just had a buffer [30:22] of like oh you know a thousand [30:24] characters should be enough for all the [30:26] extensions and we do a you know copy a g [30:29] get string into there and of course as [30:31] drivers got to the point where they had [30:33] tens of thousands of characters of [30:35] extension strings that would just Stomp [30:37] all over memory and they went in behind [30:40] our backs to our benefit and said well [30:42] if we identify that you're playing this [30:44] game we're just not going to do this [30:45] we'll do this other thing we'll give you [30:47] a shortened list that you know that fits [30:49] what you're expecting so there's reasons [30:51] there's archaeological reasons why PC [30:54] drivers have a lot of the stuff that [30:55] they do but it is is very unfortunate [30:58] that they have to rely on such an [31:00] overwhelming amount of Brute Force to I [31:03] you know to overcome the console's [31:05] low-level Advantage there but again [31:08] there's there's signs that things may be [31:10] getting a little bit better there uh I'm [31:12] hoping that we will have just like to [31:15] speak to another success point on here [31:17] uh it is kind of nice only having uh [31:21] sort of three relevant Graphics vendors [31:23] to work with on on this in the old days [31:25] you know in the Quake 3 time frame [31:27] there were there were 20 different [31:29] people making Graphics chips and we kind [31:31] of had you know we were sort of on top [31:33] of all of that but a lot of them should [31:35] not have been writing Graphics drivers [31:36] you know you had a clear uh separation [31:39] between the the professionals that knew [31:40] what they were doing and the you know [31:42] and the companies that didn't and right [31:45] now everybody working in the industry at [31:47] a high level knows what they're doing [31:49] they have the you know the intelligent [31:52] conversations about things and we can [31:54] reach agreement on a lot of things where [31:56] we had uh talking about 60 frames per [31:59] second swap interval stuff where what we [32:01] do on the consoles and you can you can [32:03] probably catch sites signs of this uh if [32:06] you play the games aggressively uh we [32:08] try to be 60 frames per second swapping [32:11] exactly with the swap interval all the [32:13] time but we monitor a lot of things and [32:15] we adjust the game's behavior in the [32:17] rendering side we resolution scale when [32:20] it looks like we might be going over 60 [32:22] frames per second so we've got all this [32:24] Dynamic resolution scaling going on but [32:26] there's still cases where uh you know we [32:28] can't predict that all this well we [32:32] talked about trying to do some more uh [32:35] not so much predictive but uh like when [32:37] explosions go off on there really we [32:38] should have been able to inform the [32:40] renderer that that's going on and [32:41] preemptively scale it down a little bit [32:43] that's another one of those things that [32:44] we you know we should evolve towards a [32:46] little bit more but right now it's [32:48] reactive where as you're running through [32:50] the scene and it gets more and more [32:52] complex or more and more heavy with [32:54] particle overdraw it slowly scales the [32:56] resolution down and usually you won't [32:58] even notice but when something [32:59] unexpected happens like something just [33:01] jumps into view from offside and massive [33:04] explosions and after effects go off uh [33:06] we can miss the target frame rate what [33:08] we do then is we allow it to go ahead [33:11] and instead of having the classic PC [33:13] problem where either you choose swap [33:16] interval locked and you get into this [33:17] ugly awful stuttering when you're not [33:19] quite 60 frames per second you're [33:21] bobbling between 30 and 60 and doesn't [33:23] feel very smooth at all or you just [33:25] accept the tear line as kind of the [33:27] standard in high-speed PC play which [33:29] really is one of the more objectionable [33:31] Graphics artifacts that we deal with now [33:33] so what we have now is on the consoles [33:36] we proved this out first where you're [33:38] locked as long as you're going 60 frames [33:40] per second and as soon as you miss 60 [33:41] frames per second then you get some tear [33:43] lines and uh hopefully our Dynamic [33:46] adaption and everything catches in and [33:49] uh a couple frames later the tear line [33:50] just kind of runs back up to the top of [33:52] the screen and it stops tearing again [33:54] and it was really good that we're able [33:56] to make the case to uh Nvidia and AMD [34:00] and I think Intel is even going to going [34:02] to address this as well uh that look [34:05] this is an important thing we are [34:06] obsessing over some relatively [34:08] unimportant things with sizes of filter [34:11] kernels and I and the other things that [34:13] Graphics Geeks can go on about forever [34:15] but we've got this stupid ugly tear line [34:17] going down the screen or we've got this [34:18] non-isochronous swap Behavior Uh this is [34:21] actually an important thing to fix and I [34:24] you know Nvidia went in and put [34:26] something together pretty quick and [34:27] defined a it's a little bit of a hackish [34:30] interface where we didn't Define [34:31] anything new we just said well negative [34:33] swap intervals will mean I you know swap [34:35] to this if you can otherwise tear and uh [34:38] AMD looked it over and said they could [34:40] do the same thing and you know hooray a [34:42] success story for uh kind of you know [34:44] industry vendors cooperating on that so [34:47] you know that's been uh that's been [34:49] actually pretty good but we're still [34:52] we're going to push we've still got time [34:54] to make some significant pushes on the [34:56] PC side of things things um we do not [34:59] have any crazy PC specific features that [35:02] are going in on the rendering but [35:04] there's actually a lot of things in the [35:06] near-term like initial shipping version [35:09] of the PC we need to tune how big we can [35:11] make the textures where people that have [35:13] multi-gigabyte video cards that 4K by 4K [35:16] texture on the consoles we should be [35:18] able to turn that into a 16k x 16k [35:20] texture so that you know once things are [35:23] resident in that you can make quite a [35:25] bit of moving around without ever [35:27] actually having to transcode anything [35:28] else again uh and that's stuff that [35:30] we'll we'll get that tuned up relatively [35:32] soon but I'm also looking forward to the [35:35] possibility of uh doing some almost [35:39] research engine like things that may be [35:41] able to leverage some of the rage data [35:42] kind of back to the the old days where [35:44] glquake came out where it was this [35:46] completely unsupported thing that you [35:48] just dropped this eeks in and ran this [35:50] and it kind of showed you what I was [35:52] playing with technology wise with the [35:54] existing data and I'm I'm think thinking [35:57] that I might be able to do some things [35:58] like that um possibly with rage you know [36:02] it is a little bit of a bigger deal [36:03] considering the size of the company we [36:05] are and all this where I'm not positive [36:08] I can get away with just here completely [36:09] unsupported but play around it might be [36:11] kind of neat you know it might look [36:13] stupid in some places uh but that's [36:15] that's something that I'm thinking about [36:17] because there are there are the far out [36:20] technologies that I'm looking at all the [36:23] you know the different ways of [36:24] representing things whether you want to [36:25] do tracing splatting in voxal and non-p [36:28] polygonal stuff but you know that's [36:31] still relatively that's not what we're [36:33] working on right now and I'm interested [36:35] to see how far we can take our current [36:37] data sets you know if we say here's what [36:39] we've got how good could we make it look [36:42] by essentially changing the technology [36:44] because we really don't want to reinvent [36:47] our entire content pipeline again [36:50] because again it took you know the demo [36:52] of look a virtual texture it's over five [36:54] years ago uh you know it took 5 years to [36:57] get everything that goes into this for [37:00] how we create the stuff how our back-end [37:02] processing and how we distribute all of [37:04] this it takes a long time to go from [37:06] demos to you know production work and [37:10] the the cold hard truth is every game [37:14] that we've done that's come out of ID [37:15] software proper on our main stream [37:17] Mainline has taken longer than the game [37:19] before and that cannot continue you know [37:22] it's it's always well and good you plot [37:24] Trends and say you know look an [37:26] exponential curve I you know there's a [37:28] whole bunch of areas like this where I [37:30] you can say well that means that you [37:32] know three generations down the line [37:34] will be taking 30 years to create our [37:36] next game I but as is always the case if [37:40] something can't go on forever it won't [37:43] and it's all a matter of how you do the [37:45] landing from can't go on forever that [37:47] determines how you're going to come out [37:49] of it you don't want to crash land you [37:51] want to go ahead and ramp that off in [37:52] some way for a nice smooth flared [37:54] Landing um so that does have impact on [37:58] how we look at our technology [37:59] development going forward and you know [38:02] I've said for years now that I think [38:04] that we are past the knee of the curve [38:06] in terms of what we get from Graphics [38:08] technology on there there's no doubt [38:11] that Graphics still matters I you know [38:14] it's rage looks spectacular but we made [38:16] conscious choices that okay it could [38:18] have looked more spectacular and we [38:20] could have been a 30 frames per second [38:21] game like most of the competition but we [38:24] decided early on although it was was a [38:26] hardfought battle which uh at this point [38:29] despite all the pain and suffering that [38:31] we went through I think everybody's real [38:32] happy that that we did make the call [38:34] that we did uh it did involve a lot of [38:36] suffering on art design and programming [38:38] side but that initial choice to say we [38:42] can do fancier Graphics you know there [38:44] are techniques that we can apply that [38:46] will make the game look better but I'd [38:48] rather have twice the frame rate and I [38:50] think that we are that question of how [38:54] we spend our resources uh there's a lot [38:57] of options on there on what we want to [38:58] do with it um so technology-wise I'm [39:04] going to do more research engines uh you [39:06] know I've got a handful of little things [39:07] that I that I'm tinkering with I've [39:09] actually uh there are still people at [39:11] the office right now making our sht [39:13] candidates but uh it's mostly of the uh [39:17] like what do you do when you're at the [39:19] disc Swap and somebody sends you a [39:20] multiplayer invite and You Yank out your [39:22] memory card you know what do you do um [39:25] so we're we're the main game part is [39:28] done and I've actually stepped a little [39:31] bit away and there's still people there [39:32] that are that are there all night [39:34] working on getting the stuff done but I [39:36] actually opened up another little [39:37] project and started writing some new [39:39] code I relatively recently to start [39:41] exploring some things and that's I you [39:44] know it's nice to be able to start [39:46] looking at uh at some additional things [39:49] but uh it's possible that some of these [39:51] research engines might turn into other [39:54] things to do on the PC with the game [39:57] I certainly we're not going to try and [39:59] recertify a game with some fancy new [40:00] rendering technology but I'm interested [40:02] in seeing what it looks like if we take [40:05] the content that we've created now and [40:07] say you make perfect anti-aliasing or [40:10] perfect motion blur you just really do [40:12] sort of the speed of light calculation [40:14] here where you say if everything was how [40:17] we wanted it to and this was the data [40:19] that you had to work with what could you [40:21] get out of it and it's an open question [40:23] of how compelling that would be uh we do [40:26] have 10 times the horsepower on the PC [40:28] that we have on the consoles if we you [40:31] know and we are using the PC as just a [40:34] sort of a muscular console in this point [40:37] we're not doing uh anything radically [40:39] different there's not uh you know dx11 [40:41] tessellation or anything in there uh I [40:44] don't believe really in bolt-ons like [40:46] that I think it's something that you [40:48] have to design for from the beginning [40:49] and we did not choose to go that route [40:51] on this generation but if we want to [40:54] throw these ridiculous amounts of power [40:57] at it and it is you know it's crazy how [40:59] much power we have to I spend a lot of [41:01] time just uh smiling and being amazed at [41:04] how uh how much Computing horsepower [41:07] that we have to look at with these I you [41:10] know the high-end graphics cards you've [41:11] got at least 10 times the power of the [41:13] console and I know in previous years [41:15] I've talked about how we've got this [41:17] factor of a million where I've gone from [41:19] uh like the first game that I wrote to [41:21] what we're doing now you know a million [41:23] times more power but the interesting [41:25] thing was uh a month or two ago we had a [41:28] case where I actually looked at it and [41:31] said this is a factor of a billion where [41:33] I was spending it I was spending a [41:35] little bit of time reading about things [41:37] that were before my time like Atari 2600 [41:40] programming and the internet is so [41:41] awesome you know you can go and you know [41:43] look at I you know program code and ROMs [41:45] and things that people have written and [41:47] disassembled of all these ancient [41:49] systems and and that was the system from [41:51] when I was a kid uh I never programmed [41:53] for the 2600 I knew a few people that [41:55] overlapped my development space that uh [41:58] you know that did do some work there but [42:00] it was uh you it was an incredibly [42:02] primitive machine you had 128 bytes of [42:05] RAM and 2K of ROM on the early [42:09] cartridges you know later with all their [42:11] fancy Bank switching they got it up to [42:13] you know an amazing 16k of ROM on the [42:16] the highest most expensive cartridges so [42:18] you know it was fun reading about all of [42:20] this and I you know it's again one of [42:23] those things where if I only had a bunch [42:25] more time I'd like to go you know do a a [42:27] little test app and I try out certain [42:29] things on there but not likely to happen [42:32] I but still you go and look at that and [42:34] say 128 bytes of ram one of the things [42:37] that we were doing in our production [42:38] side of things for cranking out our [42:40] build games to rebuild all the games um [42:44] when we build our virtual textures for [42:46] the uh the dynamic stuff it's this [42:48] process that at one point it just took [42:51] hours I rewrote it to to be such a way [42:54] that it used a huge ounts of memory [42:56] mapped files and it got down much much [42:58] faster but it really swapped started [43:01] swapping on any system that we had so we [43:03] said well let's find out what the you [43:05] know what the actual limitations here [43:07] are so we took one of our servers and we [43:09] put 192 gigabyt of ram in it and and it [43:13] was so it's like $5,000 we used to spend [43:16] more than $5,000 on a desktop PC you [43:19] know we had $10,000 workstations back in [43:21] the day but 192 gigabytes of RAM [43:26] and I think back okay 128 bytes of ram [43:30] in the Atari 2600 192 gigabytes of RAM [43:34] being used to build this you know [43:36] greater than a factor of a billion now [43:39] that's stretching from uh you know [43:41] before my time to a server grade system [43:43] here but it's still it's nine orders of [43:46] magnitude you know where do you see that [43:48] in anything else and you also see it on [43:51] you know the storage going from 2K to I [43:53] mean two terabyte drives are pedestrian [43:55] you know that's I another factor of a [43:57] billion there so that's you know pretty [44:00] amazing to look at that and we've got a [44:02] lot more yet to come I mean certainly [44:04] serial clock speeds have you know have [44:07] pretty much petered out we're going to [44:08] see a little bit more on that but the [44:10] the massive multi-core performance that [44:12] we're getting I and certainly all the [44:14] experience with the gpus uh we're going [44:16] to be seeing more orders of magnitude [44:19] coming yet so the big question is as [44:21] game developers what do we want to do [44:23] with those um there's some OB cases [44:26] where as we look at throwing things up [44:29] for um you know for highend PCs or nextg [44:32] consoles uh there's the the immediately [44:35] clear stuff you say well instead of [44:37] running at 720p I'm going to run at my [44:39] you know 2.5k by by whatever high def PC [44:43] monitor on there you know there's a [44:45] factor of three or start running [44:47] multiple monitors take it up to maybe a [44:50] factor of 10 there you go ahead and run [44:52] your 4X or 8 or 16x multi- sample [44:55] fragment anti-al iing you take [44:57] everything out to much higher Dynamic [44:59] ranges on there and all of those are the [45:02] obvious things where you're just [45:03] cranking knobs that already exist uh [45:05] there are things that are beginning to [45:07] look possible on this level of Hardware [45:09] where I I'm looking at this thinking you [45:12] know I guess we can do a full Fast forer [45:14] transform on the entire damn screen and [45:16] do full screen convolutions of things [45:18] where instead of having our flares be [45:20] these Sprites and blurred things that we [45:22] have on there you we can convolve the [45:24] whole damn screen with this giant [45:26] Starburst and have every little pixel [45:27] come in right uh you know that might be [45:30] interesting that seems like an almost [45:32] criminal way to spend that many floating [45:34] Point operations for a post-process [45:36] operation but you know if they're there [45:38] and we don't have and we don't come up [45:39] with something more compelling to use [45:41] them for uh you know it's [45:43] interesting uh there are you know [45:46] there's a lot more that we can do with [45:47] anti-aliasing and filtering we can [45:49] certainly continue cranking up more [45:51] polygons uh more texture density uh but [45:55] we are at some of of those points with [45:56] texture density where another thing that [45:58] rage will will get knocked for if you go [46:01] and you you know you jam your face into [46:02] a wall the textures are going to be [46:04] blurry it's we don't have detail maps on [46:06] top of them we are um in many cases at a [46:09] little bit lower resolution than uh than [46:12] a game that just tiling textures would [46:13] be at and it would be it would be nice [46:17] to address that um but it's likely that [46:21] I'm not expecting anything to supersede [46:23] Blu-ray in the the real near future uh [46:27] the world's moving towards digital [46:28] distribution in a lot of ways uh DVDs [46:30] are definitely annoying to have to swap [46:33] DVDs to get what we want on here I you [46:36] know another of the things [46:38] that I I I do have to watch myself a [46:41] little bit on some of these like I'm [46:42] going to say some things that I know are [46:44] going to get taken out of context and I [46:46] and I may regret a little bit later but [46:48] the uh I wish that we had had the time [46:52] to to max out a double layer Blu-ray DVD [46:55] for for the [46:56] PS3 um right now we deliver the same [47:00] content across all of it and [47:02] realistically it's not just a matter [47:03] saying oh you know we could have just [47:05] done this it would have been a lot of [47:07] effort and it would have our build [47:08] process we're down to the wire as it is [47:11] we you know we would have been courting [47:12] failure if we had tried to do this but [47:15] it would have been nice to have twice [47:17] the data there that we could have pulled [47:18] out from uh without our artists having [47:22] to draw anything different we could have [47:23] changed our compression ratios and the [47:25] way we call detail out um and that could [47:28] have offered some better view there but [47:31] on the other hand the Blu-ray is the [47:32] slowest seeking device and the PS3 has [47:35] the least available memory so it's not [47:37] completely clear what um you know what [47:40] benefit we might have had off of that [47:42] but that's another thing I'd like to do [47:43] on the PC is I we I would hope that we [47:47] could make some kind of DLC that maybe [47:49] we take one level and we encode it at 10 [47:53] times the bit rate or something so like [47:55] here's one level but it's uh you know [47:57] it's two gigs or something rather than [47:59] the the 500 Megs or 3 to 500 Megs that [48:02] we make each individual thing uh just to [48:04] see like what's the extra benefit [48:06] because I do think that if you're just [48:08] running around playing the game like if [48:10] you watch everybody playing over there [48:11] in the the hall doesn't make a whole lot [48:14] of difference but when you stop and you [48:15] want to like really appreciate it there [48:17] would be an extra level of appreciation [48:19] that we could get there and it's I so [48:22] that's another thing that we may try to [48:23] do on the PC you know hire data higher [48:26] rate data sets uh you know larger pages [48:29] that we wind up pulling the stuff [48:32] into but there's uh it's worth talking a [48:34] little bit about how we pull all of this [48:36] data in where the shipping game [48:39] obviously it fits on One Blu-Ray disc [48:41] it's 20s something gigs uh that you wind [48:43] up putting into everything uh but the [48:45] source data is so so much larger than [48:49] that the uh the textures that that go [48:53] together to build um that are the source [48:56] art that go into building the mega [48:58] textures uh we we ran into a limit where [49:00] it ran out of a 256,000 by [49:03] 256,000 texture where everything was fit [49:06] into there and that's all the source art [49:08] the the mountain sides the ground the [49:09] stamps and everything that goes that [49:11] gets built into or they it's baked into [49:13] the the textures that actually ship and [49:16] you look through that so it's I so [49:18] 64,000 so it's 64 gigel of source data [49:22] and each one is three channels uh or [49:25] three images of three or four channels [49:28] on there it's 12 bytes on there so with [49:31] M Maps that's a terabyte of source art [49:33] that goes into making the content that [49:35] goes and ships on the One Blu-Ray or [49:37] three [49:39] DVDs now the when we build the levels it [49:43] takes that Source art combines it with [49:44] all of the lighting and uh and builds [49:47] these final outputs which are between [49:50] the biggest levels are 128 by 128 uh the [49:53] dynamic characters I think all fit in in [49:55] a 64k x 64k and the individual the [49:59] Wasteland is 14 pieces it wouldn't fit [50:02] even in one 256 x 256 it's about 14 [50:05] pieces of various sizes from 32k to you [50:09] know up to 128k for parts of it so what [50:12] we do to make all of this fit at the top [50:15] level we build out all of this and if we [50:17] shipped all of that completely uh [50:19] uncompressed in RGB format it would be [50:22] you know many many it's like 100 gigs or [50:25] so for what we would start off on that [50:27] so to get that down we obviously have [50:29] the the HD photo compression we digest [50:32] everything down uh that saves a lot but [50:35] uh we get a large amount by profiling [50:37] where the player can go so another thing [50:39] that you can do in the PC version Bring [50:42] Down the console no clip up and you you [50:44] fly up and you look at some rooftops on [50:46] there and you say it's like oh the [50:47] rooftops are all blurry I well that's [50:49] because we have these surfaces where we [50:51] map out where the player is supposed to [50:53] be able to go and we view you know we [50:56] profile zillions of views from all these [50:58] places and say well these are the images [50:59] that we need at this resolution and the [51:02] ones that are further away they get you [51:04] know lower and lower resolution and that [51:06] hurts a little bit where it's baselined [51:09] on I like a 720p image so if you're [51:12] running on a uh a PC at really high [51:15] resolution if you see something that has [51:18] like if you're in town and you can walk [51:20] all the way up to it if you're across [51:21] town you'll get all of your resolution [51:23] in there it'll use it all up but if [51:25] you're looking at something that the [51:26] player can't actually approach like the [51:28] top of a guard Tower or something where [51:30] the player can't walk up there when you [51:32] walk up on your 3 megapixel PC monitor [51:35] on there unfortunately the texture data [51:37] just doesn't exist to have the higher [51:39] quality data there so it winds up being [51:41] a little bit blurrier again if we uh you [51:44] know if we ever do get to have some kind [51:46] of a downloadable super quality pack [51:48] something in some area it would be nice [51:51] to have some of that extra stuff there [51:53] uh because it was it was painful and [51:56] disappointing during development where [51:57] at the start we were developing all on [51:59] the PC and the artists were building [52:01] stuff and when we finally kind of showed [52:03] them it's like well we have to go [52:05] through all this texture compression [52:06] stuff and this is what it's going to [52:07] look like on the game there were some [52:08] sad-faced artists looking at I at all of [52:11] this but once they start you know [52:14] working with it it's still it's just [52:16] it's a factor you have to take into [52:18] effect um you know and that also uh one [52:21] of the other sort of related to that is [52:23] we have areas that are my crusade for [52:26] years I've always been about ID games [52:28] are dinged appropriately for being far [52:30] too dark uh you know the dark areas [52:32] where you can't see what's going on you [52:34] you're supposed to of course the artists [52:35] are like well turn off your lights play [52:37] in the dark room that's the way it's [52:38] supposed to be played I but in reality [52:41] lots of times if people would look at [52:43] Doom 3 and you'd play it and just not [52:46] see half of the stuff that's there so we [52:48] made a conscious effort to brighten [52:50] things up but some of the stuff that [52:51] would happen during development on rage [52:54] is we have real lights and then we've [52:56] got our postprocessing effects on there [52:58] and sometimes we'd use we have arguments [53:01] about the the usefulness of [53:03] post-processing there's lots of people [53:05] that really love it uh a lot of times [53:07] I'm looking at something and I bring [53:09] down the console and like turn off [53:11] post-processing I'm like wow this looks [53:13] so much better you know crisper and [53:15] clearer you can see all the detail the [53:17] colors aren't messed up but I you know I [53:19] lost that battle I pretty clearly where [53:22] there's there's lots of post effects [53:24] going on throughout the game and lots of [53:26] times it does convey the right mood and [53:28] it does all of this but it does a lot of [53:30] damage to all of this Tech this data [53:32] that we spent we killed ourselves to get [53:33] it compressed over there and then to [53:35] have some postprocess go in and muck up [53:37] all the pixels uh is sometimes a little [53:39] bit uh depressing in some ways but uh [53:44] with all of this data that we've got on [53:45] there again it's it would be terabyte [53:48] plus going on there gets fully yeah [53:54] think [53:57] yeah this is actually uh having a game [53:59] to talk about I don't know how I've got [54:00] a bunch of things that I want to go into [54:02] and then the Q&A but there's uh there's [54:04] a lot involved just in Rage uh but I [54:07] probably should kind of push on to some [54:09] other topics here the um one of the real [54:12] interesting things about the development [54:14] this year that happened over the course [54:16] of the last couple years um I spent a [54:19] lot of time with static software [54:22] analysis tools and it's it's been an eye [54:25] openening experience for me where all [54:28] the good programmers I know everybody [54:30] has a goal of you want to write good [54:32] software you want to do it's your craft [54:34] it's what you do you want to make sure [54:36] that it's high quality and efficient and [54:38] does a good job but those are are very [54:41] kind of vague handwavy things you know [54:44] but it's still you could say that that's [54:45] kind of the the Mantra you want to write [54:47] good [54:47] software but there are so much the [54:50] individual styles that people have to [54:52] develop uh there are have been plenty of [54:54] study and analyses of things but there [54:57] are certain ways of doing things where [54:59] that are more or less error prone and [55:01] getting into a programming language [55:03] discussion it's it's a religious War [55:05] sort of thing if you try and tell [55:06] someone that their favorite operator is [55:08] error prone then they'll be like only [55:10] for bad programmers you know good [55:12] programmers will use it right and any [55:14] tool you can shoot yourself in the foot [55:15] with on this but uh but it's been [55:20] enlightening to have a lot of analysis [55:22] tools to look at our our large code base [55:26] where it was different when it was just [55:28] uh like me and my right-and man uh [55:31] working on the code at ID we have uh the [55:34] ID when I send something out to ID [55:36] programmers our Alias it goes to 49 [55:39] people they're not all programmers that [55:40] are there's some of them are people that [55:42] just want to be informed on what we're [55:43] doing on there but when we look over our [55:46] uh you know our two big teams and the [55:48] two are two smaller teams involved in [55:50] doing different things there's a lot of [55:53] people that wind up writing code [55:56] touching code committing to our you know [55:58] our [55:59] repository and it winds up I there's [56:03] millions of lines of code I you know I [56:05] don't have that's one of those things I [56:07] I sometimes Miss just having a a [56:09] convenient word count on Windows I [56:10] haven't bothered to go and and get real [56:12] numbers but uh it's multiple millions of [56:15] lines of code and uh we know that it uh [56:18] we had one number where we initially [56:20] tried using city as a company that comes [56:23] in they do analysis of all of code and [56:26] they they gave us like a 100 issues as a [56:28] promo of I you know here's what here's [56:31] some things that our tool found in there [56:33] uh and they said you know it's a really [56:34] high quality code base that this uh [56:36] usually we find a bunch more things than [56:38] this and you know I pr a little bit at [56:40] that say it's like that's it's great [56:42] that we've got a good team of [56:43] programmers on this and uh they wanted [56:46] like $50,000 for this software tool and [56:49] if you thought that well it's going to [56:50] save you uh looking stupid when you ship [56:52] your game on there that's a completely [56:54] reasonable thing but we figured we would [56:56] get back to to looking into that when we [56:59] got closer to shipping but uh later on I [57:01] started looking at some other tools [57:03] options that were available one of the [57:05] really great things uh available is [57:07] Microsoft has some pretty high quality [57:10] they've got Microsoft actually has uh a [57:13] very interesting research Department [57:14] that does a lot of things Microsoft [57:16] research has a lot of really smart [57:17] people in and they do a lot of work [57:19] covering a lot of different areas but [57:21] they productized some of their work that [57:23] had been you know research early on and [57:25] they've got analyze options for the [57:27] compilers now normally you only get that [57:30] on your super ultra Platinum premium [57:33] $10,000 Visual Studio on there but [57:36] interestingly for the 360 uh development [57:39] kit everybody gets that option now most [57:42] developers either aren't even aware of [57:44] it or don't want to turn it on not don't [57:47] want to deal with it but it's an [57:48] interesting thought with there where I [57:50] guess you can draw the conclusion that [57:52] Microsoft figures they're not going to [57:53] get blamed for buggy PC apps but they [57:55] will shoulder some blame for buggy 360 [57:58] apps so they're going to make these [57:59] tools that make significant differences [58:01] available for free to 360 developers um [58:05] and I'll say this quite clearly with no [58:07] hesitation any 360 developers that are [58:09] listening to this if you're not using [58:11] analyze you are making a mistake uh it [58:15] is enlightening to see what happens when [58:18] you turn this on um we found so we had [58:22] come out of this coity stuff with you [58:24] know 100ish issues or so on there uh we [58:27] had certainly grown a lot of code since [58:29] then we had a lot of new programmers but [58:31] when we first turned on the Microsoft [58:32] analysis stuff uh it found hundreds and [58:36] hundreds of things now some of them are [58:39] the cases where you get a programmer and [58:40] say that's not really an error I know [58:41] what I'm doing look this guarantees that [58:43] this doesn't make this happen and it's [58:45] okay and there were plenty of those but [58:47] there were also tons of things where you [58:50] look at this and say it's saying uh you [58:53] know potential null pointer access here [58:55] you're like well I'm checking up there [58:58] but nope not checking down there you're [59:01] right and when you see things like that [59:05] happen over and over and over again you [59:08] know hundreds of times you start looking [59:10] at this in a very different way because [59:13] everybody thinks about programming and [59:15] development where it's like okay you [59:16] know we we bang the bugs out of it we [59:18] get the code good now it's good solid [59:20] stuff uh we'll you know we'll deal with [59:22] things in [59:23] maintenance and there's uh when you talk [59:26] about reliability Theory uh and [59:28] different things that people an analyze [59:30] when they're talking about traditional [59:32] like engineering structures there's a [59:34] lot of debate that goes into things [59:35] about how well software is just [59:37] different you know we can take our [59:38] metals and we can uh get our spread of [59:40] ultimate tensil strengths and yield [59:42] strength and do all of this and this is [59:43] how you look at failures you add up all [59:45] of these tolerances and you can do all [59:47] of your analyses and figure out some [59:49] estimate about how reliable it's going [59:51] to be but you can't look at software [59:53] like that because software is supposedly [59:55] deterministic you know either it works [59:57] or it doesn't it has no chance of [59:59] failing uh given the same input and [60:03] there's truth to that and you can argue [60:05] that in a certain way but when you start [60:07] looking at large enough bodies of [60:09] software millions of lines dozens of [60:11] developers there does get to be a [60:14] distressingly statistical nature to the [60:16] amount of failures that you see where [60:19] software may be deterministic going [60:22] through things assuming you don't have [60:23] uninitialized variables and randomized [60:25] memory locations I but the development [60:29] process of building that software is [60:32] very much a statistical process where uh [60:36] every programmer in the company has you [60:38] know has put things in that come out and [60:40] that are just wrong you know you make [60:42] them up and I you know I C before I got [60:45] into the static code analysis I did [60:47] another exercise where I tried to keep a [60:49] log of the personal errors that I made [60:52] where you write the code you don't count [60:54] the the things just where you're [60:55] compiling it getting it to work and not [60:56] blow up on the very first time that you [60:58] you know you get it to run but keeping a [61:01] log of the things where all right I [61:03] think it's working and then you all the [61:04] things that you find days or weeks or [61:06] months later that were actually wrong [61:09] and there were patterns in there there [61:10] were things that that uh I could see [61:13] that I was doing where uh a common [61:15] Paradigm if you're dealing with pairs or [61:18] triples of numbers you've got like ax a [61:20] y z uh it's very very common to say all [61:23] right copy that line Pace Pace past [61:25] change the X's to y's and the Y's [61:27] disease and uh go through all of that [61:29] happens all the time there's tons of [61:31] code that does that but I noticed that [61:33] uh you know when I looked at this over [61:35] six months I had had three errors that [61:37] crept through um you know that were not [61:40] immediately discovered that only came up [61:42] later that was a result of not doing [61:44] that particular thing right and and they [61:47] were subtle things like oh the alpha [61:49] channel was screwed up on this image [61:50] that I never looked at because I was [61:52] actually copying the blue Channel cuz I [61:54] didn't change A A Z to A W or something [61:57] and something happens once you say well [61:59] it's an anomaly you know two or three [62:01] times you start seeing Trends and start [62:03] looking at saying well what do you do to [62:05] make this not happen and in those cases [62:07] the obvious things are you use either [62:09] you know Loops or or templates or [62:11] objects or something so that you don't [62:12] have this thing you're you don't want to [62:14] feel inclined to copy paste but there [62:17] are a lot of things like that that [62:19] happen where uh there are things that [62:22] people just do every day they may have [62:24] done their entire career been working [62:25] for 20 years uh that just are error [62:28] prone and are things that wind up uh [62:30] causing you problems as you go forward [62:33] and when we look at these larger teams [62:35] with millions of lines of codes and so [62:37] many developers figuring out better [62:40] practices uh is really important so [62:43] we've uh I've really gotten behind the [62:46] static code analysis we have like the [62:48] the Microsoft analyze tools are are [62:50] always on and there warnings as errors [62:53] you can't build the game and run it if [62:54] it complains about anything and even [62:56] when it's wrong even when you've got [62:59] something and you can prove and you can [63:00] say no it's guaranteed okay because [63:02] these interrelated things here that's [63:04] actually a good time to step back and [63:05] say you know if you had to explain that [63:07] to me maybe you should change the way [63:09] the code is working if the analyzer [63:11] can't figure it out other programmers [63:13] probably won't immediately figure it out [63:15] and it will cause problems and that's [63:17] the other thing that you really notice [63:19] when looking at things um you get a [63:22] certain perspective if you take your [63:23] little Home Group project that you put [63:25] together and you run it through certain [63:26] tools and lots of people will say I [63:28] don't need these stupid warnings I you [63:30] know I'll just figure it out I know what [63:32] I'm doing and there's some truth to that [63:34] where uh if you've got to hack something [63:36] together pretty quick maybe you do want [63:37] a dynamic language that's not going to [63:39] complain about types it's not going to [63:42] you know I just kind of get in your way [63:44] and who cares if it doesn't work on lots [63:45] of different things if it just sometimes [63:47] you just want something done right now [63:48] and that's okay and it's good to have [63:50] tools that are efficient for that but [63:52] when you've got a code base that's it's [63:54] going to live for a long time and I tell [63:56] the programmers now that expect a lot of [63:58] the code that you're writing it's going [63:59] to be in use in some way 10 years from [64:01] now uh you know there are bits of Quake [64:05] one code that are in modern games you [64:07] know nothing important but there are [64:09] there are little lines that are still [64:11] there so you have to expect that uh the [64:14] code will last a long time and when [64:16] people start maintaining the code and [64:18] adding features to it things will break [64:21] and that's one of the patterns we see [64:22] all the time in the game code especially [64:25] where it's clear that they checked for [64:27] okay I've got Target and my target enemy [64:29] is not another player or this uh but [64:31] then later somebody says well we need [64:32] this other feature let's you know let's [64:34] make this do this under these conditions [64:35] so somebody writes some more code down [64:37] there but it doesn't have the same [64:39] knowledge of preconditions up there and [64:41] that's when we wind up getting a game [64:43] Crash uh you know somebody winds up [64:45] saying it's like oh but I didn't expect [64:47] that we would be changing weapons while [64:49] I'm falling to my death getting crushed [64:50] by a vehicle that's targeting me or [64:52] something like that and those things [64:54] really come back to bite you so we are [64:58] uh you know we've got some healthy [64:59] discussion going on about uh you know [65:01] different things that we can do in our [65:03] programming languages to make things [65:05] less error prone because it does come [65:08] down to this we have to figure out how [65:10] to still do aggressive awesome things in [65:13] less time you know we cannot take eight [65:16] years next time to make our next game [65:18] some of that's content production some [65:20] of its programming a lot of its design [65:22] picking your battles intelligent [65:24] but as programmers there are a lot of [65:27] things that we can do to not just say [65:29] write better code take pride in your [65:31] work that's good and important but you [65:34] also have to start changing some of the [65:36] things that you do and applying other [65:37] tools that are sometimes I you know [65:40] sometimes unpleasant uh after Microsoft [65:43] analyze I moved on to a couple other [65:45] tools you know using PVS studio and uh [65:48] you know then eventually I reached PC [65:50] lint which is this program that's been [65:51] around forever you know lint was [65:53] originally an early Unix program and the [65:56] interesting thing is I was in my uh a [65:58] closet at my house looking at some [66:00] things and I noticed that I had like a a [66:03] version seven of PC lint on and I [66:06] thought back and like yeah I did [66:07] remember looking at that back in the [66:09] Quake 3 days I ran some of the stuff and [66:11] that was back when there were three [66:13] programmers involved with the project [66:16] and I and it was also C instead of C++ [66:19] and I remember going through that and [66:20] saying oh this could help make quality [66:22] stuff it could be some improvements but [66:23] it didn't really stick I didn't have [66:25] that sort of conversion experience where [66:27] clearly I'm seeing the massive value in [66:30] static analysis that I do [66:32] now so U we are completely squeegee [66:35] clean error free on Microsoft analyze [66:39] and PBS Studio but PC lint is uh you [66:42] know is another Beast entirely where [66:45] it's a lot higher noise to Signal ratio [66:47] where it can it can complain about [66:49] everything you know all sorts of [66:50] pedantic stuff and I had hoped that I [66:52] would be able to I I got all of the [66:54] errors out I was hoping I would be able [66:56] to go through and at least look at and [66:57] address every warning in there before [66:59] shipping but we weren't able to there [67:01] were still thousands of things and a lot [67:04] of them were clearly I can say well all [67:06] hundred of these are because we actually [67:08] initialized something someplace else but [67:10] it gets back down to that I'm doing that [67:11] sort of hand waving it's like yeah it [67:13] looks like that might happen but it [67:14] really can't and I'm sure buried in [67:16] those thousand warnings are some of [67:18] those that really could happen so we're [67:20] trying to you know to to write better [67:23] code from the beginning in some ways and [67:25] I'm I I am considering some of the [67:29] things that we're doing on the other [67:31] project that I think leads the way here [67:33] uh one of the lessons that we we took [67:35] away from Doom 3 was that script script [67:39] interpreters are bad from a a [67:41] performance debugging development [67:42] standpoint on there it's kind of that [67:44] argument about oh but you want a free [67:46] form dynamically typed language here so [67:48] you can do all of your quick flexible [67:50] stuff and people that aren't really [67:51] programmers can do this stuff but you [67:53] know one of the big lessons of a big [67:54] project is you don't want people that [67:56] aren't really programmers programming [67:57] you'll suffer for it um but one of the [68:01] things that we did is because the other [68:03] side of it is also performance you'd [68:05] think that with our million times faster [68:07] systems that it's like ah scripting some [68:10] things performance should be a non-issue [68:12] and it's it's striking almost how much [68:14] that isn't the case I you know in the [68:17] last month of rage's development we're [68:19] taking some of our flash gooey stuff and [68:21] converting it to C++ because the inter [68:24] to for doing the action script stuff in [68:26] the guy is taking multiple milliseconds [68:28] sometimes even with all of our wealth of [68:31] processing power uh we still don't have [68:33] enough performance performance still [68:35] matters but even more than the [68:36] performance now I'm looking for these [68:38] stronger guarantees on code quality you [68:40] know I want us to be able to you know [68:42] have full analysis trees that say okay [68:45] you can still mess the game up by doing [68:47] all sorts of different things but what I [68:50] want to be working towards is a case [68:51] where we can say well the game cannot [68:54] I cannot have an exception of any kind [68:57] with sufficient analysis through there [68:59] we're not there yet but one of the [69:01] interesting things that's going on is uh [69:04] rage still has a little bit of script uh [69:06] we still have script that's derivative [69:08] from Doom 3 it does a few things but the [69:10] bulk of the heavy lifting is just ingame [69:12] code I you know the in Doom 4 we have [69:16] what we call Super script which is [69:19] basically a way to do scripting in C++ [69:21] it's a limited subset of it but you get [69:23] the fiber goodness about being able to [69:25] sleep and do the the nice scheduling [69:27] things that people always miss in [69:29] scripting but it's full performance and [69:31] it's type safe and things like this [69:33] where uh I'm thinking that we may want [69:35] to take that even a step further and go [69:38] to a rigorously subsetted C++ dialect [69:42] for writing the code because it comes [69:44] back to this statistical awareness of we [69:46] look over all the codebase and mistakes [69:48] are made every day there are all of [69:51] these things and it's it's not because [69:53] people are are no good the very best [69:55] programmers always make mistakes and [69:57] this is something that I've really [69:58] internalized that no matter how good you [70:01] think you are you are making mistakes [70:03] all the time and you have to have [70:05] structures around you to try and help [70:07] you limit the damage that your mistakes [70:08] will cause find them as early as [70:11] possible so that you can correct them [70:13] and the earliest possible time is to [70:15] find them at compile time so I'm I you [70:18] know I'm all about trying to be much [70:20] more restrictive on what we can do here [70:23] and on the one hand I would I would [70:25] entertain programming in I'm very [70:28] tempted to want to move to a functional [70:30] programming language start programming [70:32] in you know in hll or Oak camel or [70:34] something but that's not a credible [70:36] thing to do in the game industry because [70:38] again 49 people on our list I I could [70:41] probably convince a handful of them that [70:43] we should yeah we should go convert to a [70:45] new programming language but then we're [70:47] back into having performance issues in [70:49] different cases uh having a huge [70:51] educational and hiring problem so so we [70:53] got to stay with something that's cc+ [70:56] pluses based on there but I think that [70:59] we I think that it would be worthwhile [71:02] for 95% of our code to have hard [71:06] restrictions in place to limit us to [71:08] essentially the Java subset of C++ where [71:12] I you know you have no unchecked arrays [71:14] you have no uninitialized pointers you [71:17] know you have no use after free hazards [71:20] all of these things where you know you [71:22] look it all down and that's of the [71:23] decisions that you make with Java and [71:26] then I'd even go a little bit beyond [71:27] that but it's one thing to say I write [71:30] all of my new code in this pseudo [71:32] functional Style on there but unless [71:34] somebody unless something is made [71:36] impossible it will still creep into your [71:38] code base so we probably need to be [71:40] looking at being able to analyze our [71:42] whole code base and say okay these hyper [71:45] performance Twitchy tuned areas they are [71:48] go for it do whatever the heck you want [71:49] on here but the vast bulk of the code we [71:51] want to be able to make stronger [71:53] statements about it and that's one of [71:54] the big directions that that I want to [71:56] be looking at going forward you know the [71:59] we've learned a lot about the coding and [72:01] the development but it's still if not it [72:06] still winds up being right now of course [72:08] the final C issues content is done so [72:10] programming still the long pole in the [72:12] tent here U we could argue that if I if [72:16] we hadn't let ourselves be pushed so [72:18] much on performance uh the programming [72:20] would have been stable and could have [72:21] been used earlier on that but uh [72:24] unquestionably it w it Still Remains as [72:26] one of the most important things so [72:28] looking at what we can do during our [72:30] development process there is a you know [72:32] is a pretty big deal I future research [72:37] wise I've [72:39] got one of the thing I've got the couple [72:41] things that I'm looking into with using [72:44] the current um you know the current [72:46] direction of our current data set [72:49] because I don't think at this point that [72:52] we can look at the next two games going [72:55] to a completely different uh development [72:57] process you know we want a little bit [73:00] more stability on there it's possible [73:02] the way it might go is I do some fancy [73:05] demo of some infinite detail technology [73:07] on there and uh everybody goes oh my [73:11] gosh we really want to use that but I [73:13] think a lot of us at this point are [73:15] looking back at rage and saying you know [73:17] if we had backed off a little bit we [73:19] could have shipped two games in this [73:21] time uh time frame and if If You Could [73:23] Turn Back Time what I wish we had done [73:25] is uh taken something with idtech 4 done [73:28] another game I mean maybe we did a you [73:30] know just rolled right into a doom four [73:32] there while rage was under development [73:34] and have a game every three years um but [73:38] it's I we don't want to make that same [73:40] huge long dead time I mean it's been [73:42] great that everybody still comes to quak [73:44] con year after year even though we [73:45] hadn't shipped a game for six years I [73:48] but uh we we don't want to be in that [73:50] position again in the future and we had [73:53] the part partner companies all of our [73:54] work with Raven it was you know we had [73:56] our Quake four and our Wolfenstein but [73:58] uh where we are right now we want the [74:00] the big quality games coming out from [74:02] the the team Under One Roof uh it's been [74:06] it's been quite a long journey and the [74:08] company has exploded in this last uh the [74:11] last couple years I think we're we're [74:13] over 200 people now at the company uh it [74:16] is interesting having QA and production [74:19] work uh under our roof one of the things [74:22] that uh like our last game that we did [74:24] with Doom 3 we're like okay it's a PC [74:26] game it runs uh burn it to a disc hand [74:29] it off to the publisher and and we're [74:31] all done uh it's a different world right [74:33] now where we have the multi [74:35] multi-platforms and all the translations [74:37] that we're integrating inhouse and it it [74:40] sucks up a lot of additional people [74:42] there's a lot of extra work that goes [74:44] into not just making the game but [74:46] delivering it on all those those areas [74:50] and I I I get asked a lot if I missed [74:53] the old days of the smaller teams on [74:56] there and uh this last year especially [74:59] has been uh there have been so many [75:00] anniversaries on this where we had uh ID [75:04] software's 20th anniversary quake's 15th [75:07] I'm 40 years old all of these big [75:09] numbers that uh that go by yeah there [75:12] was a recent Graphics article uh that I [75:14] made a cameo as old man carac uh about [75:18] time for me to grow a Gray beard or [75:19] something here and that uh you know it [75:22] has been path from I you know from Young [75:26] whiz kid to Industry veteran I guess [75:28] there's a uh what is it there there's a [75:31] pattern that goes the the Spectrum from [75:32] Young genius to Old Master as we've kind [75:35] of walked along the the path there but [75:39] you know I I have fond memories of a lot [75:41] of the old days but the what I've told [75:44] the reporters over and over is I'm [75:46] really a remarkably unsentimental person [75:48] I don't spend a lot of time thinking [75:51] about the good old days because I see [75:53] this this a lot the good old days are [75:54] right now uh rage is the best game we've [75:57] ever made uh I'm enjoying my programming [75:59] as much now as I ever have I'm better [76:01] programmer than I ever was I it's you [76:05] know I I have I have this extra release [76:08] that a lot of people don't have is that [76:09] I get to go spend a little bit time [76:10] working on mobile projects each year and [76:13] I had you know I told zenax it's like [76:15] 10% of my time that's what I'll I'll go [76:17] and do this and I busted that budget a [76:19] little bit doing the rage I IOS app [76:22] early on because [76:23] historically the way the mobile stuff [76:25] had worked is I got to go in and have my [76:27] little retro moment where i' I'd go [76:29] dredge back up uh how you write a [76:31] software rasterizer or how you program [76:33] on you know DX7 clash gpus and I would [76:36] sort of toss it over a wall and the the [76:38] mobile team would go build a cool game [76:40] out of it uh with rage because it was [76:43] going to be the first thing people could [76:44] publicly see about rage we made the [76:47] decision that uh that I would stick with [76:49] the project all the way through to [76:50] shipping and so there were a couple [76:53] months that I didn't spend any time on [76:54] the big project so I haven't actually [76:56] touched xcode or any mobile development [76:59] since I you know since that shipped [77:01] because that really did kind of [77:02] overshoot uh the time that I was [77:04] supposed to be dedicating to all of that [77:07] but the uh it was interesting just the [77:09] process of going back in the older [77:11] Technologies and in almost all cases I [77:14] was able to go back and say uh you know [77:17] with all of this hindsight some little [77:19] part of my brain would still be working [77:20] on those problems that I had in the [77:22] early days I was able to go back and say [77:24] all right I've got four days let's write [77:26] a little software rasterizing engine for [77:28] all of this and plow through that and [77:30] that was it was a ton of fun to go back [77:32] and explore the the old space there and [77:35] realize that I I really have learned a [77:38] lot over the years there are lessons [77:40] that let me write better code than than [77:42] what I wrote back then uh even without [77:44] the extra resources and I do sometimes [77:47] think that uh there was a as we moved [77:49] offices recently uh we have bookshelves [77:52] of old books and there was a uh a [77:55] Commodore Vic 20 reference manual that I [77:57] think I'd been carrying around since I [77:58] was 12 years old or something that had [78:00] just still wound up on a bookshelf at ID [78:03] and one of the younger guys had made the [78:05] comment that you know looking at that [78:07] how he doesn't know if the the younger [78:09] generation will ever have the same kind [78:11] of in touch with the machine that I that [78:14] our older generation like pointing at me [78:16] and Robert Duffy had um by having that [78:19] sense of here's the registers that make [78:21] the machine go and knowing everything in [78:23] there and you know my immediate reply [78:26] was yeah but the new generation can you [78:29] know tie things together on web pages [78:31] and do this amazing data access stuff [78:33] and do absolutely incredible things with [78:35] modern tools and infrastructure and yeah [78:37] you do have 20 layers of crap between [78:39] you and the Machine but it lets you do [78:41] amazing things and that's you know and [78:43] that's all well and good and it is [78:45] progress you know I'm not yet a grumpy [78:47] old man about kids these days not [78:49] knowing how to program their Assembly [78:50] Language and and all this [78:53] I but I do sometimes think that there [78:56] there is value to be had for going back [78:58] and looking at resource constrained [79:00] situations because again just you know [79:03] right now resource constraints matter we [79:06] sweat a lot on rage about getting our [79:08] systems to to fit into these constraints [79:10] even though they're insane compared to [79:13] what you would have in the early days [79:14] you know you look at you know your cell [79:17] phone is far more powerful than a cray [79:19] supercomputer and we're using it for for [79:22] all of these silly mundane things with [79:24] all of these layers of inefficiency but [79:26] it still winds up being the right thing [79:28] to do but we have not yet reached the [79:30] point where we don't care about resource [79:33] constraints so sometimes I do think that [79:35] there would be value in spending time on [79:38] much more tightly constrained platforms [79:40] and I thought for a little while cell [79:41] phones were were like that where we look [79:44] at this and say okay 128k for Doom RPG [79:46] let's cram it all in there and you learn [79:49] you all this silly stuff about [79:50] optimizing Java B code and different [79:53] things like that but that has you know [79:55] it's rocketed so far ahead it's like [79:57] this is just and the crazy thing is this [79:59] is all in the space that we've been [80:01] developing rage that I started doing [80:03] some of the little work on feature [80:04] phones we get the iPhone out and Android [80:07] and going through all of this and then [80:09] we're up to these gigahertz processors [80:11] with gigabyte of ram that you can carry [80:13] around in your pocket and oh optimizing [80:16] for 128k doesn't seem all that relevant [80:19] anymore but I still think back to that [80:21] it might even be worth [80:23] having an artificial limitation you know [80:25] where there are I I think pretty highly [80:27] of a lot of the the people that do 64k [80:30] demo competitions and things like that [80:31] where it's an arbitrary guideline but to [80:34] go ahead and and fit something in there [80:37] there are things that you learn doing [80:38] that and sometimes I think that maybe [80:40] there should be something like that [80:42] where you pick some older platform [80:44] that's uh you know that's low [80:46] performance but I low enough performance [80:49] that you evaluate some of these [80:51] interesting questions uh but you could [80:53] still program it and explore different [80:55] ways of doing things and I've actually [80:56] spent a reasonable amount of time [80:58] thinking through this where I think the [80:59] right thing to do would be to take one [81:00] of the old consoles uh that they were [81:02] produced in the millions and you take [81:04] something on the level of a PS1 or a a [81:08] you know a Nintendo an ultra 64 or [81:10] something where it's a 32-bit system you [81:12] can write real programs in it it's not [81:14] dealing with Bizarro quirky Hardware but [81:17] just something where you go back and [81:18] revisit things like well how would you [81:20] write you know a web browser in this [81:23] space or a male program and I'm thinking [81:25] this would be kind of like the society [81:26] for Creative anachronism for programmers [81:29] instead of bash bashing each other with [81:30] foam swords you're playing on archaic [81:32] hardware and you know and maybe having [81:34] some educational uh you know upside to [81:37] it uh and that's on my list of things [81:40] that I will probably never get to do for [81:42] time constraints I but you know I I'd [81:45] like to go back and and spend some time [81:47] playing with the older things where [81:49] getting a sense of that I do think is [81:52] valuable it's hard to quantify the value [81:54] for for that but like I'd love to if we [81:57] had a ho in our schedule to say okay [81:59] programming team uh we're all going to [82:01] write an Atari 2600 game you know you [82:03] have X number of days Let's uh let's see [82:06] what everybody does it'll be an [82:07] interesting [82:08] experience I that does tie a little bit [82:11] into another one of the issues with how [82:13] the company's grown on this and one of [82:15] the things that we're not doing a [82:17] spectacular job on is I you know it is [82:21] has really been sink or swim where [82:23] somebody gets hired they're like okay [82:25] here's your desk here's your you know [82:27] here's how you bring down the source [82:28] code and I make yourself productive real [82:31] quick now uh which is you know and some [82:34] people have thrived under that you know [82:36] we've got some of the people that just [82:37] have dived in and figured everything out [82:39] and I you know written all of their [82:41] little test cases and stuff and uh and [82:43] explored and learned but it's not the [82:45] most efficient way to deal with this and [82:48] we're still grappling with how we you [82:50] know how we deal with this not just in [82:52] programming but across the whole thing [82:53] and perhaps even more so in in content [82:56] development because people come in I you [82:59] know that have worked on Unreal Engine [83:01] or something like that they know how to [83:02] make things happen there and they have [83:04] no idea whatsoever uh how to make [83:07] something happen with our current [83:08] generation of technology and certainly [83:10] we don't have a polished SDK and [83:12] Commercial Books available uh it is a [83:15] shame that we don't have the uh you know [83:18] the mod community that we used to draw [83:20] so heavily from and there are just large [83:22] Trends in the industry that we're going [83:25] to release our editor for rage uh but [83:27] it's kind of going to be a non-issue you [83:29] can go in and change layers and make new [83:31] layouts for Monsters but I you know [83:34] there will not be many people that are [83:35] trying to make a new Mega texture it's [83:37] just too involveed there's too much [83:39] effort I it's just so much work and [83:41] there's so many things you have to know [83:44] and it does sadden me that that that we [83:45] don't have that anymore and that means [83:47] we don't have the pool of people to to [83:50] draw on I I guess that's a perfect place [83:53] to segue into the uh uh the Doom 3 [83:56] source code will be released this year I [83:58] got permission from I it's [84:01] [Applause] [84:07] a so it's actually I really wanted to [84:11] say how cool zenmax has been about this [84:14] where you know we we tested the waters a [84:16] little bit with the the open source uh [84:18] Doom Classic on iOS and the um uh and [84:22] releasing the enemy territory [84:23] Wolfenstein Source on that but uh the [84:28] problem the issue with the Doom source [84:29] bace is there's actually still a project [84:31] in development that's derived off of [84:33] this pre 2 is heavily modified but it's [84:36] still essentially an idtech 4 project on [84:39] this and Brink was also heavily modified [84:41] but ittech 4 on this so obviously we're [84:45] not going to put any effort into this [84:46] until rages out the door on the street [84:48] uh programmers are not going to be [84:50] pulled off of even testing or triage or [84:52] any anything to to do this but uh the [84:54] okay has been given and it will be [84:56] happening we have to make sure we get [84:58] all of our I eyes dotted and te's [85:01] crossed uh on the legal department but [85:04] it's as another interesting point on [85:06] here I had a I had uh a lady from the [85:09] legal department uh last year's [85:11] Christmas party at zenmax just come up [85:13] and tell me how important she thought it [85:16] was that we were doing the open source [85:18] of the code base and that was you know a [85:19] little bit of a double take it's like [85:21] legal department lawyers I you think [85:23] this is good great I so zenmax has been [85:28] really really supportive of this and I [85:31] you know I almost put this out as a [85:33] challenge to some of the other software [85:34] companies I you know there's a lot of [85:36] you that could be releasing seminal [85:38] classic Old Source Code that the [85:40] community would appreciate that young [85:42] programmers can learn from that all [85:44] these other benefits can come out of [85:46] it's clearly been good for us I in the [85:49] early years there was argument about it [85:51] about whether you know we gave away too [85:53] much or we helped competitors on this [85:55] but uh there's no doubt at this point [85:58] that the legacy of of the open source [86:00] software has been a really good thing [86:02] for ID and I I'm really happy that we're [86:04] able to kind of continue that going [86:07] forward so uh the uh perfect opportunity [86:10] to pick something up from the Steam Sale [86:12] if you don't have Doom 3 data handy uh [86:14] that's the place to get it now which is [86:16] also a great thing where in previous [86:18] generations when we'd release source [86:20] code if you didn't have it on your shelf [86:22] trying to find some rumage bin with an [86:24] old version of the the software was [86:26] challenging but now I just go to steam [86:28] and uh and get the stuff that way and [86:29] you can get it and start playing around [86:31] with it all right thank you [86:37] all