Video summary

How DOOM Will Teach You What CS Degrees Miss

Main summary

Key takeaways

Educational

Main ideas / lessons conveyed

  • Studying real, old code can teach skills that CS courses often miss

    • The creator analyzed the Doom engine and compared it to interviews with new CS grads, concluding that many would perform better if they’d studied such source code.
    • Emphasis: learning “universal lessons” from mature, working systems rather than only theory.

  • Why “technical limitations” matter

    • Doom’s era forced careful optimization and design choices due to limited hardware/tooling compared with today.
    • Hardware and development tooling evolved from the Wolfenstein era (e.g., better CPUs/RAM; different compilers).

  • Portability as an architectural goal

    • A key design decision was splitting the code into:
      • Platform-independent core
      • Platform-dependent parts
    • The platform split is handled at build/link time using different libraries (linked per target OS/platform).

  • Understand the build pipeline (C/C++ compilation → linking)

    • Compilation units compile independently into object files with unresolved symbols.
    • The linker resolves symbols across object files into the final executable.

  • Separation of engine vs game data

    • Doom ships the engine as an executable, while game assets/data are packaged separately into WAD files.
    • The engine loads the WAD and works with data as “lumps.”

  • Core runtime flow

    • Doom has per-OS entry points that call into a common core.
    • It initializes subsystems (“managers”) and then runs an infinite main loop.

  • Rendering is fundamentally “2 and 1/2D”

    • Doom looks 3D and feels 3D, but rendering is built on a largely 2D map with extra height properties.
    • The engine simulates depth using map structure and rendering tricks.

  • Rendering strategy focuses on efficiency: no overdraw

    • Doom renders mostly column-by-column, using occlusion/clipping logic so it doesn’t waste work on pixels that won’t be visible.

  • Use of BSP (Binary Space Partitioning)

    • BSP precomputes a spatial partitioning tree so the engine can traverse it efficiently at runtime.
    • BSP data is computed by tools ahead of time and stored in WADs, avoiding runtime recomputation.

  • Rendering pipeline components (as described)

    • 2D rendering
      • Intermission screen (background map + sprites/text)
      • Status bar (widgets like ammo/health/armor/keys/etc.)
      • Menu system (menu item structs + menu item arrays)
      • Head-up display behavior (text lines instead of the earlier detailed helmet HUD)
      • Automap
      • Wipe transitions
    • 3D-ish world rendering
      • Walls/portals/surfaces using BSP traversal
      • Clipping/occlusion
        • Horizontal occlusion for solid walls
        • Vertical occlusion for floors/ceilings and portals
      • Visplanes for floor/ceiling regions
        • Visplanes are merged when height/texture/light match to reduce cost
      • Masked elements
        • Sprites, mid-textures, player weapon
        • Render only visible pixels of elements that have transparency
    • Final composition: masked sprites drawn on top of the world.

  • Meta lessons from Doom’s development

    • How Carmack/BSP emerged from a crisis
      • A cancelled Wolfenstein port led to research and experimentation.
      • Carmack studied papers/VHS/math content and found BSP, then integrated it into Doom.
    • Universities often don’t teach “how to tackle unsolved big problems”
      • Instead of just solving known math tasks, you must learn research, information sourcing, and problem framing.
    • Don’t fear changing direction
      • Doom’s team repeatedly shifted approaches (e.g., from earlier engines/genres toward ray casting then Doom’s new architecture).
      • The project’s longevity is linked to willingness to rewrite/rethink rather than stubbornly continue bad paths.

  • Creator’s personal “Doom mindset”

    • Approach new products as “status quo,” then ask: what’s the “Doom equivalent” that would knock you off your chair?
    • Framed as guidance for starting ambitious projects even with limited experience.

Methodologies / instructional-style process (detailed)

Video’s suggested “roadmap” / methodology for analyzing an engine

  1. Identify technical limitations
    • Compare constraints at the time (CPU/RAM/toolchain) and how they shaped design.
  2. Examine the build system
    • Trace the path from source code → object files → linking → executable.
    • Show how cross-platform builds work.
  3. Analyze engine vs game-data separation
    • Determine how assets are packaged and loaded (engine executable vs WAD data).
  4. Walk through the main loop
    • Identify subsystem initialization and the perpetual update/render cycle.
  5. Deep dive rendering
    • Cover both 2D renderer components (menus/HUD/etc.) and the 3D-ish renderer.
    • Explain BSP traversal, clipping, visplanes, and masked sprites.
  6. Share personal first contact + how it informs thought process
    • Use a personal origin story to motivate “why this matters” and how it shapes approach.

Rendering process (as described conceptually)

  • Preprocessing

    • Build BSP tree for the map until subsectors are convex.
    • Store BSP data in WAD alongside other map data.

  • Runtime traversal & visibility

    • Use player position + field of view to traverse BSP from the root node.
    • Determine which side (front/back) to traverse first based on viewpoint.
    • When reaching a subsector (leaf), render it.
    • Ensure back sides are rendered when potentially visible, enabling full frame coverage without overdraw.

  • Projection & segment handling

    • Project wall segments onto the projection plane using fixed-point math.
    • Skip walls facing away (based on start/end angle checks and wall “front side” logic).

  • Clipping / occlusion

    • Horizontal step
      • Track which horizontal screen spans are already occupied by solid walls.
      • Use a solid-segment occlusion structure to know when the frame is fully covered.
    • Vertical step
      • Track per-column visible vertical ranges using:
        • floor clip array
        • ceiling clip array
      • Walls and portals update these arrays to limit what portions can be drawn.

  • Visplanes

    • Create visplane regions (floor/ceiling areas) when walls don’t fully cover the screen.
    • Merge compatible visplanes to reduce rendering cost.
    • Draw visplanes by iterating through the visplane list.

  • Masked elements

    • Render sprites and masked textures after the world.
    • Draw only visible (non-transparent) pixels of these elements.

Speakers / sources featured (identified)

  • Main speaker / narrator: The video creator (referred to in the transcript as “Tariq”; final line: “and Tariq 10X.”)
  • Doom-related contributors mentioned as sources in the transcript:
    • John Carmack (called “Carmack”; central to BSP development)
    • Dave Taylor (credited with writing the 2D renderer)
  • Books / authors referenced:
    • Fabian Sangard — Doom Engine Blackbook
  • Other Doom/writing sources mentioned:
    • “Masters of Doom” (mentioned as a read alongside the Blackbook)
  • Sponsor:
    • Brilliant (video sponsor)

Original video